So beheben Sie hohe Speicherauslastung unter Linux

So finden Sie heraus, was auf einem Linux-Server den Speicher verbraucht, und welche Overcommit-Einstellungen des Kernels das steuern.

Die Situation «Out of Memory» erkennen.

Der Engpass kann schon vorbei sein, wenn Sie nachsehen. Prüfen Sie deshalb zuerst das Kernel-Log auf OOM-Kills: Der Linux-Kernel verwaltet den Speicher des Servers, indem er Prozesse nach bestimmten Kriterien beendet und den Speicher freigibt, den der beendete Prozess belegt hat.

Für jeden Prozess, den der Kernel so beendet, entsteht ein Logeintrag. Die Logs liegen üblicherweise unter /var/log/.

Mit dem folgenden grep-Befehl durchsuchen Sie alle Logdateien unter /var/log/ nach einem Out-of-Memory-Fehler.

grep -i -r 'out of memory' /var/log/
Mar 1 01:24:05 srv kernel: [3966348.114233] Out of memory: Kill process 48305 (php-cgi) score 21 or sacrifice child
Mar 1 01:24:08 srv kernel: [3966350.061954] Out of memory: Kill process 48318 (php-cgi) score 21 or sacrifice child

Aktuelle Auslastung:

root@srv:~# free -m 
              total        used        free      shared  buff/cache   available
Mem:     1981         720         319         138         940         916
Swap:      524          84         440

Den Verlauf der Speicherauslastung über den Tag zeigt der Befehl «sar».

root@server [~]# sar -r
Linux (server.example.com)       03/05/2019      _x86_64_        (2 CPU)
12:00:01 AM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit
12:10:01 AM   1672764   1407160     45.69    100356    749140   1618364     44.90
12:20:01 AM   1289208   1790716     58.14    106580   1130096   1599588     44.38
12:30:01 AM   1248100   1831824     59.48    109184   1144680   1621332     44.98
12:40:01 AM   1267972   1811952     58.83    111460   1155828   1604104     44.51
12:50:01 AM   1254556   1825368     59.27    113888   1159632   1599480     44.38
01:00:01 AM   1092296   1987628     64.53    116020   1164540   1802228     50.00
01:10:01 AM   1212168   1867756     60.64    118204   1169516   1633940     45.33
...
Average:    kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit
Average:      1465222   1614702        52.43          179213    834889      1655342     45.93

Eine RAM-Erweiterung ist nötig, wenn der Server dauerhaft hohe Speicherauslastung zeigt oder die durchschnittliche Auslastung des Tages über 90 % liegt, denn eine so hohe Auslastung kann auf einem stark genutzten Server den freien Speicher zeitweise aufbrauchen. Auf einer virtuellen Maschine wird anhaltender Speicherdruck mit mehr RAM oder durch Korrektur der Anwendung gelöst, nie mit Swap.

Ein weiteres nützliches Werkzeug, um speicherhungrige Prozesse zu finden, ist der Befehl «top», mit dem Sie die laufenden Prozesse nach ihrem Ressourcenverbrauch sortieren können.

root@server [~]# top -c
top - 18:41:45 up 109 days, 18:03,  5 users,  load average: 1.30, 1.24, 1.24
Tasks: 544 total,   2 running, 541 sleeping,   0 stopped,   1 zombie
Cpu(s):  8.3%us,  1.4%sy,  0.2%ni, 89.8%id,  0.3%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  12296096k total, 11531800k used,   764296k free,   586732k buffers
Swap: 16777212k total,   209160k used, 16568052k free,  2471072k cached
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                    
2376001 root      20   0  230m 101m 4588 R 31.4  0.8   1:22.06 spamd child                                                                                                                 
2448741 root      30  10 19472 1056  792 S  2.6  0.0   0:00.08 /usr/sbin/lveps -c 1 -p -d -n -o id:10,ep:10,pno:10,pid:15,tno:5,tid:15,cpu:7,mem:15,com:256                                
 953572 mysql     20   0 17.5g 5.3g 5336 S  1.7 44.9 102:38.10 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=server
 844549 root      30  10  424m  59m 4532 S  1.3  0.5  52:13.20 /opt/alt/python27/bin/python2.7 /usr/share/lve-stats/lvestats-server.py start --pidfile /var/run/lvestats.pid               
1351883 root      20   0 1127m 638m 1768 S  1.3  5.3  37:37.24 /usr/local/cpanel/3rdparty/bin/clamd                                                                                        
 844526 root      30  10  462m  35m 1204 S  1.0  0.3  30:54.20 /opt/alt/python27/bin/python2.7 /usr/share/lve-stats/lvestats-server.py start --pidfile /var/run/lvestats.pid               
   3109 nscd      20   0 2725m 3956 2260 S  0.7  0.0 188:08.43 /usr/sbin/nscd                                                                                                              
