2012-03-09 14:13:35 +0000 2012-03-09 14:13:35 +0000
131
131

Linux: zoek uit welk proces alle RAM gebruikt?

Voor de duidelijkheid: ja, ik weet van disk cache, en nee, het is niet mijn zaak :) Sorry, voor deze preambule :)

gebruik ik CentOS 5. Elke toepassing in het systeem is zwaar aan het ruilen, en het systeem is erg traag. Als ik free -m doe, is dit wat ik heb:

total used free shared buffers cached
Mem: 3952 3929 22 0 1 18
-/+ buffers/cache: 3909 42
Swap: 16383 46 16337

Dus, ik heb eigenlijk maar 42 Mb om te gebruiken! Voor zover ik het begrijp, telt -/+ buffers/cache eigenlijk niet de disk cache, dus ik heb inderdaad maar 42 Mb, toch? Ik dacht dat ik het misschien mis had, dus ik probeerde de disk caching uit te schakelen en het had geen effect - het beeld bleef hetzelfde.

Dus besloot ik uit te zoeken wie al mijn RAM gebruikt, en daar gebruikte ik top voor. Maar, blijkbaar, het meldt dat er geen proces is met behulp van mijn RAM. Het enige proces in mijn top is MySQL, maar het gebruikt 0,1% van het RAM en 400Mb van de swap. Hetzelfde beeld als ik andere diensten of applicaties probeer te draaien - ze gaan allemaal in swap, top laat zien dat MEM niet gebruikt wordt (0.1% maximum voor elk proces).

top - 15:09:00 up 2:09, 2 users, load average: 0.02, 0.16, 0.11
Tasks: 112 total, 1 running, 111 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4046868k total, 4001368k used, 45500k free, 748k buffers
Swap: 16777208k total, 68840k used, 16708368k free, 16632k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
 3214 ntp 15 0 23412 5044 3916 S 0.0 0.1 0:00.00 17m ntpd
 2319 root 5 -10 12648 4460 3184 S 0.0 0.1 0:00.00 8188 iscsid
 2168 root RT 0 22120 3692 2848 S 0.0 0.1 0:00.00 17m multipathd
 5113 mysql 18 0 474m 2356 856 S 0.0 0.1 0:00.11 472m mysqld
 4106 root 34 19 251m 1944 1360 S 0.0 0.0 0:00.11 249m yum-updatesd
 4109 root 15 0 90152 1904 1772 S 0.0 0.0 0:00.18 86m sshd
 5175 root 15 0 90156 1896 1772 S 0.0 0.0 0:00.02 86m sshd

Restart helpt niet, en is trouwens zeer langzaam, wat ik normaal gesproken niet zou verwachten op deze machine (4 kernen, 4Gb RAM, RAID1).

Dus, daarmee - ik ben er vrij zeker van dat dit geen schijfcache is, die de RAM gebruikt, want normaal gesproken had het gereduceerd moeten worden en andere processen RAM moeten laten gebruiken, in plaats van te gaan ruilen.

Dus, ten slotte, de vraag is - als iemand enig idee heeft hoe hij erachter kan komen welk proces eigenlijk zo zwaar gebruik maakt van het geheugen?

Antwoorden (9)

115
115
115
2012-03-09 14:25:01 +0000

Op Linux in het top proces kunt u op de < toets drukken om de uitgangssortering naar links te verschuiven. Standaard is het gesorteerd op de %CPU, dus als je de toets 4 keer indrukt, sorteer je het op VIRT, wat een virtueel geheugenformaat is dat je je antwoord geeft.

Een andere manier om dit te doen is:

ps -e -o pid,vsz,comm= | sort -n -k 2

moet je en uitvoer gesorteerd op processen virtueel formaat geven.

Hier is de lange versie:

ps --everyone --format=pid,vsz,comm= | sort --numeric-sort --key=2
78
78
78
2016-02-09 21:12:26 +0000

Toon het procesgeheugen in megabytes en het procespad.

ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n
14
14
14
2012-10-15 15:05:01 +0000

