Linux: Finden Sie heraus, welcher Prozess den gesamten Arbeitsspeicher belegt.
Bevor ich wirklich frage, nur um klar zu sein: Ja, ich kenne mich mit Festplatten-Cache aus und nein, das ist nicht mein Fall :) Entschuldigung, für diese Präambel :)
Ich verwende CentOS 5. Jede Anwendung im System ist stark ausgelagert und das System ist sehr langsam. Wenn ich free -m mache, habe ich Folgendes:
total used free shared buffers cached
Mem: 3952 3929 22 0 1 18
-/+ buffers/cache: 3909 42
Swap: 16383 46 16337
Also, ich habe eigentlich nur 42 MB zur Verfügung! Soweit ich weiß, zählt -/+ buffers/cache den Festplatten-Cache nicht, also habe ich tatsächlich nur 42 MB, oder? Ich dachte, ich könnte mich irren, also habe ich versucht, das Disk-Caching auszuschalten, und es hatte keine Auswirkung - das Bild blieb gleich.
Also entschied ich mich herauszufinden, wer mein gesamtes RAM nutzt, und benutzte dafür top. Aber anscheinend meldet es, dass kein Prozess meinen RAM verwendet. Der einzige Prozess in meinem Top ist MySQL, aber es werden 0,1% von RAM und 400 MB Swap verwendet. Dasselbe Bild, wenn ich versuche, andere Dienste oder Anwendungen auszuführen - alle werden ausgetauscht. top zeigt, dass MEM nicht verwendet wird (maximal 0,1% für jeden Prozess).
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
Neustart hilft nicht und ist übrigens sehr langsam, was ich normalerweise auf diesem Rechner nicht erwarten würde (4 Kerne, 4 GB RAM, RAID1).
Also, damit - ich bin mir ziemlich sicher, dass dies kein Festplatten-Cache ist, der den RAM verwendet, weil er normalerweise reduziert werden sollte und andere Prozesse den RAM nutzen lassen sollten, anstatt zu tauschen.
Schließlich stellt sich die Frage, ob jemand eine Idee hat, wie er herausfinden kann, welcher Prozess den Speicher tatsächlich so stark nutzt.
Unter Linux können Sie im Prozess top die Taste < drücken, um die Sortierung der Ausgabeanzeige nach links zu verschieben. Standardmäßig wird es nach dem %CPU sortiert. Wenn Sie also die Taste viermal drücken, wird es nach VIRT sortiert, der virtuellen Speichergröße, die Ihnen Ihre Antwort gibt.
Ein anderer Weg dies zu tun ist:
ps -e -o pid,vsz,comm= | sort -n -k 2
sollte Ihnen und Ausgabe sortiert nach Prozessen virtuelle Größe geben.
Hier ist die lange Version:
ps --everyone --format=pid,vsz,comm= | sort --numeric-sort --key=2
Zeigen Sie den Prozessspeicher in Megabyte und den Prozesspfad an.
ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n
Nur eine Randnotiz auf einem Server, die die gleichen Symptome zeigt, aber immer noch Speichererschöpfung anzeigt. Was am Ende herausfand, war eine sysctl.conf aus einer Box mit 32 GB RAM und ein Setup für eine Datenbank mit riesigen Seiten, die auf 12000 konfiguriert ist. Diese Box hat also nur 2 GB RAM es hat alle freien RAM den riesigen Seiten zugewiesen (nur 960 von ihnen). Durch das Festlegen von 10 für große Seiten, da ohnehin keine verwendet wurden, wurde der gesamte Speicher freigegeben.
Eine schnelle Überprüfung von/proc/meminfo, um nach den Einstellungen für HugePages_ zu suchen, kann ein guter Anfang sein, um mindestens ein unerwartetes Speicherproblem zu beheben.
Sie können auch den Befehl ps verwenden, um weitere Informationen zum Prozess abzurufen.
ps aux | less
In meinem Fall bestand das Problem darin, dass der Server ein virtueller VMware-Server mit aktiviertem vmw_balloon-Modul war:
$ lsmod | grep vmw_balloon
vmw_balloon 20480 0
vmw_vmci 65536 2 vmw_vsock_vmci_transport,vmw_balloon
Laufen:
$ vmware-toolbox-cmd stat balloon
5189 MB
Rund 5 GB Speicher wurden vom Host zurückgefordert. Obwohl ich 8 GB "offiziell" auf meinem VM hatte, war es in der Praxis viel weniger:
$ free
total used free shared buff/cache available
Mem: 8174716 5609592 53200 27480 2511924 2458432
Swap: 8386556 6740 8379816
Erstelle ein Skript namens show-memory-usage.sh mit folgendem Inhalt:
#!/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") }
'
Ich verweise auf dies und Gesamtspeicher, der vom Python-Prozess verwendet wird? - Stack Overflow , das ist meine Antwort. Ich bekomme jetzt ein bestimmtes Prozesszählwerkzeug (Python).
# 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
Hänge meine Prozessliste an.
$ 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