[ACCEPTED]-Can I tell Linux not to swap out a particular processes' memory?-swap

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

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

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

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

If you wish to change the swappiness for 2 a process add it to a cgroup and set the 1 value for that cgroup:

https://unix.stackexchange.com/questions/10214/per-process-swapiness-for-linux#10227

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

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

There exist a class of applications in which 31 you never want them to swap. One such class 30 is a database. Databases will use memory 29 as caches and buffers for their disk areas, and 28 it makes absolutely no sense that these 27 are ever put to swap. The particular memory 26 may hold some relevant data that is not 25 needed for a week until one day when a client 24 asks for it. Without the caching/swapping, the 23 database would simply find the relevant 22 record on disk, which would be quite fast; but 21 with swapping, your service might suddenly 20 be taking a long time to respond.

mysqld includes 19 code to use the OS / system call memlock. On Linux, since 18 at least 2.6.9, this system call will work 17 for non-root processes that have the CAP_IPC_LOCK capability[1]. When 16 using memlock(), the process must still work within 15 the bounds of the LimitMEMLOCK limit. [2]. One of the (few) good 14 things about systemd is that you can grant the 13 mysqld process these capabilities, without requiring 12 a special program. If can also set the rlimits 11 as you'd expect with ulimit. Here is an override file 10 for mysqld that does the requisite steps, including 9 a few others that you might need for a process 8 such as a database:

[Service]
# Prevent mysql from swapping
CapabilityBoundingSet=CAP_IPC_LOCK

# Let mysqld lock all memory to core (don't swap)
LimitMEMLOCK=-1 

# do not kills this process if low on memory
OOMScoreAdjust=-900 

# Use higher io scheduling
IOSchedulingClass=realtime    

Type=simple    
ExecStart=
ExecStart=/usr/sbin/mysqld --memlock $MYSQLD_OPTS

Note The standard community 7 mysql currently ships with Type=forking and adds --daemonize in 6 the option to the service on the ExecStart line. This 5 is inherently less stable than the above 4 method.

UPDATE I am not 100% happy with this solution. After 3 several days of runtime, I noticed the process 2 still had enormous amounts of swap! Examining 1 /proc/XXXX/smaps, I note the following:

• The largest contributor of swap is from a stack segment! 437 MB and fluctuating. This presents obvious performance issues. It also indicates stack-based memory leak.
• There are zero Locked pages. This indicates the memlock option in MySQL (or Linux) is broken. In this case, it wouldn't matter much because MySQL can't memlock stack.

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

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

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