Re: 32-bit vs AMD64 on Opteron for LAMP server
On Fri, Jul 06, 2007 at 07:53:18AM -0500, Neil Gunton wrote:
> michael@estone.ca wrote:
> The AMD64 port is less straightforward because they do not include the
> dpt_i2o driver, which is necessary for my RAID card. Instead, I have to
> either use the i2o_block driver, which I gather has had some reliability
> issues under load, or else build a patched kernel with dpt_i2o, which
> isn't ideal since it always complicates and lengthens the install. Also,
> for some reason, my own kernels always seem to end up being slower than
> the stock kernels, even though I am careful to go through and build
> in/enable everything very specific to the hardware.
Without the driver, will the card just look like a non-raid card or will
the drives not be visiable at all? If the drives are visible, forget
the hardware raid.
Otherwise, would something like module-assistant be able to make your
module for you without compiling the whole kernel?
>
> >But since you are running 4 Gig of RAM, take full advantage of it by
> >running amd64.
>
> My understanding is that 32-bit can utilize up to 4 GB as well, it's
> when you have more than 4GB that it starts to matter.
>
There's also something about the maximum amount of memory that a single
process can access in 32-bit but I forget the details.
> >The developers have done a great job getting this port official and you
> >won't be disappointed with it. Its rock solid.
>
> I know it's solid, it's been running in my server for over two years.
> I'm wondering about real world speed difference between 32-bit and
> 64-bit given the fact that the 64-bit world is still not as complete in
> terms of software support (dpt_i2o being case in point, but there is, I
> assume, other software that isn't 64-bit safe yet as well). The 32-bit
> version is also rock solid, even more so probably.
>
The only software I've found missing is a flash plugin for browsers but
there's a fix in testing that I'm told can be dragged into one's Etch
box (I'll try it in a bit).
> >If you can, try both in a test environment, and then make your decision.
> >Perhaps there are some apache, or mysql benchmarks you can try?
>
> This is my only server. It's production, and in colo.
What about a test on any amd64 box. Borrow one for a few hours?
> I don't have money to have a multi-server setup at this time. When I
> take it down, the whole shebang is down, and I need to get things back
> up again asap. So it's going to be, ideally, a process of backing up
> the essential data, rebuild, restore essential data, reconfigure for
> Etch, and go. Also, the server is in Chicago IL, I am in Saint Louis
> MO, I don't have much time up there. The colo company has to accompany
> me in to the datacenter for security. They wanted to charge me $100
> per hour to have someone be there with me, but they are doing me a
> favor by not charging me for their time. I know, it seems silly, but
> that's how they do it. I am getting a relatively good deal on the
> bandwidth so it's worth keeping them happy. Upshot is, I don't have
> unlimited time/opportunity to be at the console installing and
> reinstalling operating systems, or mucking around for that matter
> trying to get kernels patched. I know that once we have the base
> system up I can do stuff via ssh, but we're talking about console time
> here. Hence my desire to see how 32-bit would compare
> performance-wise, because I know that has dpt_i2o built-in and will
> work right out of the box.
>
Fairly early in the install, there's a menu item "continue install from
ssh". Is there no way to get remote access to the console so that the
datacenter people only have to put CD-bin1 into the drive?
I can do an install from scratch on my Athlon64, including the raid
setup, in about 20 minutes. The i386 installer looks the same so you
could practice what you want to do on a spare i386 where you are and
write it out step-by-step so that you minimize down time.
> >Oh, and I would ask you if you have considered Software raid instead
> >of using an adaptec raid card? If you have time, try benchmarking
> >between them.
> >You might be suprised to see which one actually works better for you.
>
> I don't know why it would be faster to use up my main CPU cycles doing
> RAID rather than using the hardware RAID that is already in the box. The
> guy that built my server seemed to think that this RAID solution was
> very appropriate for this setup. In any case, see my previous paragraph
> - I won't have time to mess around with testing different setups. Also,
> from what I have seen of software RAID in linux, you still have to mess
> around with making a new kernel with the RAID personalities built into
> the kernel (rather than modules) to be able to boot off a software RAID
> partition. The Adaptec makes it all transparent to me, the 4 drives
> appear as one single drive and RAID 10 is done under the covers.
You can do software raid right from the installer. My box has two
drives, with LVM over raid1 for the system including swap. Grub can
boot off of raid1 so put /boot on raid1 (no LVM) partition.
>
> Does anybody else have any opinions on whether software RAID would be
> faster than using the built-in Adaptec SmartRaid 2015S card?
I can't see how software RAID could ever be _faster_ than hardware raid,
but it may not be any slower. I suppose it depends on the CPU's
workload. If its waiting for disk I/O it may as well work on software
RAID. If it has other compute-bound processes to work on, then farming
out the RAID to hardware makes sense. Personally, I like to farm
anything I can out to hardware but I've never been able to afford a real
hardware RAID card.
>
> For reference, my travails using dpt_i2o with AMD64 were documented here:
>
> http://lists.debian.org/debian-amd64/2005/09/msg00201.html
That's almost 2 years ago. You may find that "it just works". If you
could find someone else with this card, even if they don't usually run
debian, they could boot the installer CD and go through the motions and
see if the drives appear as one drive (hardware RAID working) or many
(no hardware RAID).
Doug.
Reply to: