Forum OpenACS Q&A: Re: OpenACS on Debian pros and cons...

Collapse
11: Re: OpenACS on Debian pros and cons... (response to 1)
Posted by Patrick Giagnocavo on 10/17/03 07:28 PM
I have run OpenACS on FreeBSD, Linux, and OpenBSD.

OpenBSD is the easiest to secure, FreeBSD has more capabilities than OpenBSD in terms of ports and will support slightly more hardware - they are faster at supporting new stuff.

I have run OpenACS on Linux in the past and not been impressed.

However, I recently loaded Debian 3.0r1 on a new system, and put everything on an XFS partition (XFS is a journaled filesystem from SGI); and the performance increase can not be denied; most likely due to Linux caching everything it can up to the amount of RAM it has (OpenBSD has a fixed amount you can change at boot time for use in caching).  It was easy to install as well.

I have not done any stringent performance tests, but running Postgres on XFS seems to speed up vacuums and other tasks.

Collapse
15: Re: OpenACS on Debian pros and cons... (response to 11)
Posted by Andrew Piskorski on 10/18/03 11:14 AM
I lack hands on experience with it, but my understanding is that OpenBSD is easy to secure once, and only once. Updates and patches to a live system after the fact? Forget it, last I heard, that wasn't supported, their advice was to rebuild from scratch, more or less like you first installed it. Correct me if I'm wrong...

Oh yeah, if it was up to me, I'd use Debian for everything, barring some much more compelling reasons than "Oracle Corp. says to use Red Hat". Like say, running Linux on an embedded microcontroller that's just too small for Debian, that sort of thing. :)

Collapse
16: Re: OpenACS on Debian pros and cons... (response to 15)
Posted by Patrick Giagnocavo on 10/18/03 04:39 PM
Andrew, concerning OpenBSD upgrades:  you do not have to start from scratch, but, you need to rebuild the main binaries and the kernel to upgrade.

Of course, if you have multiple systems you would only do this once and then move the files over.

You would not lose data or configuration information, but would have to reboot.

Collapse
17: Re: OpenACS on Debian pros and cons... (response to 11)
Posted by Roberto Mello on 10/18/03 08:56 PM
Regardless of Journaling File System used, the PostgreSQL data files should have only its metadata journaled to avoid double journaling.

Here's what Tom Lane had to say about the issue:

"Journaling metadata is good.  Journaling file contents is redundant --- turn that off if you can.  (Of course, if there is anything other than Postgres files on the same device, you may not want to turn off contents journalling..."

For ext3 that means mounting the /var/lib/postgres (or wherever your postgres data is stores) with the option "data=writeback".

I've only heard great things about SGI's XFS, especially its superb ACL features.

-Roberto

Collapse
18: Re: OpenACS on Debian pros and cons... (response to 17)
Posted by Dirk Gomez on 10/22/03 08:24 AM
What about restart time in case of a crash. That is the reason why large Oracle installations are often on a journalled file systems.
Collapse
20: Re: OpenACS on Debian pros and cons... (response to 11)
Posted by Andrei Popov on 10/23/03 05:13 PM
FreeBSD is *very* stable, and if you've been reading on a few stories lately on Slashdot in the past week or so, its performance in most cases is the same, if not better than Linux 2.6.  FreeBSD's TCP/IP stack is considered one of the best (if not the best) implementation.  This may not, however, be all that important for OpenACS.

Postgres runs like a charm on all of my BSD machines, and I had very little trouble setting up OpenACS (aside from the known little patches to get a few models compile).  This, unfortunately, may change with AOL Server 4 -- the stock distribution does not compile at all -- there seems to be just too much Linux-ism (no flames, please) in it (NB: fi your experience differs -- please let me know.  I think I saw a few posts mentioning AS4 on OSX which is FreeBSD with Mach kernel).

FreeBSD does not have journaled FS, but it has a feature that maybe better in some circumstanese -- soft updates.  I am not sure, however, how it affects Postgres -- never benchmarked it nor seen any benchmarks on it.