with 48G of ram, 32 bit + PAE is horribly inefficient, plus it runs into
problems with running out of memory in some zones.
even with 16G of ram this is a touchy situation that you can still run
into serious problems with.
since you can run 32 bit code on a 64 bit kernel, is there any good reason
_not_ to use a 64 bit kernel?
avoiding the entire 'lowmem' issue is just one of the benifits, having
registers twice as big and twice as many of them can make a significant
difference to the kernel.
David Lang
On Wed, 20 Apr 2011, apostolos pantazis wrote:
I can tell you my personal experience with SWAP/OOM and RHEL under
both 32 and 64 bit and you can judge as to whether or not its any good
in your situation; During a migration from 32 bit SLES to 32 bit RHEL
I discovered that workloads previously relatively functional under
SLES started to experience issues with OOM kills; In the beginning I
was a bit confused about the whole idea; The new machine had 3 times
the amount of memory the old machines had; 10 times more powerful
processors and 7 years of technology enhancements; How is this
possible? Well it turns out that badly written code is badly written
code no matter what the conditions but that above and beyond the
point. On our old machines we were running a SMP based kernel and 16GB
of RAM; The workload was mainly batch processing style, a lot of
things waking up doing their thing and back to sleep the go, all day
and night long. The new machines were now running RHEL 5.4 with a PAE
Kernel. First test begin all looks good; Then we started adding some
real data crunching and load and the OOM's started; I had roughly 48GB
of RAM and a 8GB swap; figured that should be good; No sir. After a
lot of research and talking it RedHat we were advised that under RHEL
5 support of Hugemem kernels was dropped; Guess that is their way of
saying *silently* goodbye 32 bit; We were advised that the support
configuration under RHEL 5 32 bit is up to 16GB of RAM; Thats it if we
wanted to guarantee stable operation; BTW the reason we were OOM
killed was due to Low Mem zone pressure; Finally with 16GB of RAM,
12GB of swap and quite some tuning (reservations for Low zone etc) we
got the machine at a almost stable state (we still get the occasional
runaway process which will cause a OOM of some other Random process);
Not happy to say the least; Oh and BTW one of the other tunables I had
to mess with is the swappiness value; set it to 100 seems to work ok
for us.
Now I run Database servers on RHEL 5 64 bit; Thats a different beast;
with no High/Low zone memory separation (I believe under 64 bit all
memory is in the low zone) and a application that can leverage
hugepages things are much much better;
on the 32 bit side I am still bothered by this whole pain of OOM; I am
not sure what else I can do from a SA perspective. so in a way I am
also extremely interested in this thread and any feedback anyone can
provide.
best regards
On Wed, Apr 20, 2011 at 8:13 AM, Dan Foster <[email protected]> wrote:
Hot Diggety! Michael C Tiernan was rumored to have written:
----- Original Message -----
From: "Adam Tauno Williams" <[email protected]>
Most recommendations I see [...]
The thing I keep seeing is stuff that discusses about how much the
system "*needs*". There's lots of sides about how you can live without
much or you *should*[1] have some or you *should*[1] have lots but I'm
wondering if anyone found any discussions about what happens if you
have *too* much swap?
Ignoring the issue of wasting disk space, are there any negatives to
having lots of swap?
That's actually easy to answer: the system slows down BIG time if it's
heavily utilized, to the point where you're forced to power cycle it
uncleanly if you want to regain control in less than 24 hours. :)
So swap sizing is bit of an art; need to know what the app needs (and
how it works behind the scenes) and allocate accordingly, but not set up
such so huge of an 'overdraft' account that you find yourself in an
impossible-to-sanely-fulfill-quickly situation.
-Dan
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
