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.
Leos