Der Linux-Server verfügt nicht mehr über ausreichend Speicher und Swap

2076
Andrius

Ich denke, es gibt Speicherleckagen und Speicher werden nicht freigegeben. Gibt es ein paar gute Möglichkeiten, um herauszufinden, welcher Prozess und warum ein Speicherleck läuft?

Die einzige temporäre Lösung besteht darin, den Server neu zu starten. Aber nach ein paar Tagen wächst der Speicherbedarf und wächst und der Server verlangsamt sich sehr und ich muss noch einen Neustart durchführen.

Zum Beispiel free -m:

 total used free shared buffers cached Mem: 2005 1989 15 0 2 126 -/+ buffers/cache: 1861 144 Swap: 2004 1494 510

Die Sache ist, diese Verwendung ändert sich nicht viel. Und diese Speichernutzung bleibt entweder so gefroren oder wird größer, aber nicht weniger.

Kennt jemand bewährte Methoden, um die Ursache von Speicherverlusten zu ermitteln?

top sortiert nach verwendetem Speicher zeigt dies:

top - 16:58:40 up 6:00, 1 user, load average: 0.10, 0.08, 0.07 Tasks: 136 total, 1 running, 135 sleeping, 0 stopped, 0 zombie Cpu(s): 26.2%us, 1.0%sy, 0.0%ni, 72.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2053476k total, 2036380k used, 17096k free, 39272k buffers Swap: 2053112k total, 13348k used, 2039764k free, 924372k cached  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND  1529 oerp 20 0 919m 419m 8100 S 19.9 20.9 17:44.49 python  1768 postgres 20 0 342m 161m 137m S 0.0 8.1 0:27.28 postgres  1775 postgres 20 0 334m 155m 137m S 0.0 7.8 0:14.05 postgres  1751 postgres 20 0 333m 152m 138m S 0.0 7.6 0:26.56 postgres  1779 postgres 20 0 330m 150m 136m S 0.0 7.5 0:13.73 postgres  1758 postgres 20 0 329m 149m 137m S 0.0 7.5 0:19.89 postgres  1742 postgres 20 0 330m 149m 137m S 0.0 7.5 0:10.19 postgres  1769 postgres 20 0 329m 149m 138m S 0.0 7.4 0:55.47 postgres  1760 postgres 20 0 329m 149m 137m S 0.0 7.4 0:16.52 postgres  1772 postgres 20 0 328m 148m 136m S 0.0 7.4 0:18.93 postgres  1764 postgres 20 0 328m 148m 137m S 0.0 7.4 0:17.72 postgres  1759 postgres 20 0 329m 148m 136m S 0.0 7.4 0:21.15 postgres  1757 postgres 20 0 330m 148m 136m S 5.6 7.4 0:17.73 postgres  1766 postgres 20 0 327m 148m 138m S 0.3 7.4 0:25.07 postgres  1762 postgres 20 0 328m 148m 136m S 0.0 7.4 0:17.91 postgres  1776 postgres 20 0 329m 147m 137m S 0.0 7.4 0:21.30 postgres  1770 postgres 20 0 328m 147m 136m S 0.0 7.4 0:16.01 postgres

Es ist klar, dass Python und PostgreSQL den gesamten Speicher verbrauchen, aber wie kann ich die Ursache feststellen, dass kein Speicher freigegeben wird (es gibt viele verschiedene Operationen, die Python und PostgreSQl ausführen)?

mit ps aux:

Dieser Prozess belegt den meisten Speicher:

oerp 1529 4.9 20.9 916984 429332 ? Sl 10:58 17:55 /opt/odoo/venv/bin/python /opt/odoo/odoo/openerp-server --config=/etc/odoo-server.conf --no-database-list

Aber wenn Sie alle Prozesse so kombinieren (es gibt viele davon) 

postgres 1742 0.0 7.4 338268 153140 ? Ss 10:59 0:10 postgres: oerp nodbaltic [local] idle

Dann nimmt es den größten Teil des Speichers.

Ist es für postgresql normal, viele Leerlaufprozesse zu haben, die so viel Speicher benötigen?

