Es ist normal, dass ein einzelner Pitchfork-Prozess den Großteil der Last bearbeitet – andere Prozesse werden nur dann herangezogen, wenn der erste beschäftigt ist. Es ist ebenfalls normal, dass der Speicherverbrauch im Laufe der Zeit zunimmt. Er sollte jedoch nach einer Weile einen stabilen Zustand erreichen, sobald alles, wie z. B. Caches und Ruby-JIT, hochgefahren ist.
Hier ist ein Graph aus einem unserer Produktivcluster über einen Zeitraum von 7 Tagen. Er zeigt den einzelnen Prozess mit dem höchsten Speicherverbrauch. Die grünen gepunkteten Linien kennzeichnen Deploys (d. h. Neustarts von Pitchfork):
Man sieht also, dass der Verbrauch nach dem ersten Start zunimmt, dann aber bei knapp unter 1,4 GB stabil bleibt. Dieser Cluster bedient Hunderte von Websites, daher ist er in Bezug auf die nackten Zahlen vielleicht nicht der beste Vergleichsmaßstab… aber die Visualisierung des Wachstums sollte hoffentlich hilfreich sein.
Die RSS-Werte pro Prozess erzählen nicht die ganze Geschichte. Pitchfork ist ein „forking web server“. Er startet also den „Mold“-Prozess, und alle Worker werden daraus mittels eines Copy-on-Write-Speichermusters abgeleitet. Während der RSS-Wert für worker[0] beispielsweise 500 MB anzeigen mag, sind etwa 200 MB davon mit dem Mold und allen anderen Workern geteilt.
In nicht allzu ferner Zukunft hoffen wir, die „Reforking“-Funktion von Pitchfork aktivieren zu können. Sie tötet regelmäßig Worker und leitet sie von einem bereits hochgefahrenen Worker neu ab, sodass sie im Laufe der Zeit so viel Speicher wie möglich teilen. Dafür müssen wir jedoch noch sicherstellen, dass unser gesamter Code mit diesem Muster kompatibel ist 