total used free shared buffers cached
Mem: 95360 87764 7596 8188 724 7896
-/+ buffers: 79144 16216
Swap: 32252 6800 25452
Why is USED still increasing?
On Tue, 7 Jan 1997, Jake (not the snake) Messinger wrote:
> Im still having this problem BIG TIME! This appears to be a kernel bug.
>
> I now have 96 megs ram in the computer. (triton II, P133, 2 eide 1
> gig drives). I added the EXTRA ram in hopes that the prob would go away.
> It had 64 and used to run nicely.
>
> Here is a free:
>
> total used free shared buffers cached
> Mem: 95360 94024 1336 5104 144 2580
> -/+ buffers: 91300 4060
> Swap: 32252 16464 15788
>
> Here is what is running: (ps -aux)
>
> USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
> ams 9872 0.0 0.0 2012 84 p6 S 09:03 0:00 (dbc)
> ams 9941 0.0 0.0 2012 4 p7 S 09:09 0:00 (dbc)
> ams 10014 0.0 0.0 2012 4 p8 S 09:15 0:00 (dbc)
> ams 10127 0.0 0.0 2012 4 p9 S 09:26 0:01 (dbc)
> ams 10155 0.0 0.1 2012 100 p10 S 09:27 0:02 (dbc)
> ams 10168 0.0 0.0 2012 4 pc S 09:27 0:00 (dbc)
> ams 10300 0.0 0.0 2012 4 p0 S 09:36 0:01 (dbc)
> ams 10422 0.0 0.0 2012 4 q0 S 09:47 0:02 (dbc)
> ams 11284 0.0 0.0 2012 4 p4 S 11:03 0:00 (dbc)
> ams 11341 0.2 0.1 2012 140 p1 S 11:07 0:03 (dbc)
> ams 11733 0.1 0.3 2012 328 p5 S 11:34 0:00 /usr/swills/dbc
> amy 10415 0.0 0.0 1132 0 q0 SW 09:47 0:00 (tcsh)
> aworchel 11721 0.1 0.0 936 0 p5 SW 11:34 0:00 (menu)
> jake 11075 0.0 0.0 1128 20 p2 S 10:47 0:00 (tcsh)
> jake 11084 0.0 0.1 796 128 p2 S 10:47 0:00 newmail
> jake 11771 0.1 0.2 1128 240 p3 S 11:36 0:00 -tcsh
> jake 11780 0.0 0.1 796 188 p3 S 11:36 0:00 newmail
> jake 11781 2.3 4.4 7152 4196 p3 S 11:36 0:02 pine
> karen 10130 0.0 0.0 936 0 p10 SW 09:26 0:00 (menu)
> karen 11274 0.0 0.0 936 0 p4 SW 11:03 0:00 (menu)
> lynne 10276 0.0 0.0 1132 0 p1 SW 09:36 0:00 (tcsh)
> marcia 9862 0.0 0.0 936 0 p6 SW 09:03 0:00 (menu)
> mary 10117 0.0 0.0 936 0 p9 SW 09:26 0:00 (menu)
> mary 10158 0.0 0.0 936 0 pc SW 09:27 0:00 (menu)
> moongate 208 0.0 0.0 1076 0 ? SW Jan 4 0:00 (autorun)
> moongate 20823 0.0 0.0 3620 0 ? SW Jan 6 0:00 (gdb)
> moongate 20825 3.4 15.5 19820 14832 ? D Jan 6 74:03 /usr3/home/moongate/M
> nelson 9931 0.0 0.0 936 0 p7 SW 09:09 0:00 (menu)
> nelson 10004 0.0 0.0 936 0 p8 SW 09:15 0:00 (menu)
> new 82 0.0 0.0 788 0 ? SW Jan 4 0:00 (rpc.portmap)
> nobody 10822 0.0 0.1 932 120 ? S 10:25 0:00 /usr/sbin/httpd
> nobody 11073 0.0 0.1 932 128 ? S 10:47 0:00 /usr/sbin/httpd
> nobody 11106 0.0 0.2 932 268 ? S 10:50 0:00 /usr/sbin/httpd
> nobody 11124 0.0 0.1 932 168 ? S 10:50 0:00 /usr/sbin/httpd
> nobody 11218 0.0 0.3 932 328 ? S 10:57 0:00 /usr/sbin/httpd
> nobody 11621 0.0 0.1 932 140 ? S 11:27 0:00 /usr/sbin/httpd
> nobody 11631 0.0 0.1 932 156 ? S 11:27 0:00 /usr/sbin/httpd
> nobody 11650 0.0 0.1 932 168 ? S 11:28 0:00 /usr/sbin/httpd
> root 1 0.0 0.0 776 32 ? S Jan 4 4:14 (init)
> root 2 0.0 0.0 0 0 ? SW Jan 4 0:02 (kflushd)
> root 3 0.0 0.0 0 0 ? SW< Jan 4 0:31 (kswapd)
> root 4 0.0 0.0 0 0 ? SW Jan 4 0:00 (nfsiod)
> root 5 0.0 0.0 0 0 ? SW Jan 4 0:00 (nfsiod)
> root 6 0.0 0.0 0 0 ? SW Jan 4 0:00 (nfsiod)
> root 7 0.0 0.0 0 0 ? SW Jan 4 0:00 (nfsiod)
> root 13 0.0 0.0 756 40 ? S Jan 4 1:11 update (bdflush)
> root 60 0.0 0.1 772 152 ? S Jan 4 0:22 /usr/sbin/crond -l10
> root 78 0.0 0.0 784 80 ? S Jan 4 0:33 /usr/sbin/syslogd -r
> root 80 0.0 0.0 776 0 ? SW Jan 4 0:00 (klogd)
> root 86 0.0 0.6 1940 604 ? S Jan 4 0:16 /usr/sbin/named -b /u
> root 88 0.0 0.0 788 16 ? S Jan 4 0:00 (lpd)
> root 90 0.0 0.0 804 16 ? S Jan 4 0:01 (lpd)
> root 92 0.0 0.0 816 60 ? S Jan 4 0:00 /usr/sbin/rpc.mountd
> root 94 0.0 0.0 844 68 ? S Jan 4 0:00 /usr/sbin/rpc.nfsd
> root 100 0.0 0.2 1156 220 ? S Jan 4 0:01 sendmail: accepting c
> root 105 0.0 0.0 776 0 ? SW Jan 4 0:00 (gpm)
> root 113 0.0 0.1 916 96 ? S Jan 4 0:06 /usr/sbin/httpd
> root 123 0.0 0.0 1124 4 1 S Jan 4 0:00 (tcsh)
> root 350 0.0 0.0 772 0 4 SW 17:16 0:00 (agetty)
> root 1061 0.0 0.0 772 0 6 SW 17:35 0:00 (agetty)
> root 1136 0.0 0.0 772 32 ? S 17:37 0:00 (inetd)
> root 1180 0.0 0.0 772 0 2 SW 17:37 0:00 (agetty)
> root 1194 0.0 0.0 772 0 5 SW 17:38 0:00 (agetty)
> root 5287 0.0 0.0 772 0 3 SW Jan 4 0:00 (agetty)
> root 9023 0.0 0.0 816 0 ? SW 07:25 0:00 (in.telnetd)
> root 9861 0.0 0.0 816 0 ? SW 09:03 0:00 (in.telnetd)
> root 9930 0.0 0.0 816 0 ? SW 09:09 0:00 (in.telnetd)
> root 10003 0.0 0.0 816 0 ? SW 09:15 0:00 (in.telnetd)
> root 10116 0.0 0.0 816 0 ? SW 09:26 0:00 (in.telnetd)
> root 10128 0.0 0.0 816 4 ? S 09:26 0:00 (in.telnetd)
> root 10157 0.0 0.0 816 0 ? SW 09:27 0:00 (in.telnetd)
> root 10271 0.0 0.0 816 0 ? SW 09:36 0:02 (in.telnetd)
> root 10414 0.0 0.0 816 0 ? SW 09:47 0:00 (in.telnetd)
> root 11074 0.0 0.0 816 44 ? S 10:47 0:02 in.telnetd
> root 11273 0.0 0.0 816 0 ? SW 11:03 0:00 (in.telnetd)
> root 11695 0.0 0.4 1124 416 p2 S 11:33 0:00 -tcsh
> root 11720 0.0 0.0 816 56 ? S 11:34 0:00 in.telnetd
> root 11770 0.1 0.0 816 88 ? S 11:36 0:00 in.telnetd
> root 11798 0.0 0.3 824 360 p2 R 11:38 0:00 ps -aux
> rose 9024 0.0 0.0 936 0 p0 SW 07:25 0:00 (menu)
>
> As you can see, only the mud is taking up a significant amount of ram
> (almost 20%), but this was NEVER much of a problem before. The mud does
> NOT run as root and worked fine on a 1.3 and a 2.0.0 kernel. I have the
> slackware 3.1.0 distribution which has the LATEST libs and kernel 2.0.27.
> I have the same problem with 2.0.21 so SOMETHING happened between 2.0.0
> and 2.0.21
>
> Why are my USED buffers so high!?!?!
>
> This has got to be a kernel problem. I run the exact same stuff on an
> alternate server running 2.0.0 and it runs happily.
>
> Also I can write a program (eatmem) that allocates 2 megs ram then crashes
> and running this enough times will crash the server. This is runing NOT as
> root also.
>
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> Jake Messinger 713-772-6690 jake@ams.com
> Advanced Medical Systems, Inc. jake@uh.edu
> Houston, Texas http://www.ams.com/~jake
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> (Betcha can't do this on a MAC)
>
>
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Jake Messinger 713-772-6690 jake@ams.com
Advanced Medical Systems, Inc. jake@uh.edu
Houston, Texas http://www.ams.com/~jake
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
(Betcha can't do this on a MAC)