tags:

views:

1071

answers:

5

Is there a way to tell Linux that it shouldn't swap out a particular processes' memory to disk?

Its a Java app, so ideally I'm hoping for a way to do this from the command line.

I'm aware that you can set the global swappiness to 0, but is this wise?

A: 

You can do that by the mlock family of syscalls. I'm not sure, however, if you can do it for a different process.

jpalecek
I would be careful how much of the total system memory is locked though. I suspect that you could bring down the system through trashing if you weren't careful.
Dana the Sane
+3  A: 

You can do this via the mlockall(2) system call under Linux; this will work for the whole process, but do read about the argument you need to pass.

Do you really need to pull the whole thing in-core? If it's a java app, you would presumably lock the whole JVM in-core. I don't know of a command-line method for doing this, but you could write a trivial program to call fork, call mlockall, then exec.

You might also look to see if one of the access pattern notifications in madvise(2) meets your needs. Advising the VM subsystem about a better paging strategy might work out better if it's applicable for you.

Note that a long time ago now under SunOS, there was a mechanism similar to madvise called vadvise.

Thomas Kammeyer
@sanity did you try this? How did it work out for you? I was considering doing something similar.
Bill K
A: 

As super user you can 'nice' it to the highest priority level -20 and hope that's enough to keep it from being swapped out. It usually is. Positive numbers lower scheduling priority. Normal users cannot nice upwards (negative nos.)

SumoRunner
unless I'm mistaken, this will only affect the CPU time the process is granted, not its tendency towards main memory usage.
intuited
+3  A: 

Except in extremely unusual circumstances, asking this question means that You're Doing It Wrong(tm).

Seriously, if Linux wants to swap and you're trying to keep your process in memory then you're putting an unreasonable demand on the OS. If your app is that important then 1) buy more memory, 2) remove other apps/daemons from the machine, or dedicate a machine to your app, and/or 3) invest in a really fast disk subsystem. These steps are reasonable for an important app. If you can't justify them, then you probably can't justify wiring memory and starving other processes either.

dwc
If it were cryptographically-related, it's entirely reasonable to want to stay in memory. gnome-keyring, for instance, takes quite a few steps to keep important bits of itself off of swap. (Other than that, reasonable observations.)
Paul Fisher
Good point, Paul. I do feel that this qualifies as an unusual circumstance.
dwc
It's quite usual in banking and payment card industry with all the strong cryptography requirements.
Aleksander Adamowski
See the following advice ("recommendation MEM06-C - Ensure that sensitive data is not written out to disk") from CERT that applies to C programs on POSIX and Windows:https://www.securecoding.cert.org/confluence/display/seccode/MEM06-C.+Ensure+that+sensitive+data+is+not+written+out+to+diskIt's pretty standard stuff when secure coding is required. Similar stuff is needed for Java.
Aleksander Adamowski
BTW, encrypting swap space would alleviate the problem, but it still wouldn't prevent a privileged system user from reading sensitive data from the crypto block device that backs swap space - possibly even long after the original program's termination (until the particular swap area gets overwritten).
Aleksander Adamowski
What about UI-related processes that don't use much memory? EG the desktop manager's panels, that sort of thing? user interface stuff should be ready to go at all times, or at least more ready than stuff that's basically batch processing. Ideally apps would be built so that their interface had a higher real-memory priority than their guts, so that it would still be possible to, EG scan through the menus while the app was busy doing something. Some apps do work this way but it requires multithreading. but apps that are just launchers etc. should be given higher memory "stickiness".
intuited
Java should probably be coded in a way that it's data area is never swapped--java is too likely to re-arrange all of it's data which can cause some extreme thrashing. However keeping the entire JVM and libraries in memory might be overkill.
Bill K
+1  A: 

Why do you want to do this?
If you are trying to increase performance of this app then you are probably on the wrong track. The OS will swap out a process to increase memory for disk cache - even if there is free RAM, the kernel knows best (actauly the samrt guys that wrote the scheduler know best).
If you have a process that needs responsiveness (it's swapped out while not used and you need it to restart quickly) then nice it to high priority, mlock, or using a real time kernel might help.

Martin Beckett