Re: 32-bit vs AMD64 on Opteron for LAMP server
Adam Stiles wrote:
You won't be able to use all of your 4GB RAM with a 32-bit kernel. A 32-bit
processor only has 4GB of addressing space, and that has to be shared between
memory and peripherals.
Really? I thought that the only limitation was on individual processes
not having more than 4GB available, but the entire system as a whole
could address a lot more than that. But I could be wrong.
You'd also do better with Apache 2.0 or 2.2, as long as you use the "prefork"
I am using apache 1.3 because I also use mod_accel and mod_deflate from
Igor Sysoev. His modules are 1.3 only, and the proxy module (mod_accel)
does some things that mod_proxy didn't seem to provide back when I was
trying to build my reverse proxy. The thing that pops up from memory is
that mod_accel correctly passed cookies and differentiated requests
based on cookies, whereas mod_proxy didn't. So if mod_proxy got two
different requests that were for the same URI, but with the only
difference being the cookie, then mod_proxy would see them as the same
request and (incorrectly, in my book) give the same cached result. I
discussed this with some of the httpd developers, and they insisted that
differentiating requests based on cookies wasn't in the http spec, and
wasn't a "proper" way to do things; I maintained that since cookies are
the universal method of keeping track of sessions and users, thus it
makes perfect sense to differentiate requests based on them. But they
took a dogmatic line, whereupon Igor popped up and said "Hey, my module
does what you're needing", and it worked great, and has been for the
last four years or so.
I have no idea if Apache 2 has progressed to the point of being able to
handle cookies "correctly", but my discussions did not give me hope back
then. Also, it was only recently that mod_perl 2 got to a point where it
even worked, let alone was at the same level of reliability that
mod_perl 1 was at after years of testing. Finally, Embperl, yet another
module essential to my site, wasn't stable in version 2 for a long, long
time, and continues to have compatibility issues that break my (large)
existing code base. All of this prompted me to write an essay about the
patterns I saw, called "Rewrites considered harmful", published on my
site and on slashdot a few years ago. All in all, I am leery of new
systems that claim to get everything right that the old systems didn't,
and I like to use well tested systems in production, not new stuff that
might be faster for plain vanilla cases, but aren't reliable for more
complex situations. Apache 1.3 has worked very well for me, and is rock
solid, and for production I don't have time to mess around with
completely new APIs that were changed just because some developers
needed to feel important that they wrote "version 2 of apache". Their
little campaign to change the whole apache API caused a huge pain in the
ass for many, many people such as myself who had working v1 modules that
would have to be debugged and converted to v2 api calls. It's not
trivial, and it makes all the old books on writing apache modules out of
date. It throws the entire developer community into chaos. Just look at
how long it took mod_perl 2 to stabilize. Very stupid situation. So I
don't feel particularly well disposed toward apache 2, thanks.
If your RAID card is one of the ones that uses a binary-only driver, ignore it
and use the open source drivers with md RAID instead -- md is faster than any
Not binary, I have the source code patch.
manufacturer's proprietary alternative (anything that needs a driver is fake
RAID. True hardware RAID never needs a special driver; the array just shows
up as a single drive). Beside the non-polluted kernel, you also get the
advantage that you can have your swap area without redundancy, hence running
as fast as possible (just set up the partitions as separate swap areas).
I don't think this is an accurate characterization of what constitutes
hardware RAID. Any piece of hardware needs a driver for the kernel to
interact with it. Once the Adaptec array has been defined (in its own
config at boot time) then it does appear to be a single device. Four
hard drives configured as two RAID 1 arrays, then striped into a single
RAID 10 device, appears as a single hard drive to the kernel.
Thanks again,
/Neil
Reply to: