Der Speicher ist knapp

448
swiffer

Vom freien Befehl gemeldeter gemeinsam genutzter Speicher steigt ständig an, während der verfügbare Speicher auf 0 sinkt. Verstanden, dass Linux einen freien RAM für die Zwischenspeicherung von Festplatten verwendet, aber auch nach dem Ausführen von drop_caches der Speicher für gemeinsam genutzten Speicher nach wie vor sehr hoch ist. Nach 1-2 Tagen beginnt das System zu tauschen und wird sehr langsam!

$ grep Shmem /proc/meminfo Shmem: 4922540 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB  $ df -BK | grep tmpfs tmpfs 1608216K 3268K 1604948K 1% /run tmpfs 8041060K 12K 8041048K 1% /dev/shm tmpfs 5120K 4K 5116K 1% /run/lock tmpfs 8041060K 0K 8041060K 0% /sys/fs/cgroup tmpfs 1608212K 16K 1608196K 1% /run/user/120 tmpfs 1608212K 0K 1608212K 0% /run/user/1000  $ free -m Gesamt belegt frei gemns. Puffer/Cache verfügbar Speicher: 15705 494 4220 4807 10990 10069 Auslagerungsspeicher: 8099 3 8096

Wie kann ich sehen, warum Shared zunimmt und was da drin ist?

Ich habe gitlab für die Verwendung von prometheus konfiguriert und node_exporter aktiviert, damit ich Einblicke in die Speichernutzung bekomme. Sie können deutlich sehen, dass etwa 250 MB alle 20 Minuten um hh: 13, hh: 33 und hh: 53 zunehmen.

prometheus node_exporter über längere Zeit inaktiv

0

2 Antworten auf die Frage

0
harrymc

Anscheinend läuft ein Programm in der Erstellung von Shared Memory-Segmenten. Diese Segmente können nicht aus dem Arbeitsspeicher ausgelagert werden, daher wird der verfügbare Arbeitsspeicher aufgebraucht, was zu Auslagerungen führt.

Informationen
zum Identifizieren des Produkts finden Sie im Artikel So ermitteln Sie, welches Programm den Freigabespeicher verwendet und wann es verwendet wurde .

Die kurze Zusammenfassung lautet:

  1. Verwenden Sie ipcs -mdiese Option, um Informationen zum Shared Memory-Segment zu erhalten

image1

  1. Zeigt ipcs -mpan, welche PID das Shared Memory-Segment verwendet (oder verwendet)

image2

  1. ps -pSuchen Sie nach den PID-Informationen

Vielen Dank für das Teilen dieser Anweisungen. Ich habe die Anweisungen abgeschlossen und eine laufende gitlab-Instanz heruntergefahren, da gitlab-psql und postgres dort auftauchten. Die Nutzung des gemeinsam genutzten Speichers bleibt jedoch weiterhin hoch und steigt alle 20 bis 30 Minuten an. swiffer vor 6 Jahren 0
Möglicherweise müssen Sie weiter suchen, oder Gitlab wird von selbst neu gestartet. harrymc vor 6 Jahren 0
tat das, mein ursprünglicher Beitrag wurde mit einem prometheus node_exporter-Diagramm aktualisiert, das regelmäßig ansteigende inaktive Größe anzeigt. Gibt es eine Chance zu sehen, was hier regelmäßig läuft? soweit ich weiß, nichts innerhalb von crontab swiffer vor 6 Jahren 0
Ich verstehe nicht, warum das oben genannte Verfahren Ihnen nicht hilft, den Schuldprozess herauszufinden. Shared Memory kann nicht ohne Verwendung existieren, da es zerstört wird, wenn der letzte Benutzer es schließt oder der Prozess beendet wird. harrymc vor 6 Jahren 0
Hat mit dem Absturz von gnome-shell alle 20 Minuten zu tun. (Siehe andere Antwort) swiffer vor 6 Jahren 0
0
swiffer

Gefunden, dass Gnome-Shell alle 20 Minuten abstürzt. Das System wird als Headless-Homeserver verwendet, ist jedoch über HDMI (4-TV-TV) ständig an ein 4-k-Fernsehgerät angeschlossen. Skalierung anzeigen In der Benutzersitzung auf 200% einstellen.

System: H370 / i915 / i3-8100.

Ich habe das HDMI-Kabel abgezogen und zumindest für den Moment sieht es gut aus!

Ausgabe von dmesg | Grep-Gnomeshell

Verwandte Probleme