Gewoon een kanttekening op een server met dezelfde symptomen, maar nog steeds met geheugenuitputting. Wat uiteindelijk gevonden werd was een sysctl.conf uit een doos met 32 GB RAM en een setup voor een DB met enorme pagina’s geconfigureerd op 12000. Deze box heeft slechts 2 GB RAM, dus het was het toewijzen van alle vrije RAM aan de enorme pagina’s (slechts 960 van hen). Het instellen van enorme pagina’s op 10, omdat er toch geen pagina’s werden gebruikt, maakte al het geheugen vrij.

Een snelle check van /proc/meminfo om te zoeken naar de HugePages_ instellingen kan een goed begin zijn voor het oplossen van tenminste één onverwacht geheugenvarken.

5
5
5
2018-03-31 03:38:27 +0000

In mijn geval was het probleem dat de server een virtuele VMware server was met vmw_balloon module ingeschakeld:

$ lsmod | grep vmw_balloon
vmw_balloon 20480 0
vmw_vmci 65536 2 vmw_vsock_vmci_transport,vmw_balloon

Running:

$ vmware-toolbox-cmd stat balloon
5189 MB

Dus ongeveer 5 GB geheugen werd in feite hergebruikt door de host. Dus ondanks dat ik “officieel” 8 GB aan mijn VM heb, was het in de praktijk veel minder:

$ free
              total used free shared buff/cache available
Mem: 8174716 5609592 53200 27480 2511924 2458432
Swap: 8386556 6740 8379816
2
2
2
2013-07-08 06:05:54 +0000

U kunt ook het ps commando gebruiken om meer informatie over het proces te krijgen.

ps aux | less
2
2
2
2016-10-21 10:51:37 +0000

Ik verwijs naar deze en Totaal geheugen gebruikt door Python-proces? - Stack Overflow , dat is mijn antwoord. Ik krijg een specifiek proces (python) teltool, nu.

# Megabyte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum/1024 " MB"}'
87.9492 MB

# Byte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum " KB"}'
90064 KB

Voeg mijn proceslijst toe.

$ ps aux | grep python
root 943 0.0 0.1 53252 9524 ? Ss Aug19 52:01 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root 950 0.6 0.4 299680 34220 ? Sl Aug19 568:52 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root 3803 0.2 0.4 315692 36576 ? S 12:43 0:54 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
jonny 23325 0.0 0.1 47460 9076 pts/0 S+ 17:40 0:00 python
jonny 24651 0.0 0.0 13076 924 pts/4 S+ 18:06 0:00 grep python

Referentie

1
1
1
2016-03-14 20:50:46 +0000

Maak een script genaamd show-memory-usage.sh met inhoud:

#!/bin/sh
ps -eo rss,pid,user,command | sort -rn | head -10 | awk '{ hr[1024**2]="GB"; hr[1024]="MB";
 for (x=1024**3; x>=1024; x/=1024) {
 if ($1>=x) { printf ("%-6.2f %s ", $1/x, hr[x]); break }
 } } { printf ("%-6s %-10s ", $2, $3) }
 { for ( x=4 ; x<=NF ; x++ ) { printf ("%s ",$x) } print ("\n") }
 '
0
0
0
2019-07-12 19:46:37 +0000

Mijn ubuntu server DISTRIB RELEASE=18.04 op Hyper-V had het grootste deel van het geheugen gebruikt, maar alle processen waren in orde. (Toegegeven, ik heb snapd en onbeheerde-upgr pakketten verwijderd, maar 95% van het geheugen werd nog steeds gebruikt.)

Het antwoord is dat Hyper-V dynamisch geheugen heeft, dus het nam geheugen voor het gebruik van het hoofdsysteem en ubuntu markeerde het als gebruikt.

Hoop dat het iemand helpt.

0
0
0
2019-03-31 17:51:48 +0000

Dit neemt ook het proces id, sorteert op MB gebruikt, en schetst het commando (dat het proces creëerde):

ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n