Bug 46817 - SWAP space constantly increases even though there is plenty of physical memory
SWAP space constantly increases even though there is plenty of physical memory
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
low Severity low
: ---
: ---
Assigned To: Arjan van de Ven
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-01 04:29 EDT by Kury
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-02 10:46:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kury 2001-07-01 04:29:28 EDT
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
Comment 1 Preston Brown 2001-07-02 10:46:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.