Ich habe mehrmals Benachrichtigungen von meinem Überwachungssystem über 98% Speicher erhalten. Ich habe es ausgeführt topund nur etwa 60% Speichernutzung gezählt, wenn ich summiereErinnerungSpalte. Nach mehreren Stunden war die Speichernutzung wieder normal (~70%). Ich vermutete den FS-Cache, aber free -mdas beweist es nicht.
Irgendwelche Ideen? Server: x86-64, Ubuntu 12.04, 8 GB RAM
# free -m
total used free shared buffers cached
Mem: 7958 7835 123 0 8 39
-/+ buffers/cache: 7787 171
Swap: 975 975 0
#top
top - 10:11:48 up 179 days, 14:25, 1 user, load average: 1.99, 1.81, 1.59
Tasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.8%us, 0.6%sy, 0.0%ni, 82.8%id, 13.6%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 8149424k total, 8017556k used, 131868k free, 6708k buffers
Swap: 999420k total, 999372k used, 48k free, 37952k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30562 mysql 20 0 6033m 2.6g 3160 S 14 32.9 74:37.56 mysqld
10898 www-data 20 0 25.3g 2.0g 1560 S 16 25.6 19:44.10 java
9570 rabbitmq 20 0 2611m 166m 1540 S 6 2.1 628:08.96 beam.smp
13166 redis 20 0 94276 72m 584 S 0 0.9 23:24.47 redis-server
3798 root 20 0 348m 29m 988 S 0 0.4 167:36.37 cimprovagt
7614 root 20 0 51468 28m 1256 S 0 0.4 0:02.59 bash
3677 root 20 0 4706m 26m 0 S 0 0.3 110:47.59 java
3458 bind 20 0 668m 5328 1488 S 0 0.1 0:23.38 named
7595 root 20 0 85380 2956 880 S 0 0.0 0:00.25 sshd
2061 root 10 -10 4996 2948 2104 S 0 0.0 13:39.72 iscsid
632 syslog 20 0 244m 2404 360 S 0 0.0 7:12.39 rsyslogd
5855 newrelic 20 0 107m 1852 1248 S 0 0.0 128:23.28 nrsysmond
1 root 20 0 24340 1516 736 S 0 0.0 0:29.96 init
2741 root 20 0 17340 1308 944 R 0 0.0 0:00.04 top
4214 root 20 0 45336 1264 1020 S 0 0.0 6:12.72 cdm
4235 root 20 0 12428 1108 908 S 0 0.0 10:55.38 processes
4178 root 20 0 19124 1064 856 S 0 0.0 7:20.07 controller
5853 ntp 20 0 37772 1036 872 S 0 0.0 7:40.35 ntpd
4179 root 20 0 86044 1024 848 S 0 0.0 9:55.54 spooler
4008 root 20 0 4090m 980 756 S 0 0.0 0:08.70 console-kit-dae
3790 root 20 0 422m 952 668 S 0 0.0 89:21.80 cimprovagt
3629 root 20 0 50032 868 752 S 0 0.0 1:17.44 sshd
4075 root 20 0 182m 844 408 S 0 0.0 0:02.90 polkitd
27661 root 20 0 101m 776 772 S 0 0.0 0:00.02 mysql
18465 root 20 0 101m 732 732 S 0 0.0 0:00.04 mysql
3436 root 20 0 19112 716 636 S 0 0.0 0:11.25 cron
3783 root 20 0 1009m 716 432 S 0 0.0 0:04.83 cimserver
26239 root 20 0 22092 700 696 S 0 0.0 0:00.03 bash
4181 root 20 0 13196 696 596 S 0 0.0 4:18.57 hdb
3406 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3410 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3428 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3429 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3432 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3972 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
18452 root 20 0 22076 620 620 S 0 0.0 0:00.00 bash
361 root 20 0 22104 568 568 S 0 0.0 0:00.04 udevd
3441 root 20 0 15980 560 464 S 0 0.0 26:28.16 irqbalance
654 messageb 20 0 23948 516 324 S 0 0.0 0:01.98 dbus-daemon
676 root 20 0 21188 504 504 S 0 0.0 0:00.00 bluetoothd
3665 root 20 0 4400 492 488 S 0 0.0 0:00.00 sh
5546 rabbitmq 20 0 7672 488 308 S 0 0.0 1:04.49 epmd
26238 root 20 0 26092 476 476 S 0 0.0 0:00.24 screen
2060 root 20 0 4504 440 400 S 0 0.0 3:18.60 iscsid
Antwort1
PufferIstder FS-Cache.
Puffer sind mit einem bestimmten Blockgerät verknüpft und umfassen das Zwischenspeichern von Dateisystemmetadaten sowie das Verfolgen von Seiten während der Übertragung. Der Cache enthält nur geparkte Dateidaten. Das heißt, die Puffer merken sich, was sich in Verzeichnissen befindet, welche Dateiberechtigungen gelten und verfolgen, aus welchem Speicher für ein bestimmtes Blockgerät geschrieben oder aus welchem Speicher gelesen wird. Der Cache enthält nur den Inhalt der Dateien selbst.
https://stackoverflow.com/a/12547130/636573
Oben sind auf dem Snapshot, den Sie uns gegeben haben, auch 13 % von IOWAIT zu sehen. Für mich sieht das so aus, als ob eine OLTP-Datenbank nicht annähernd genug der benötigten Disk-IOPS erhält. Aktualisieren Sie Ihr Speichersubsystem.
Antwort2
OK, gehen Sie zuerst zurück und stellen Sie sicher, dass Ihre oberste Ausgabe nach Speichernutzung ( RESIdentgröße) sortiert ist. Wenn dies nicht der Fall ist, aktualisieren Sie Ihre Frage mitDasAusgabe. Dann können Sie tatsächlich sehen, was Ihren RAM beansprucht.
Zweitens, vergessen Sie die %MEMSpalte. Dieser spezielle Kuchen ist eine Lüge (aufgrund der Rundung).
Konzentrieren Sie sich stattdessen auf die RESIdent-Größe von Programmen (und wenn Sie sich über Swap-to Gedanken machen, auf die VIRTual-Größe) - sumdieseSpalten und Zahlen stimmen mit dem überein, was Sie in freeder topAusgabe sehen.
Wenn man sich Ihre Top-Ausgabe ansieht, haben Sie einen riesigen (2,6 G) MySQL-Prozess und einen riesigen (2,0 G) Java-Prozess – ich vermute, diese beiden sind Ihre Mitverschwörer, die Ihren gesamten RAM auffressen (was auch immer dieser bestimmte Java-Prozess MySQL tun lässt, ist die Generierung riesiger Ergebnismengen oder Zwischendaten).
Der Java-Prozess hat außerdem eine virtuelle Größe von 25 G (!!) – offensichtlich verliert er intern Speicher, den der Garbage Collector nicht freigibt (oder vielleicht verarbeitet er eine riesige Ergebnismenge ineffizient).
Ich würde wetten, dass Ihr System an einem „normalen Tag“ wahrscheinlich mit 4-5 GB RAM auskommt, und wenn diese beiden Prozesse zusammenkommen, fressen sie den Rest (und noch mehr) auf, und Sie landen in einer schlechten Lage.
Finden Sie heraus, was sie tun, beheben Sie es, und Ihr Problem wird behoben sein.