2243573 nobody    20   0  189m  78m 1140 S  0.7  0.7   4:22.20 litespeed (lshttpd - #01)                                                                                                   
2448384 mailnull  20   0 78756 7736 3348 S  0.7  0.1   0:00.06 /usr/sbin/exim -bd -q1h -oP /var/spool/exim/exim-daemon.pid

Mit der folgenden Tastenfolge sortieren Sie die Prozesse nach ihrer Speichernutzung.

Geben Sie den Befehl top ein. Drücken Sie SHIFT+o für die Optionen von top. Drücken Sie N und Enter.

Speicherlecks finden

Sie können die Serverzeit ablesen, zu der das «out of memory» gemeldet wurde, hier “Mar 1 01:24:05”. Suchen Sie mit grep nach diesem Zeitstempel in den Logdateien Ihrer Anwendungsserver wie Apache, MySQL und so weiter.

Auf einem cPanel-Server können Sie mit grep die Access-Logs der Websites nach verdächtigen oder missbräuchlichen Zugriffen durchsuchen, die diese Ressourcenerschöpfung ausgelöst haben.

grep  -ir “01/Mar/2019:01:2”  /usr/local/apache/domlogs/

Einige verdächtige Aktivitäten, die sich in den Access-Logs erkennen lassen:

1. Viele Zugriffe von bestimmten IP-Adressen.
2. Viele Zugriffe auf nicht vorhandene Ressourcen oder Dateien und Ähnliches.
3. Eine hohe Zahl von HTTP-POST-Anfragen.
4. Eine hohe Zahl fehlgeschlagener Zugriffsversuche, etwa Logins.

Mit dem Befehl mysqladmin proc stat finden Sie MySQL-Abfragen, die lange hängen und dadurch hohen Speicherverbrauch verursachen.

root@server [~]# mysqladmin proc stat
+--------+------+-----------+----+---------+------+-------+------------------+----------+
| Id     | User | Host      | db | Command | Time | State | Info             | Progress |
+--------+------+-----------+----+---------+------+-------+------------------+----------+
| 137324 | root | localhost |    | Query   | 0    | init  | show processlist | 0.000    |
+--------+------+-----------+----+---------+------+-------+------------------+----------+
Uptime: 370827  Threads: 1  Questions: 20484133  Slow queries: 0  Opens: 1456  Flush tables: 1  Open tables: 747  Queries per second avg: 55.239

Prüfen Sie die Spalten Time, db und State, finden Sie die Abfragen mit einem hohen Wert unter «Time» und sehen Sie sie gemeinsam mit dem Entwickler Ihrer Website durch.

Aktivieren Sie das «Slow Query Logging» in MySQL und beheben Sie die langen Abfragen gemeinsam mit dem Entwickler Ihrer Website.

Memory Overcommit

Üblicherweise erlaubt ein Linux-Server, für einen Prozess mehr Speicher zu reservieren, als er tatsächlich braucht. Dahinter steht die Annahme, dass kein Prozess den gesamten ihm zugestandenen Speicher nutzt, sodass dieser anderen Prozessen zur Verfügung steht. Sie können einstellen, wie das System mit Memory Overcommit umgeht, und die Einstellung wird mit dem Werkzeug sysctl gesetzt.

Alle sysctl-Parameter zeigt der Befehl sysctl -a. Der Parameter, der uns interessiert, ist vm.overcommit_memory.

[root@srv ~]# sysctl -a | grep vm.overcommit_memory
vm.overcommit_memory = 0

vm.overcommit_memory kennt 3 Werte: 0, 1 und 2.

• 0 Erlaubt Overcommit auf Basis der Schätzung «haben wir genug RAM»
• 1 Erlaubt Overcommit immer
• 2 Verweigert Overcommit, wenn das System den Speicher nicht hat.

Ein weiterer sysctl-Parameter, den Sie beachten sollten, ist overcommit_ratio. Er legt fest, welcher Prozentsatz des physischen Speichers zusätzlich zum Swap-Bereich berücksichtigt wird, wenn Prozesse Overcommit betreiben dürfen.

Setzen wir vm.overcommit_memory auf 2, erlaubt der Kernel kein Overcommit über den Swap-Bereich plus vm.overcommit_ratio des gesamten RAM hinaus: vm.overcommit_memory=2 vm.overcommit_ratio=50% RAM=8GB SWAP=4GB

Mit dieser Konfiguration ist Overcommit für 4GB SWAP + 50 % von 8GB RAM möglich.

sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=100

sysctl -w überlebt keinen Neustart. Tragen Sie dieselben zwei Zeilen in /etc/sysctl.conf ein.