"free: 180MB" auf einem 8-GB-Server erschreckt jeden Tag jemanden, und fast immer ist alles in Ordnung. Linux benutzt übrigen Speicher als Plattencache und gibt ihn in dem Moment zurück, in dem ihn etwas braucht. Die Zahl, die man liest, ist available, nicht free.

free -h
#               total   used   free   shared  buff/cache   available
# Mem:           7.8Gi  2.1Gi  180Mi   120Mi      5.5Gi       5.3Gi

5,3 Gi unter available heißt, dass 5,3 Gi zu haben sind. Der Cache ist kein verlorener Speicher; er ist Speicher, der etwas Nützliches tut, bis er gebraucht wird.

Swap ist die Zahl, auf die es ankommt

Dass Swap BELEGT ist, ist nicht das Problem. Dass aktiv hinein- und herausgelesen wird, schon: Die Maschine schiebt Seiten auf die Platte, um Platz zu schaffen, und die Platte ist tausendmal langsamer als der Speicher. Alles ist langsam, und in der Anwendung erklärt es nichts.
vmstat 2 5
# watch the si and so columns - sustained non-zero is thrashing

Finden, was ihn festhält

ps aux --sort=-%mem | head -10
smem -rs uss 2>/dev/null | head -10

uss ist der Speicher, den ein Prozess beim Beenden tatsächlich freigäbe - die ehrliche Zahl. rss zählt gemeinsam genutzte Bibliotheken doppelt und lässt jeden PHP-Worker riesig aussehen.

Die übliche Antwort

  • Zu viele PHP-Worker. pm.max_children aus einer Anleitung übernommen statt aus Ihrem RAM berechnet. Teilen Sie den verfügbaren Speicher durch den durchschnittlichen Worker und bleiben Sie vorsichtig.
  • innodb_buffer_pool_size zu groß. Eine Datenbank, der man aufträgt, mehr zu cachen, als die Maschine hat.
  • Ein Leck in einem langlebigen Worker. Starten Sie ihn regelmäßig neu; php-fpm macht das mit pm.max_requests.
Etwas Swap ist gesund - er lässt den Kernel wirklich untätige Seiten beiseiteschieben. Ein Server ohne jeden Swap hat kein Polster und wird bei Knappheit auf der Stelle abgeschossen.