Ich habe gerade eine Reihe von Upgrades durchgeführt und beschlossen, dass der einfachste Weg, die Speicherfehler zu beheben, darin besteht, den Swap auf 4 GB zu verdoppeln. Der Nachteil ist, dass auf einem 1-GB-Droplet nur 25 GB SSD vorhanden sind, sodass der Verlust von 4 GB für Swap eine erhebliche Menge an Speicherplatz darstellt und es mit nur 25 GB bereits etwas eng ist.
Sollten wir also discourse-setup ändern, um den Standard auf 3 GB festzulegen?
Was denkst du, @Falco?
Wenn das das Problem löst, bin ich ganz dafür.
Kann ich dringend empfehlen, dass das Installationsskript auch die beiden Kernel-Tunables festlegt, die die Speicherverwaltung beeinflussen? Es wäre gut zu wissen, dass jeder, der anscheinend ein Problem hat, zumindest einen Ausgangspunkt für eine gute Kernel-Einrichtung hat.
Das erscheint mir eine vernünftige Idee. Ich kann mir nicht vorstellen, wo THP auf einer dedizierten Discourse-Instanz von Nutzen sein könnten, und Overcommit kann helfen, OOM zu vermeiden.
Man könnte erwägen, jeden dieser Punkte separat anzubieten und sie als Standardantwort festzulegen, wobei die nicht standardmäßige Option zum Abwählen besteht.
Außerdem könnte das Skript sysctl verwenden, um herauszufinden, ob die Einstellungen überhaupt geändert werden müssen, bevor eine Änderung vorgenommen wird. Wenn jemand diese Änderungen bereits mit anderen Dateien vorgenommen hat, wäre es potenziell verwirrend, doppelte Überschreibungen zu erstellen. Ich denke, dass nicht alle Linux-Distributionen standardmäßig mit deaktiviertem Memory Overcommit ausgeliefert werden.
if $(sysctl -n vm.overcommit_memory) != 1 ; then
....
fi
Obwohl die Gefahr besteht, die wichtige Botschaft über Kernel-Tunables zu verwässern, gibt es eine zweite Überlegung: Das aktuelle Skript erstellt nur Swap auf einem Rechner mit wenig RAM. Ich halte das für einen Fehler, sowohl weil Swap immer noch nützlich ist, um die Auslastung des RAMs zu maximieren, als auch, und das ist wichtiger, weil es Probleme verursachen wird, wenn jemand sein Discourse auf einem Rechner mit viel RAM erstellt, aus Gründen der Geschwindigkeit oder Bequemlichkeit, und es dann auf einen Rechner mit wenig RAM verkleinert.
Die Einrichtung sollte in allen Fällen Swap erstellen (es sei denn, es ist bereits genug vorhanden). Es ist gültig und manchmal nützlich, mehrere Swap-Dateien zu haben.
Ich entscheide nicht, und ich setze diese auf Maschinen, die ich einrichte, aber dies ist ein Shell-Skript, das von (meistens) jedem ausgeführt wird, der Discourse installiert. Es muss so einfach wie möglich sein, und wir sind sicher, dass diese Einstellungen auf Raspberry Pi und Mac und was auch immer für Unsinn Leute versuchen zu tun, funktionieren? Und jede Methode, die Sie verwenden, um zu testen, ob sie bereits festgelegt ist, funktioniert auf all diesen Plattformen? Scheint schwierig.
Ich habe discourse-setup geschrieben und es macht mir ein wenig Angst, Änderungen daran vorzunehmen.
Das Anbieten, Swap zu erstellen, ist keine schlechte Idee. Vielleicht immer anbieten, 3 oder 4 GB Swap einzurichten? Aber wie viel dann? Eine Faustregel, die ich einmal kannte, war, Swap so groß wie RAM zu haben. Und im Moment ist Ihre einzige Option, Strg+C zu drücken, wenn Sie keinen Swap erstellen. Also entweder zwingen wir die Leute, Swap zu erstellen, oder wir fügen eine weitere Ja/Nein-Frage hinzu (was dazu führt, dass ich meine Skripte ändere, die discourse-setup ausführen 
). Oh! Oder wir können es über einen --skip-swap-Schalter steuern. Das scheint mir in Ordnung zu sein. Wenn Sie schlau genug sind, um über Swap Bescheid zu wissen, können Sie den Schalter finden, um ihn zu überspringen; wir können eine Notiz über den Schalter in diese WARNUNG aufnehmen.
Und vielleicht auch eine Notiz über --skip-connection-test hinzufügen, wenn dieser fehlschlägt.
Ich denke, wenn sie bereits Swap eingerichtet haben, kann man davon ausgehen, dass sie wissen, was sie tun.
Danke! Und ja, vollkommen verstanden, ich würde genauso fühlen. Es erfordert sicherlich sorgfältige Überlegung und Tests. Und das würde auf mindestens ein paar günstigen Maschinen von Hosting-Anbietern und auch auf dem Pi geschehen. Ich bin mir bei Windows oder Mac nicht sicher – wenn sie unterstützt werden sollen, dann wohl. Ich würde eher erwarten, dass sie als Entwicklungsmaschinen verwendet werden, was eine andere Geschichte ist.
In der Tat. Was auch immer derzeit notwendig erscheint, vielleicht. Es scheint einen Schritt nach vorne zu machen. Aber es schmerzt mich sehr, nicht zu wissen, ob diese Berichte den Overcommit-Tweak enthalten oder nicht. Ich bin ziemlich sicher, dass wir aus früheren Diskussionen wissen, dass Overcommit einen Unterschied macht.
Und wir wissen, dass auf einer 25G-Instanz und noch mehr auf einer 20G-Instanz der Speicherplatz knapp ist. Ich betreibe solche Maschinen: 25G-Festplatte und 1G-RAM, was bereits 2G Swap benötigt und heutzutage wahrscheinlich mehr; und 20G-Festplatte mit 2G-RAM, wo ich derzeit 1G Swap habe.
Ich würde nicht mehr Ja/Nein-Fragen empfehlen. Kommandozeilenoptionen scheinen ein besserer Weg zu sein.
Wenn wir dieses Skript überhaupt ändern wollen, würde ich mehrere 1G-Swap-Dateien empfehlen, da dies die Flexibilität maximiert, nichts verschwendet und es am einfachsten ist, diese Entscheidung zu treffen.
Da bin ich mir nicht so sicher. Wenn die kleinste Instanz mit nacktem Ubuntu oder Debian bereits etwas Swap hat – das müsste überprüft werden –, dann haben wir Probleme, wenn es nicht genug ist. Viel besser ist es, RAM+Swap mit free zu messen, wie üblich für die Konfigurationen unter 1G anzupassen (ich glaube AWS, vielleicht Oracle) und dann 1G-Swap-Dateien bis zu einer vereinbarten Anzahl hinzuzufügen, was auch immer das derzeit ist. Hoffentlich reichen insgesamt 4G, mit dem Kernel-Overcommit entsprechend eingestellt.
Ich helfe gerne.
Hmm. Ja. Ich wünschte, ich hätte daran gedacht, das bei denjenigen zu überprüfen, die ich gerade angepasst habe.
Hmm. Ich bin der Meinung, dass eins besser ist, aber mehrere erhöhen die Flexibilität und es wäre dann möglich, discourse-setup dazu zu bringen, eine weitere Swap-Datei hinzuzufügen, wenn mehr Swap benötigt wird, was bedeutet, dass wir jedem sagen könnten, discourse-setup auszuführen, um sein Swap-Problem zu “beheben”. Und vielleicht auch das Overcommit-Problem – vielleicht versuchen wir explizit, dies nur für Linux zu tun, da uns das alles interessiert.
Ich stimme nicht zu. Swap ist kein universelles Gut. Früher war es wichtig, um VM-Code gleichmäßiger zu gestalten, wenn unter bestimmten Umständen nicht getauscht wurde, aber die VM-Algorithmen haben sich geändert.
Das basierte auf sehr alten Kernel-Code-Heuristiken, die nicht mehr gelten.
Auch wenn man die Messung betrachtet: Ich weiß nicht einmal, was man messen möchte, um Swap und Speicher zu messen, wenn zswap verwendet wird. Dies ist jedoch wahrscheinlich ein Fall von „zuerst keinen Schaden anrichten“.
Ich bin ziemlich sicher, dass der einzige Nachteil von „zu viel Swap“ darin besteht, mehr Festplattenspeicher als unbedingt nötig zu verbrauchen. Das ist ein Grund, warum es vorzuziehen wäre, mehrere bescheidene Swap-Dateien zu haben – man kann sie nach und nach mit swapoff entfernen, wenn der Festplattenspeicher wieder freigegeben werden muss. Außerdem glaube ich, dass Linux sie recht gut progressiv nutzt:
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 863.6M -2
/var/local/swap/swapfile.0 file 1024M 4.6M -3
Die Situation, in der wir uns befinden, ist, dass günstige Instanzen sowohl im RAM als auch im Festplattenspeicher recht begrenzt sind und Discourse mit der Weiterentwicklung der vielen darin enthaltenen Pakete immer mehr davon benötigt. Aber ich denke, es gibt Wege, dies klug zu navigieren, um denen zu helfen, die nicht in der Lage sind, einfach die Hände zu heben und ihre monatliche Rechnung zu verdoppeln oder zu vervierfachen.
Das Swapping ist langsam genug, dass ich „kaum noch Platz übrig“ nicht als Grund anführen würde, mehr als 1 GB zum Standardvorschlag hinzuzufügen. Jeder 1 GB ist viel Swap, wie auf einer dedizierten Discourse-Instanz erfahren.
Ja, standardmäßig verwendet Linux Swap in der Reihenfolge der Priorität, und es ist möglich, die gleiche Priorität für mehrere Geräte zu verwenden, um Swap explizit zu stripen. Aber das Hinzufügen von viel Swap für kleine Websites ist meiner Meinung nach nicht besonders wertvoll.
Wenn also nach etwa einem Jahrzehnt die Leute nur gelegentlich über 2 GB stolpern, würde ich vorschlagen, eher auf 3 GB als auf 4 GB als Standard zu gehen. Und die notwendige Menge an Swap für eine dedizierte Discourse-Instanz sollte mit zunehmendem Speicher nicht besonders ansteigen, da sich der Inhalt, der tatsächlich ausgelagert würde, nicht wesentlich ändert.
Die Idee, Swap mit mehr Speicher zu vergrößern, stammt hauptsächlich aus der allgemeinen Computerverwendung, basierend auf der allgemeinen Annahme, dass je mehr RAM Sie benötigen, desto größer ist wahrscheinlich die Nachfrage. Aber der Swap-Druck auf einer spezialisierten Discourse-Instanz wird dieses Muster wahrscheinlich nicht befolgen, denke ich.
THP sind spezifisch für Plattformen, die riesige Seiten unterstützen, was nicht alle Plattformen sind. Der generische Weg, damit umzugehen, ist zu sehen, ob es existiert. Auf einem Raspberry Pi, den ich habe:
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255
Im Gegensatz dazu ist Overcommit seit Jahrzehnten ein allgemeiner VM-Parameter für Linux. Auf demselben Raspberry Pi:
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
Das Parsen der Ausgabe von free in der Shell ist etwas mühsam. Als ursprünglicher Autor von procps würde ich dafür einfach nach SwapFree in /proc/meminfo suchen. 
Ich stimme zu, dass in unseren kostenbeschränkten Welten die Skalierung von Swap nach RAM-Größe kein guter Plan mehr ist. Die nächste Idee danach war historisch gesehen, dass RAM riesig ist und man keinen Swap braucht. Danach kommt die Weisheit, dass etwas Swap nützlich ist, weil es eine bessere Nutzung von RAM ermöglicht. (In einer uneingeschränkten Welt haben wir einfach riesige Mengen an RAM, aber das ist eine Nische.)
Was wir in den letzten Monaten gesehen haben, ist, dass mehr Leute Speicherprobleme und Fehler beim Wiederaufbau haben. Mehr Leute stellen fest, dass Web-Upgrades fehlschlagen, aber die Befehlszeile funktioniert. Aus einer einfachen Support-Perspektive und aus der Perspektive des Rufs des Produkts denke ich, dass wir eine Änderung der üblichen Ratschläge und der üblichen Einrichtung vornehmen müssen. Ich denke, 3 GB Swap sind die einfachste und kleinste Änderung, und das sollten wir tun, wenn wir nichts anderes tun.
Aber ich denke immer noch, dass mehrere kleinere Swap-Dateien eine klügere Wahl sind – und wir haben hier Support-Threads gesehen, die darauf hinweisen. Und ich denke immer noch, dass es am besten wäre, zu versuchen, RAM + Swap zu dimensionieren, da dies der limitierende Faktor ist, das, was die Leute in Schwierigkeiten bringt. Es mag sein, dass es verschiedene Möglichkeiten gibt, diese Berechnung durchzuführen. Die üblichen Vorbehalte gelten für die Taktiken, die wartbar, verständlich und langlebig sind.
Was transparente riesige Seiten angeht, verstehe ich, dass es das „transparente“ ist, das Probleme verursacht: Der Kernel kann sich zusammenziehen und de-zusammenziehen, für Leistungseinbußen und keinen großen Nutzen. Ich bin mir ziemlich sicher, dass riesige Seiten für kleinere Systeme nicht ratsam sind.
Es geht mehr um die Eigenschaften der Workload als um die Größe des Systems. Auf einem System mit 1 GB RAM und ziemlich stabilen Prozessen mit RAM-Blöcken können die Standard-2-MB-Hugepages das TLB-Thrashing reduzieren und die Leistung verbessern; die TLB deckt die Zuordnungen für 1 GB RAM noch nicht ab. Es ist im Allgemeinen nur ein Kompromiss zwischen der CPU, die damit beschäftigt ist, Speicher zum Zusammenfassen zu finden, und TLB-Cache-Fehlern, und es gibt viele Workloads auf 1-GB-Maschinen, die erheblich von THP profitieren können. (Viele Empfehlungen, es zu deaktivieren, stammen aus der frühen Phase seiner Implementierung; es wurde seitdem erheblich verbessert.) Die Empfehlung, THP für Discourse zu deaktivieren, liegt nicht an der Größe von 1 GB RAM, sondern ist spezifisch für die Verwendung von Redis mit Persistenz auf der Festplatte, was Discourse verwendet:
https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages
Leider, wenn ein Linux-Kernel transparente riesige Seiten aktiviert hat, erleidet Redis eine große Latenzstrafe nach dem
fork-Aufruf, um auf der Festplatte zu persistieren. Riesige Seiten sind die Ursache für das folgende Problem:
…