SHMMAX + wie sich Kernel-Parameter auswirkten, die versehentlich nicht richtig gesetzt wurden

SHMMAX + wie sich Kernel-Parameter auswirkten, die versehentlich nicht richtig gesetzt wurden

ein paar Worte zum gemeinsamen Speicher

Gemeinsam genutzter Speicher ermöglicht Prozessen den Zugriff auf gemeinsame Strukturen und Daten, indem diese in gemeinsam genutzten Speichersegmenten abgelegt werden. Dies ist die schnellste Form der Interprozesskommunikation, da bei der Datenübertragung zwischen den Prozessen keine Kernelbeteiligung erfolgt. Tatsächlich müssen Daten nicht zwischen den Prozessen kopiert werden.

Wir stellen fest, dass der Wert von Redhat-Maschinen enorm ist, wie im Folgenden dargestellt.

 cat /proc/sys/kernel/shmmax
 17446744003692774391

 sysctl -a | grep kernel.shmmax
 kernel.shmmax = 17446744003692774391

wenn ich es auf Giga umrechne, ist es - 16248546544.17632

ist das logisch?, übersehen wir hier etwas

Die Maschinen sind mit 64G und 16 CPU ausgestattet und werden im Hadoop-Cluster verwendet

Antwort1

DerStandardwertfür shmmaxist

#define SHMMAX (ULONG_MAX - (1UL << 24))

Dies ist eine Obergrenze, die so groß wie möglich gewählt wird, während gleichzeitig das Risiko eines Überlaufs begrenzt wird:

SHMMNI, SHMMAX und SHMALL sind standardmäßige Obergrenzen, die von sysctl geändert werden können. Die Werte für SHMMAX und SHMALL wurden so groß wie möglich gewählt, ohne Szenarien zu ermöglichen, in denen der Benutzerbereich Überläufe verursacht, wenn die Grenzen über Operationen der Form „aktuelle Grenze abrufen; X hinzufügen; Grenze aktualisieren“ angepasst werden. Es wird daher nicht empfohlen, SHMMAX und SHMALL größer zu machen. Diese Grenzen sind sowohl für 32- als auch für 64-Bit-Systeme geeignet.

Der Wert ist so in Ordnung, er ist richtig eingestellt, es liegt kein Fehler vor.

verwandte Informationen