Slashdot Mirror

← Back to Stories (view on slashdot.org)

Swap Performance in Linux

Posted by michael on from the RAM-is-cheap dept.

GizmoDuck writes "I'm working in a computational chemistry lab, and we find ourselves using memory and CPU hogs like Amber and Gaussian. The CPU hogging isn't a problem, thanks to Condor, but when submitting one of the jobs that request (and pretty much require) all the physical RAM in the machines, Linux promptly starts swapping so hard that the mouse pointer in X stops moving, NFS and NIS halt, and things don't get back to normal for five minutes. I've tried toying a bit with the settings in /proc/sys/vm/kswapd to no avail. I've done some poking around on the 'net looking for answers. Faster disks and swap partitions at the beginning of the drive aren't really an option at this point. I haven't found a good solution yet. I was wondering if the /. community has any input on how to keep the system from locking during periods of necessarily high swap activity?"

3 of 62 comments (clear)

  1. The answer can be summed up in a math equation by Anonymous Coward · · Score: 2, Informative

    2.4.x

    I still have no idea why Linus used 2.4 as a development tree. Go back to 2.2.x, no swapping problems going on there.

    By the way, does anyone know the command to flush the swap partition?

  2. preempt ? by raulmazda · · Score: 4, Informative

    Maybe try out the preemptible kernel patch?

    My personal experience is that it has helped my workstation's interactive performance noticeably for big ass c++ compiles and periods of lots of disk activity (big apt-get dist-upgrades). Thankfully, I'm no longer doing the big ass c++ compiles, so it's not as big of an issue as it used to be :)

  3. Computational Chemistry by leastsquares · · Score: 3, Informative

    Why don't you submit yhis query to the computational chemistry mailing list (see CCL)

    Those people may be able to give you some sensible suggestions, especially with respect to those particular peices of software.

    I believe that you can restrict the amount of memory that Gaussian uses via its keywords. When it requires more, it will handle the dumping of data to disk itself. Read the manual - I haven't used gaussian since g94 was the current version so can't remember..

    How big is your AMBER simulation? I think I would run a smaller system... or even better... buy some more RAM given that it is dirt cheap nowadays.

    AMBER's memory use is a bit heavy - you may have better luck with another MD package. Maybe NAMD? (Although I'd still vote for the "buy more RAM" option)