Re: 32-bit vs AMD64 on Opteron for LAMP server
Hi,
If I understand right you need to rebuild all the system because you
need to repartition,
If you need the software in sarge why not have sarge and use your
already patched kernel?
Try to patch the etch kernel before you go and even you could spend a
quickly down time on the server previous to rebuild "in situ" just
patch the kernel install reboot and ask for another reboot if the
things don't go...
This is second thread about this server rebuild if my memory is accurate...
From my point of view you need sarge and you already have experience
with, don't reinstall everything just move to the right place, backup
data delete and recreate part of the new partitions move the base
system, delete and recreate again the rest of the partitions and place
in the final place the base system.
There is a possibility that you could upgrade everything to etch and
preserve your kernel but I have doubts in that point, certainly in
this list could answer it.
On the othe hand , are your sure about all the system could operate
without problems with etch i386?
If you are sure don't waste your time and make your life easy
installing it, if that is 10% less powerfull in the other way that is
100% more maintainable.
On 7/6/07, Neil Gunton <neil@nilspace.com> wrote:
Roberto C. Sánchez wrote:
> On Fri, Jul 06, 2007 at 04:07:23PM +0100, 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.
>>
> Not true. With PAE, a 36-bit address is available, allowing access to
> 64 GB of RAM. What does not change, however, is that with a 32-bit
> kernel no single process can address more than 4 GB of RAM.
That sounds very much like what I have read as well.
>> You'd also do better with Apache 2.0 or 2.2, as long as you use the "prefork"
>> version (which is more compatible with PHP, if that's your chosen "P"). The
>> breaking-up of the configuration files is a bit of a pain to deal with, but
>> worth it in the long run (I knocked up a Perl script to break up a 1.3-style
>> configuration file into 2.0-style snippets; e-mail me if you are interested,
>> on-list if you think others would be interested). Otherwise it's just like
>> 1.3, only faster.
>>
> This is true. Any pain spent transitioning from Apache v1 to Apache v2
> or 2.2 is well worth it.
You're probably right; however, as is probably usual with production
environments, I never really have the time or inclination to take time
out to do such a major shift. Apache 1.3 works just fine for me, I
really doubt there is that much difference between using apache 1.3 and
apache 2, since the limiting factor for me is almost certainly not in
the number of raw static connections that can be served, but rather the
mod_perl backend communicating with the mysql database server. That is
the heavyweight here, not apache itself. CPU used to do complex sql
queries, and disk I/O in serving those queries, is what is going to kill
performance, not how fast apache can fork a new process.
Thanks,
/Neil
--
To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
Perhaps the depth of
love can be calibrated by the number of different selves that are
actively involved in a given relationship.
Carl Sagan (Contact)
Jaime Ochoa Malagón
Integrated Technology
Tel: (55) 52 54 26 10
Reply to: