[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RHEL 4 improvement in use of swap? (compared to RHEL 3)



While I just two Linux servers I found RHEL3 to be quite swappy and it caused issues with my samba server. I switched to RHEL-4 and set vm.swappiness=0 and haven't looked back.


Don MacAskill wrote:


Leos Bitto wrote:

Arjan van de Ven wrote:

On Thu, 2005-10-27 at 15:20 -0700, robert infotility com wrote:

Hello,

First of all I've used Redhat distributions for several years and
Linux has been almost entirely a pleasant and productive environment
for me. Thanks to all responsible parties for the hard work which
goes into every release.

My question is, is RHEL 4 known to be better at handling
virtual memory (swapping in particular) than RHEL 3 ?

I have an ageing Dell box (2 x 450 MHz cpu, 256 M memory) running
RHEL 3 update 6 (last updated circa 2005/10/01).
Today it was running several Java programs, Mozilla, and various
daemons, and perking along OK. The Java programs are terrible
memory pigs but GUI apps response to mouse clicks and command line
response to keyboard input was OK.





at some point... the VM subsystem only deals with VIRTUAL memory..
that's no substitue for real memory. If you really need more than 256 Mb
then it will suck always. Disk is just over 1000 times slower as ram,
and no amount of kernel hacking can fix that.

RHEL4 behaves different than RHEL3, better in a lot of cases. But
again.. once you're over the edge in requirements, there's not a whole
lot the kernel can do other than trying to keep the box alive.



About a year ago we found an issue with RHEL 3 AS, which we considered serious - however, when I called Red Hat support, I was assuerd that the behaviour was absolutely normal. What happened was a server with 4 CPUs, 2 GB RAM and 2 GB swap, which started swapping terribly after some disk activity appeared, and kept swapping ever since then, until we rebooted it.

We have an in-house developed Java application, which is running using Sun's JVM 1.4. This application receives authentication requests from some black-box device and has to respond quickly, otherwise that black-box device considers the authentication requests failed.

We were able to trigger the issue simply by analyzing some large logs using simple grep commands. What happened was that the server cached the logs in RAM and forced the application to swap and thus slow down unacceptably. What bothered us was that the application never returned to the original speed, even after we stopped accessing the logs. Even after several hours it did not recover, so we had to reboot the server.

We solved it by turning off the swap - fortunatelly we had enough RAM. This way the RAM does not get filled with disk cache and the application is not forced to slow down due to swapping and everything works fine. When we tried this application on RHEL 4, it worked much better - no swapping, even with heavy disk activity.


We saw the same behavior with RHEL3. It preferred disk cache so much that our applications would suffer greatly.

One of our DB boxes has 8GB of RAM. We fed MySQL 6GB of RAM, but found that RHEL3 was keeping 4-5GB of disk cache around, and thus, would swap out 2-3GB of MySQL, causing massive slowdowns.

Like you, we just disabled swap and watched a free, massive performance increase.

We're now on RHEL4 with lots of our boxes, but I haven't had the guts to enable swap on any of them. I just make sure we buy ample RAM and never need it. I wouldn't mind having it as a safety net, if I knew the prefers-disk-cache-to-application-RAM problem was fixed, though... Anyone done any comparisons?

Don

--
nahant-list mailing list
nahant-list redhat com
https://www.redhat.com/mailman/listinfo/nahant-list

--
My "Foundation" verse:
Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.

-- carpe ductum -- "Grab the tape"
CDTT (Certified Duct Tape Technician)

Linux user #322099
Machines:
206822
256638
276825
http://counter.li.org/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]