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

Linux: Finden Sie heraus, welcher Prozess den gesamten Arbeitsspeicher nutzt?

Bevor Sie tatsächlich fragen, nur um das klarzustellen: Ja, ich kenne mich mit Disk-Cache aus, und nein, das ist nicht mein Fall :) Entschuldigung, für diese Präambel :)

Ich benutze CentOS 5. Jede Anwendung im System ist stark ausgelastet, 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 habe ich eigentlich nur 42 Mb zu verwenden! Soweit ich verstanden habe, zählt -/+ buffers/cache eigentlich nicht den Plattencache, also habe ich tatsächlich nur 42 Mb, richtig? Ich dachte, ich könnte mich irren, also versuchte ich, den Plattencache auszuschalten, aber es hatte keinen Effekt - das Bild blieb dasselbe.

Also beschloss ich, herauszufinden, wer meinen gesamten RAM-Speicher benutzt, und ich benutzte dafür top. Aber anscheinend wird berichtet, dass kein Prozess meinen RAM-Speicher verwendet. Der einzige Prozess in meinem Kopf ist MySQL, aber er benutzt 0,1% des RAM und 400Mb Swap. Dasselbe Bild, wenn ich versuche, andere Dienste oder Anwendungen laufen zu lassen - alle gehen in Swap, top zeigt, daß MEM nicht benutzt wird (maximal 0,1% für jeden Prozeß).

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 dieser Maschine nicht erwarten würde (4 Kerne, 4Gb RAM, RAID1).

Also, damit - ich bin mir ziemlich sicher, daß dies kein Plattencache ist, der das RAM benutzt, denn normalerweise hätte er reduziert werden müssen und anderen Prozessen die Nutzung des RAMs erlauben sollen, anstatt zum Swap zu gehen.

Also, schließlich ist die Frage - ob jemand eine Idee hat, wie man herausfinden kann, welcher Prozeß den Speicher tatsächlich so stark nutzt?

Antworten (9)

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

Unter Linux können Sie im Prozess top die Taste < drücken, um die Sortierung der Ausgabeanzeige nach links zu verschieben. Standardmäßig wird sie nach %CPU sortiert, d.h. wenn Sie die Taste 4 Mal drücken, wird sie nach VIRT sortiert, d.h. nach der Größe des virtuellen Speichers, der Ihnen Ihre Antwort liefert.

Eine andere Möglichkeit, dies zu tun, ist:

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

sollte Ihnen und der Ausgabe sortiert nach Prozessen virtuelle Größe liefern.

Hier ist die lange Version:

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

Zeigen Sie den Prozessspeicher in Megabyte und den Prozesspfad an.

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

Nur eine Randbemerkung auf einem Server, der die gleichen Symptome zeigt, aber immer noch Gedächtnisschwäche zeigt. Was am Ende gefunden wurde, war eine sysctl.conf aus einer Box mit 32 GB RAM und Setup für eine DB mit riesigen Seiten, die auf 12000 konfiguriert war. Diese Box hat nur 2 GB RAM, so dass sie den riesigen Seiten (nur 960 von ihnen) den gesamten freien RAM zuwies. Die Einstellung von “huge pages” auf 10, da ohnehin keine verwendet wurden, setzte den gesamten Speicher frei.

Eine schnelle Überprüfung von /proc/meminfo, um nach den HugePages_-Einstellungen zu suchen, kann ein guter Anfang für die Fehlersuche bei mindestens einem unerwarteten Speicherfresser sein.

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

In meinem Fall war das Problem, dass es sich bei dem Server um einen virtuellen VMware-Server mit aktiviertem vmw_balloon-Modul handelte:

$ 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

Also wurden in der Tat etwa 5 GB Speicher vom Host zurückgefordert. Obwohl ich also “offiziell” 8 GB in meiner 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
2
2
2
2013-07-08 06:05:54 +0000

Sie können auch den Befehl ps verwenden, um weitere Informationen über den Prozess zu erhalten.

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

Ich verweise auf dieses und Vom Python-Prozess genutzter Gesamtspeicher? - Stack-Überlauf , das ist meine Antwort. Ich erhalte jetzt ein spezielles Tool zum Zählen von Prozessen (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

Meine Prozessliste anhängen.

$ 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

Verweis

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

Erstellen Sie ein Skript namens show-memory-usage.sh mit dem 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") }
 '
0
0
0
2019-07-12 19:46:37 +0000

Mein Ubuntu-Server DISTRIB RELEASE=18.04 auf Hyper-V hatte den größten Teil des Speichers belegt, aber alle Prozesse waren in Ordnung. (Zugegeben, ich habe Snapd- und unbeaufsichtigte upgr-Pakete entfernt, aber 95 % des Speichers wurden immer noch benutzt)

Die Antwort ist, dass Hyper-V dynamischen Speicher hat, also nahm es Speicher für die Benutzung des Hauptsystems und ubuntu markierte es als benutzt.

Hoffentlich hilft es jemandem.

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

Dies nimmt auch die Prozess-ID, sortiert nach dem verwendeten MB und umreißt den Befehl (der den Prozess erstellt hat):

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