TIL: shmmax

shmmax

Vor ein paar Tagen habe ich in /proc/sys/kernel/shmmax einen extrem hohen Wert gefunden, sowas wie 18446744073692774399. Da in dem Gerät nur 32 Gigabyte installiert sind, hat mich dieser Wert etwas verwundert.

Nach einigen Stunden Recherche, wurde ich auf diesen Commit aufmerksam gemacht: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=060028bac94bf60a65415d1d55a359c3a17d5c31 .

Hier wird die Problematik beschrieben, dass System V shared memory dazu missbraucht werden kann, um Out-of-Memory Bedingungen auszulösen, die Standard Maßnahmen jedoch nicht dagegen helfen:

  • Es ist nicht möglich, setrlimit zu verwenden, um die Größe von shm-Segmenten zu begrenzen.
  • Segmente können ohne Verbindung zu irgendwelchen Prozessen existieren, sodass der OOM-Killer nicht in der Lage ist, diesen Speicher freizugeben.

Ein weiterer Grund ist das shared memory heute häufig für Datenbanken als “shared buffers” verwendet wird System V shared memory deshalb recht schnell einige GB groß wird.

Dieser Patch setzt den Wert auf fast das höchst Mögliche, also ein bisschen niedriger als ULONG_MAX, um zu vermeiden, dass es zu einem Overflow kommt.

Weiter wird in dem Commit beschrieben, dass es in der Vergangenheit nötig war, solche Limits unter UNIX zu setzen, dieses Verhalten hat Linux geerbt. Was zur Folge hatte, dass dieser Wert oft vom Benutzer selbst berechnet werden muss und entsprechend eingepflegt werden muss.