From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; AIRF) Description of problem: The used swap space constantly increases and top reports parts of the programs swapping. We have to restart daemons in order to decrease the used swap space. Used swap amount never goes down and constantly increases. The machine is a PIII 866 Mhz (133MHz system bus), 512 MB RAM, 9GB IBM SCSI II Hard Drive, Adaptec Ultra160 SCSI Controller. SWAP used generally is 60MB. RH7.1, 2.4.2 kernel. The same daemons that were running on a Celeron 366 MHz, 128 MB RAM, 6.4 GB IDE drive on a RH 6.1 (2.2.16 kernel) were using at maximum 20 MB of swap. All deamons have been recompiled in 7.1 environment after switching from 6.1. Please see TOP's results below modified to show SWAP usage by process. I don't know if this is proc system or kernel related so I am posting here. I have checked all over the net however could not come accross any detailed explanations about the inner details of swap usage. Any pointers would be appreaciated. Kury How reproducible: Always Steps to Reproduce: Run the system. Expected Results: SWAP should not be used at all on our system since the physical RAM is enough. Additional info: # top 11:18am up 44 days, 18:01, 2 users, load average: 0.00, 0.00, 0.00 96 processes: 95 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 1.3% user, 0.5% system, 0.0% nice, 98.0% idle Mem: 512268K av, 369576K used, 142692K free, 0K shrd, 4380K buff Swap: 120476K av, 34944K used, 85532K free 252816K cached PID USER PRI NI SIZE SWAP RSS SHARE STAT %CPU %MEM TIME COMMAND 17664 pr 13 0 2180 0 2180 1216 S 0.7 0.4 0:00 ipop3d 13735 nobody 11 0 14988 0 14M 1268 S 0.3 2.9 1:10 squid1 17667 root 18 0 1068 0 1068 840 R 0.3 0.2 0:00 top 21784 named 10 0 20008 596 18M 1060 S 0.1 3.7 9:12 named 16827 nobody 10 0 1588 0 1588 1320 S 0.1 0.3 0:00 httpd 1 root 8 0 124 52 72 68 S 0.0 0.0 0:08 init 2 root 9 0 0 0 0 0 SW 0.0 0.0 0:00 keventd 3 root 9 0 0 0 0 0 SW 0.0 0.0 7:11 kswapd 4 root 9 0 0 0 0 0 SW 0.0 0.0 0:00 kreclaimd 5 root 9 0 0 0 0 0 SW 0.0 0.0 1:26 bdflush 6 root 9 0 0 0 0 0 SW 0.0 0.0 0:05 kupdated 7 root 9 0 0 0 0 0 SW 0.0 0.0 0:00 scsi_eh_0 773 root 9 0 64 60 4 4 S 0.0 0.0 0:00 mingetty 7619 root 9 0 260 92 168 128 S 0.0 0.0 0:00 sshd 21366 root 9 0 140 136 4 4 S 0.0 0.0 0:00 socks5 21367 root 9 0 748 44 704 528 S 0.0 0.1 0:00 socks5 21370 root 8 0 748 44 704 528 S 0.0 0.1 0:00 socks5 21476 root 8 0 184 68 116 84 S 0.0 0.0 0:00 crond 21509 root 9 0 228 56 172 128 S 0.0 0.0 0:03 syslogd 21534 root 8 0 688 64 624 468 S 0.0 0.1 0:02 xinetd 21764 named 9 0 20008 596 18M 1060 S 0.0 3.7 0:00 named 21783 named 9 0 20008 596 18M 1060 S 0.0 3.7 0:00 named 21788 root 9 0 144 100 44 20 S 0.0 0.0 0:00 bouncer 21793 root 9 0 4060 2584 1476 192 S 0.0 0.2 7:19 msgsnarf 21797 named 9 0 20008 596 18M 1060 S 0.0 3.7 0:04 named 21800 root 10 0 5824 104 5720 712 S 0.0 1.1 9:38 dsniff 21805 named 9 0 20008 596 18M 1060 S 0.0 3.7 1:08 named 21807 root 9 0 216 52 164 152 S 0.0 0.0 6:26 ngrep 21883 root 11 0 5048 3196 1852 268 S 0.0 0.3 15:38 snort 21905 root 9 0 184 180 4 4 S 0.0 0.0 0:00 safe_mysqld 21932 mysql 9 0 3384 2880 504 220 S 0.0 0.0 0:00 mysqld 21934 mysql 8 0 3384 2880 504 220 S 0.0 0.0 0:00 mysqld 21935 mysql 9 0 3384 2880 504 220 S 0.0 0.0 0:00 mysqld 21936 mysql 9 0 3384 2880 504 220 S 0.0 0.0 0:00 mysqld 26918 root 9 0 740 680 60 40 S 0.0 0.0 0:00 httpsd 26919 nobody 9 0 928 924 4 4 S 0.0 0.0 0:00 httpsd 26920 nobody 9 0 1756 488 1268 916 S 0.0 0.2 0:00 httpsd 26921 nobody 9 0 864 860 4 4 S 0.0 0.0 0:00 httpsd 26922 nobody 9 0 872 868 4 4 S 0.0 0.0 0:00 httpsd 26923 nobody 9 0 1640 396 1244 904 S 0.0 0.2 0:00 httpsd # free -m total used free shared buffers cached Mem: 500 360 139 0 4 247 -/+ buffers/cache: 109 390 Swap: 117 34 83 # vmstat procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 34944 142812 4380 253084 0 0 4 10 1 5 3 5 3
The 2.4 kernel is _much_ more aggressive about swapping out processes that aren't actually being used. We have been working on tuning this behaviour in our recent errata kernel, and will continue to aggressively optimize the swapping/memory management behaviour in the kernel.