Fehler in der Produktion behoben – Ticket geschlossen. Benutzer sehen den Fehler immer noch. CDN-Cache? Leer. Opcode? opcache.validate_timestamps=0 aus einer „Leistungs“-Einstellung: Die PHP-Dateien werden auf der Festplatte aktualisiert, aber der alte Bytecode bleibt vierzig Minuten bis zum panischen Neustart von PHP-FPM bereitgestellt.
OPcache ist eine Beschleunigung – es wird in der Produktion schlecht verwaltet und ist ein Code-Cache, der Ihre Bereitstellungen ignoriert. Das Problem besteht nicht darin, „den Cache zu leeren“. Es synchronisiert die Veröffentlichung auf der Festplatte und den PHP-Workern, ohne eine 502-Kaskade auszulösen.
Gesunder Bereitstellungszyklus
Eine zuverlässige PHP-Bereitstellung folgt einer dokumentierten Reihenfolge:
- Atomic Release: „/releases/20260719/“ plus Symlink „current“.
- Installation zusammenstellen, Migrationen, Vorwärmen des Anwendungscaches.
php artisan Optimizeoder Symfony-Cache, falls zutreffend.- PHP-FPM neu laden:
systemctl reload php8.2-fpm(graceful). - Rauchtest am Gesundheitskontrollpunkt.
- Rücktaste = Symlink wiederherstellen und neu laden.
Beim „Neuladen“ werden die Arbeiter nach und nach wiederverwendet – aktuelle Anfragen enden; Neue Worker laden einen neuen OPcache. Ein plötzlicher „Neustart“ führt zum Herunterfahren; „reload“ ist die bevorzugte Wahl für eine unterbrechungsfreie Bereitstellung.
Neustart brutal versus Neuladen anmutig: Der erste unterbricht den Dienst; der zweite behält aktuelle Verbindungen bei.
validate_timestamps: Der Kompromiss, den es zu verstehen gilt
| Einstellung | Verhalten | Verwendung |
|---|---|---|
validate_timestamps=1 | stat() in der Datei, wird neu kompiliert, wenn sich mtime ändert | Entwicklung, Vorproduktion |
validate_timestamps=0 | Überprüfen Sie die Festplatte niemals erneut | Produktion plus Nachladen bei jedem Einsatz |
Mit „revalidate_freq=0“ und „validate=1“ überprüft jede Anfrage die Festplatte – eine unnötige E/A-Last in der Produktion. Das Paar „validate_timestamps=0“ plus geskriptetes FPM-Neuladen ist der Standard für Teams, die mehrmals pro Woche bereitstellen.
Invalidierungsstrategien
A – FPM-Neuladen (empfohlen) Schritt nach der Bereitstellung im Skript: „systemctl reload php-fpm“. Einfach, vorhersehbar, ohne große Unterbrechungen.
B – „opcache_reset()“ in der Befehlszeile nach der Bereitstellung Über One-Shot-SSH – akzeptabel, wenn nur ein PHP-FPM-Pool vorhanden ist. Niemals in einer HTTP-Anfrage.
C – Schrittweise Bereitstellung auf N Servern Load Balancer im Drain → Bereitstellung → Neuladen → Reaktivierung. Keine Ausfallzeit auf einem Cluster.
D — opcache.file_cache Zweite Ebene auf der Festplatte – achten Sie während der Bereitstellung auf die Synchronisierung zwischen den Knoten.
Fallen und Container in mehreren Versionen
- Blau-grün mit zwei Releases: gemischte Worker bei teilweisem Neuladen – Schließen Sie das Neuladen auf allen Knoten ab, bevor Sie den Datenverkehr wechseln.
- Vorabladen von PHP 7.4+: Eine Änderung der Vorabladedatei erfordert einen vollständigen Neustart, nicht ein einfaches Neuladen.
- Docker: neues Image = neuer Container, frischer OPcache. Volume-Mount für Code = dasselbe „validate_timestamps“-Problem.
Bei Shared Hosting kein Self-Service-FPM-Neuladen – FTP-Bereitstellung mit „validate_timestamps=1“ oder Support-Ticket. Ein Grund mehr für einen VPS oder PaaS, wenn Sie häufig bereitstellen.
Der Gipfel: OPcache ohne Bereitstellungsverfahren ist unbeabsichtigtes A/B-Testen
Hier ist, was die „Leistungs“-Einstellungen vergessen zu dokumentieren.
Checkliste für die PHP-Bereitstellung: Symlink plus FPM-Neuladen dokumentiert – nicht „Wir laden hoch und hoffen“.
Entscheide dich und gehe ohne blinden Fleck voran
Innerhalb eines halben Tages können Sie Ihre PHP-Bereitstellungen sichern:
- Übergeben Sie „validate_timestamps=0“ in der Produktion mit skriptgesteuertem FPM-Neuladen.
- Einrichten einer atomaren Bereitstellung per Symlink.
- Machen Sie einen Rauchtest nach dem Aufladen zur Pflicht.
- Verbieten Sie „opcache_reset()“ in Web-Endpunkten.
- Planen Sie eine schrittweise Bereitstellung, wenn Sie über mehrere Server verfügen.
Dokumentieren Sie die vollständige Sequenz in Ihrem Bereitstellungs-Runbook: Wer initiiert das Neuladen, wie überprüft man, ob alle Worker recycelt wurden, und welcher Test bestätigt, dass der neue Code erfolgreich bereitgestellt wird. Querverweis mit PHP Profiling, um die Auswirkungen einer schlechten Bereitstellung zu messen, und Blue-Green-Bereitstellung für Architekturen mit mehreren Instanzen.
Häufig gestellte Fragen
Warum wird der alte Code nach der Bereitstellung ausgeführt?
OPcache behält den kompilierten Bytecode im Speicher. Mit „validate_timestamps=0“ lösen geänderte Dateien auf der Festplatte kein Neuladen aus, bis ein Worker über ein FPM-Neuladen wiederverwendet wird.
Ist opcache_reset() im Produkt sicher?
Nein in der Webanfrage – es ist ein brutaler globaler Reset. Bevorzugen Sie ein ordnungsgemäßes Neuladen von PHP-FPM oder einen Befehlszeilen-Reset nach der Bereitstellung unter Ausschluss des Benutzerverkehrs.
validate_timestamps=1 in der Produktion?
In der Vorserie möglich. In der Produktion werden dadurch jedem Include stat()-Aufrufe hinzugefügt. Der übliche Kompromiss bleibt „validate_timestamps=0“ plus FPM-Neuladen bei jeder Bereitstellung.
Hilft die atomare Bereitstellung?
Ja. Der Symlink-Umschalter plus FPM-Neuladen synchronisiert alle Worker im selben Dateibaum, ohne alte und neue Versionen zu vermischen.
Wenn OPcache nach einer Bereitstellung nicht zur Party eingeladen wurde, verwalten Sie zwei Versionen der Site – eine in Git, eine im RAM.