V7.3 Beta as Up2Date package?

personnaly I've astaro test environments under kvm virtualization under ubuntu which is working quite well... (better than vmware [:)] )

else just backing up your old config and installing the 7.250 beta should be fine, even under your vmware vm... then restore your backedup config...

I imagine that since they are changing the backend DB to Postgres that it may take them a while to work out the conversion routine that they'll be using when they do release an up2date package version, they decided to go ahead and get started on the beta so we can get the bugs wrung out while they work on that...

That's just a guess on my part.

We'll come up with an Up2Date later, but it can still take 1-3 weeks. Like Bruce already wrote, this one isn't that simple and requires more in-house testing than usual.

OK, I understand this database conversion issue. Perhaps I'll do a new install at the weekend, we'll see [;)]

I imagine that since they are changing the backend DB to Postgres that it may take them a while to work out the conversion routine that they'll be using when they do release an up2date package version, they decided to go ahead and get started on the beta so we can get the bugs wrung out while they work on that...

That's just a guess on my part.

how come the conversion to postgres?  they just got done moving to mysql.

According the the info at up2date.astaro.com, "Perfomance Improvements for Logging and Reporting (based on PostgreSQL)" are the reason... I think that MySQL was having some memory leak issues when the box was heavily loaded (I didn't have any customers myself that reported this issue to me, but I've seen some references to it on the UBB here), and perhaps is not as quick as Postgres.  I've found that Postgres seemed to be more stable and faster than the "other" open source SQL servers I've tried (though I've not really had any real issues with MySQL itself), so I'm thinking this is a good move.

According the the info at up2date.astaro.com, "Perfomance Improvements for Logging and Reporting (based on PostgreSQL)" are the reason... I think that MySQL was having some memory leak issues when the box was heavily loaded (I didn't have any customers myself that reported this issue to me, but I've seen some references to it on the UBB here), and perhaps is not as quick as Postgres.  I've found that Postgres seemed to be more stable and faster than the "other" open source SQL servers I've tried (though I've not really had any real issues with MySQL itself), so I'm thinking this is a good move.

Hi,
I just installed a v7.300b on a vmware partition. It installed easily, trouble is I setup one NIC because this was a proof of concept box.

Try using vmware server 2.0b RC1, in my opinion it is a lot better than 1.04 which is the last version I used.

Ian M[:)]

Yes, I'm going to upgrade to VMware Server 2.0, too. But first I need a new home server (the one in my signature is way too slow *g*). 

I think a X3320 with 8 Gigs of RAM should be enough for the next few years [:)].

According the the info at up2date.astaro.com, "Perfomance Improvements for Logging and Reporting (based on PostgreSQL)" are the reason... I think that MySQL was having some memory leak issues when the box was heavily loaded (I didn't have any customers myself that reported this issue to me, but I've seen some references to it on the UBB here), and perhaps is not as quick as Postgres.  I've found that Postgres seemed to be more stable and faster than the "other" open source SQL servers I've tried (though I've not really had any real issues with MySQL itself), so I'm thinking this is a good move.

I think there's other reasons.  I operate one high traffic site on mysql and there's no memory leaks at all.  I also help administer another site that has even more database activity with no issues.  I know there's a ton of fear about the future of Mysql since Sun bought them.

William, I was going to say the same thing, that MySQL normally performs great, ..., and I am a "Certified MySQL DBA", but MySQL does need more memory when using InnoDB tables (which ASL7 is) versus the default MyISAM tables, and some of the smaller boxes may not have enough RAM.

This is not exactly the same as a memory 'leak', but the result is similar; memory usage grows as more data is processed and buffered.

512MB RAM really is low considering everything going on inside an ASL firewall these days (assuming more than just PF is being used). I've got a linux mailserver with 1GB + 1GB swap that has been crashing lately because the command-line mail A/V software is getting too bloated. I had to greatly lower the # of threads, even though it had been fine for many years before.

Nonetheless, I've seen your mysql configation comments on here, and I agree with you that ASL's MySQL configuration could have been MUCH better tuned, as well as the kernel swapiness.
After I made those changes to my box at home, I didn't have any more 'unchecked growth' in MySQL's memory usage on 7.x, and I only have 512MB RAM.

If Postgres truly uses less memory, great, but if it's just tuning issues, it's kind of silly to switch.

My understanding is that MySQL InnoDB and PostgreSQL perform similarly on all but very high-end hardware (as of 2006 Postgres scaled better on 8CPUs), but MySQL and InnoDB have been making a lot of improvements since 2006. Regardless, on 1-4CPUs, there hasn't been enough difference to declare a winner.
http://www.google.com/search?q=innodb+~versus+postgresql+performance+graphs+OR+charts

For the record, InnoDB is the transactional storage engine for MySQL, and is comparable in features / ACID compliance to Postgres.

Basically, I think some tuning would have helped a lot, but I too suspect there are other, non-technical, reasons for the switch.

Barry

Yes but you can really chop the cache for the db if needed.  This is a consistent issue with Astaro's tuning is that they forget to tune to their 12x series machines.  Frankly i think the 12x series needs to be either seriously upgrade(and make 1 GB ram the default) or dropped completely.