Speicher, CPU und Festplatte dimensionieren #

Diese Seite ist für Systemadministratoren und Produktmanager bei einem Hosting-Anbieter, die Server und Tarife für Exponential-Websites dimensionieren. Sie beantwortet: welche Zahlen die Dokumentation und die Einstellungen des Projekts tatsächlich nennen, was auf einer laufenden Website Arbeitsspeicher, CPU und Festplatte verbraucht und wie Sie eine echte Website messen. Sie nennt keine Zahlen, die das Repository nicht nennt; Kapitel 2.10 sagt dasselbe: Die Dokumentation nennt wenige harte Zahlen, und das Buch erfindet keine weiteren.

Inhalt #

1. Die Zahlen, die das Repository nennt
2. Arbeitsspeicher
3. CPU
4. Festplatte
5. Messen, nicht raten
6. Aus Messungen Tarife machen
7. Checkliste
8. Verwandte Seiten

Die Zahlen, die das Repository nennt #

Arbeitsspeicher #

Was auf einem Server mit Exponential-Websites Arbeitsspeicher verbraucht:

• PHP-Prozesse. Jedes PHP-FPM-Kind oder jeder Velocity-Worker in der Spitze bis zu seinem memory_limit; Paketinstallationen, Importe und Bildarbeit brauchen am meisten. Planen Sie die Pool-Größen so, dass der geschäftigste Moment hineinpasst (Abstimmung von PHP-FPM).
• Velocity-Worker halten ab dem Moment, in dem sie geforkt werden, je etwa 10 MB privaten Speicher, ob untätig oder nicht. Mit SpareWorkers hält der Pool in ruhigen Zeiten nur so viele und wächst unter Last bis Workers, wobei er untätige Worker nach IdleWorkerTimeout Sekunden beendet.
• Gemeinsame Caches. OPcache (opcache.memory_consumption) und APCu (apc.shm_size) reservieren gemeinsamen Speicher. PHP-FPM nimmt sie aus seiner php.ini; Velocity setzt seine eigenen in velocity.ini [PHPSettings] IniOptions[], weil der Standard der Kommandozeile für APCu 32 MB beträgt, zu wenig für seinen Antwort-Cache und den SQL-Abfrage-Cache zusammen.
• Die Datenbank. Der Seitencache von SQLite zählt pro Prozess, der sie genutzt hat: SQLitePragmas[]=cache_size=-16384 senkt ihn auf 16 MB, was auf Servern mit vielen kleinen SQLite-Websites hilft. Datenbankserver brauchen ihre eigene Dimensionierung.
• Optionale Dienste. Solr, Valkey oder Redis, wenn ein Tarif sie enthält.

Hinweis Lesen Sie den Speicher von Velocity so, wie sein Kontrollzentrum ihn zeigt: als Proportional Set Size (PSS) des Elternprozesses und seiner Worker. Die Resident Set Size (RSS) jedes geforkten Workers zählt den gemeinsam genutzten Speicher immer wieder mit und summiert sich zu weit mehr, als die Maschine tatsächlich nutzt (Kapitel 2.10).

CPU #

• Zwischengespeicherte Seiten kosten wenig. Der Antwort-Cache von Velocity beantwortet anonyme Besucher im Serverprozess ohne Worker. settings/velocity.ini hält eine Messung fest: Ein Server beantwortet zwischengespeicherte Seiten mit etwa 0,3 ms CPU je Seite, etwa 3.500 pro Sekunde auf einer Maschine mit 12 Kernen; mit Instances über 1 verteilt der Kernel Verbindungen auf mehrere Server (zwei gemessen 6.600 bis 6.900, vier 12.200 bis 13.100). Gerenderte Seiten sind durch die Worker begrenzt, nicht dadurch.
• Gerenderte Seiten (erste Aufrufe nach dem Leeren, angemeldete Redakteure, Suche) verbrauchen die CPU. Lassen Sie den Content-View-Cache und den Template-Block-Cache an (beide mitgeliefert), und lassen Sie den statischen Cache aus (Kapitel 10.12).
• OPcache zählt. Unter Velocity ließ opcache.file_update_protection über 0 ein Rendering etwa das Vierfache der CPU kosten, die es unter PHP-FPM braucht; die mitgelieferte velocity.ini setzt es auf 0 (Opcode-Cache von Velocity).
• FrankenPHP-Threads sind standardmäßig doppelt so viele wie CPU-Kerne, wenn [FrankenPHPSettings] Workers leer ist.
• Cron und Bildarbeit bringen Lastspitzen: Bildvarianten werden bei der ersten Verwendung erzeugt, und die Cronjobs laufen nach Zeitplan.

Festplatte #

Die Festplattenprüfung der Administration (Setup > Systeminformationen) schlägt unter 1 GB oder 5 % frei fehl und warnt unter 5 GB oder 10 %; nutzen Sie dieselben Schwellen in Ihrer Überwachung. Siehe auch das Runbook bei voller Festplatte.

Messen, nicht raten #

php bin/php/console exp:benchmark --save=var/benchmark/base.json --allow-root-user
php bin/php/console exp:benchmark kernel --repeat=30 --allow-root-user
php bin/php/console exp:system:info --json --allow-root-user
du -sh var/storage var/cache var/log

exp:benchmark ruft die Startseite, Menüseiten, die Suchseite und die Anmeldeseite der Administration ab und gibt Median, p90 und p99 aus; gegenüber anderen Hosts ist es standardmäßig zurückhaltend (Benchmarking). exp:system:info gibt die Fakten und Zustandsprüfungen von Setup > Systeminformationen aus (Speichergrenze, OPcache und APCu, Festplatte, Arbeitsspeicher und Last der Maschine). Das Kontrollzentrum von Velocity zeigt den Speicher des Pools.

Tipp Bauen Sie eine Referenz-Website nach Ihrem häufigsten Tarif, messen Sie sie mit diesen Befehlen auf Ihrer Hardware, und dimensionieren Sie danach. Eine auf Ihren eigenen Servern gemessene Zahl ist mehr wert als jede Faustregel.

Aus Messungen Tarife machen #

Das Repository nennt keine Tarifgrößen und keine Preise; dies sind die Dimensionen, für die ein Hoster Grenzen festlegen kann, jede mit den Befehlen oben messbar:

Checkliste #

• To do: memory_limit 256M oder mehr für Produktions-Pools.
• To do: Workers von Velocity ausdrücklich gesetzt; SpareWorkers auf ausgelasteten Servern mit mehreren Websites erwogen.
• To do: Größen von OPcache und APCu für PHP-FPM und für Velocity getrennt gesetzt.
• To do: Speicher von Velocity als PSS gelesen.
• To do: Festplattenüberwachung mit den Schwellen der Systeminformationen.
• To do: Eine Referenz-Website auf Ihrer eigenen Hardware gemessen.

Verwandte Seiten #

• Anforderungen auf einen Blick
• Cache-Schichten und Benchmark einer gehosteten Website
• Velocity-Worker und Pools
• Hosting-Tarife gestalten
• Kapitel 2.10: Arbeitsspeicher, CPU und Festplatte
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.