cat /proc/meminfo:

MemTotal: 2053476 kB MemFree: 20312 kB Buffers: 38944 kB Cached: 926480 kB SwapCached: 1196 kB Active: 1431788 kB Inactive: 490424 kB Active(anon): 824712 kB Inactive(anon): 276456 kB Active(file): 607076 kB Inactive(file): 213968 kB Unevictable: 3884 kB Mlocked: 3884 kB SwapTotal: 2053112 kB SwapFree: 2039340 kB Dirty: 4144 kB Writeback: 0 kB AnonPages: 959108 kB Mapped: 164144 kB Shmem: 142332 kB Slab: 58796 kB SReclaimable: 38440 kB SUnreclaim: 20356 kB KernelStack: 1728 kB PageTables: 28340 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 3079848 kB Committed_AS: 2131992 kB VmallocTotal: 34359738367 kB VmallocUsed: 281432 kB VmallocChunk: 34359446164 kB HardwareCorrupted: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 10240 kB DirectMap2M: 2086912 kB

PS und der Server läuft auf einer virtuellen Maschine, wenn dies einen Unterschied macht.

0
Haben Sie versucht, "top" zu verwenden oder in "/ proc / $ pid / mem" nach dem beleidigenden Prozess zu suchen? Dmitry Grigoryev vor 9 Jahren 2

3 Antworten auf die Frage

1
Paramaeleon

Der topBefehl zeigt die derzeit ausgeführten Prozesse mit ihrer Speichernutzung an. In dieser RESSpalte wird der von einem Prozess tatsächlich belegte Speicher angezeigt. Drücken Sie Shift+ M, um nach dieser Spalte zu sortieren. Drücken Sie die QTaste, um den Bildschirm wieder zu verlassen.

0
Jdeboer

Es gibt verschiedene Möglichkeiten, um herauszufinden, welche Prozesse ausgeführt werden und wie viel Speicher verwendet wird.

Top wurde bereits erwähnt, aber ich bevorzuge die Verwendung von oben oder oben. Sie können diese von Ihrem Repository aus installieren (yum install atop oder apt-get install atop). Dadurch erhalten Sie eine viel bessere und vollständige Übersicht über alles, was auf Ihrem Server passiert. Sie können sogar oben konfigurieren, um alle x Minuten alles zu protokollieren, was beim Debuggen Ihres Problems hilfreich sein kann.

Sie können auch einfach prüfen, was gerade ausgeführt wird und Ressourcen verwenden, indem Sie eingeben

ps faux

Mit dem PS-Befehl erhalten Sie eine Momentaufnahme aller aktuell laufenden Prozesse. Es gibt eine Spalte für die Verwendung von CPU und MEM.

Auch die Verwendung von free -m zum Debuggen von Speicherproblemen kann irreführend sein. Es wäre eine bessere Idee zu prüfen:

cat / proc / meminfo

Oder verwenden Sie die oben genannten Tools wie "top" oder "htop", um einen besseren Einblick in die tatsächliche Speichernutzung zu erhalten (Speicher wird durch Cache und Puffer reserviert).

Wenn Sie die Ergebnisse von ps faux oder top / atop / htop veröffentlichen, können wir Ihr Problem besser unterstützen.

0
user3471740

Verschieben Sie alle Daten im Speicher auf die Festplatte und löschen Sie den physischen Speicher:

sudo /bin/syncfree pagecache, dentries and inodes  sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"

Stellen Sie sicher, dass ausreichend physischer Speicher zum Speichern des gesamten Auslagerungsbereichs vorhanden ist, und verschieben Sie die ausgelagerten Daten anschließend wieder in den verfügbaren RAM, indem Sie die folgenden zwei Befehle ausführen: 

$ free -m total used free shared buffers cached Mem: 2048 884 1163 0 0 42 -/+ buffers/cache: 842 1205 Swap: 996 996 0   sudo /sbin/swapoff -a && sudo /sbin/swapon -a

Dadurch werden vertauschte Elemente in den physischen Speicher verschoben, der Swap wird deaktiviert und erneut aktiviert.

Verwandte Probleme