Opcache precompile

Grad hatte ich ja davon erzählt, dass ich wissen wollte, wie groß die PHP-Scripte in einer bestimmten Hierarchie sind.

Das habe ich jetzt für ein paar andere Verzeichnisbäume durchgelutscht und bin auf das Ergebnis gekommen, das

Opcache-Limit einzustellen 😀

Nun ja. Ganz fürchterlich großes Kino, eine Konfigurationsdatei anpacken und fertig.

Möchte man meinen, ja.

Aber doch nicht mit dem Dicken. Da gibt es doch so fürchterlich viele lustige Schalterchen, an denen man herumspielen kann, also suchen wir doch einfach mal eine Einstellungskombination, die möglichst maximalen Nutzen bei minimalem Schaden Speicherverbrauch möglich macht.

Was wollen wir?

Wir wollen sämtliche und alle noch so unnützen PHP-Scripte, die irgendwann und irgendwie mal ausgeführt werden, im OpCache haben.

Stecken wir uns doch einfach mal vernünftig hohe Ziele 🙂

Was wissen wir?

Zunächst mal, wir haben uns gerade die Größen besorgt, die unsere PHP-Scriptdateien insgesamt haben.

In meinem Fall waren das so 140MB und ’nen bisschen Kleingeld. Unterstellen wir des Weiteren, das die Scripte vollständig inklusive dem ganzen Müll (also den fast immer sinnlosen Kommentaren… was hab ich davon, wenn mir jemand sagt, dass jetzt sofort eine Schleife losgeht – statt mir zu sagen, wieso). Denn die Erfahrung lehrt, wenn die Kommentare beim Cachen abgeklemmt werden (was möglich ist), läuft nicht mehr alles, weil irgendein Held auf irgendwelche Kommentare angewiesen ist.

Ich könnte manchmal so brechen… wie auch immer. Ist halt so.

Und was wir auch noch wissen, naja, ich weiß es, ihr noch nicht – die Anzahl der PHP-Scripte. Das bekommt ihr hin, oder? Ich hab das so gemacht:

find . -type f -name '*.php' | wc -l

Das spuckt mir aus, wie viele Zeilen Output der find geworfen hat – und die wiederum entspricht dann der Anzahl der PHP-Dateien. Geht sicher eleganter, aber „it gets the job done“ und muss nicht erst durch ein Gremien beraten und durch ein weiteres beschlossen werden – „einfach mal machen“, meine Devise (…und manchmal hinterher doch noch mal nachdenken…).

Ach so, das Ergebnis. Bei mir waren es so 10.000 Dateien.

Wie…?

Mit vim.

Ok – jetzt mal im Ernst, WIE???

Hmpf. Ok.

vim /usr/local/etc/php56/conf.d/opcache.ini

Und bei der Anzeige erst mal einen frischen Kaffee holen und auf dem zweiten Bildschirm (ein dritter wäre mal eine Maßnahme) schon mal Google anwerfen und jede einzelne Option nachrecherchieren.

Ja wirklich. Jede. Und auch die, die nicht in der Standard-Konfiguration steht. Denn da sind wahre Schätze verborgen 😀

Ok. Dann eben nicht, ich finde es ja immer total spannend die ganzen Optionen auszuprobieren…

Endergebnis

In meinem Fall kam ich mit folgendem Erguss heraus, da ist vermutlich immer noch Spielraum für mehr Nerdyness, aber so tut es es erstmal und nimmt akzeptable Resourcen in Anspruch.

zend_extension = opcache.so

[opcache]
opcache.enable = 1
opcache.enable_cli = 0
opcache.memory_consumption = 196
opcache.interned_strings_buffer = 64
opcache.max_accelerated_files = 12288
opcache.max_wasted_percentage = 10
opcache.use_cwd = 1
opcache.validate_timestamps = 1
opcache.revalidate_freq = 30
opcache.revalidate_path = 0
opcache.save_comments = 1
opcache.enable_file_override = 1
opcache.optimization_level = "0xffffffff"
opcache.inherited_hack = 1
opcache.dups_fix = 0
opcache.blacklist_filename =
opcache.max_file_size = 0
opcache.consistency_checks = 0
opcache.force_restart_timeout = 180
opcache.log_verbosity_level = 0
opcache.preferred_memory_model =
opcache.protect_memory = 0
opcache.mmap_base =
opcache.restrict_api =
opcache.enable_file_override = On
opcache.file_cache = "/var/opcache/cache.dat"

Die Fetten sind die, auf die es wirklich ankommt. Die Roten (ok und Fetten) sind die, bei denen ich noch überlege, ob ich mir ein kleines Auswertungsscript schreiben soll, das die maximal und mit machbarem Aufwand parsbaren, konstanten Strings aus den Scripten extrahiert und die Längen dann summiert… hebe ich mir für heute Nacht auf – nicht.

Die memory_consumption muss man leider aus mir nicht erklärbaren Gründen locker mal doppelt so hoch wählen wie die tatsächliche Scriptgröße. Auch noch eine offene Baustelle:

  • Klären, wieso memory_consumption so viel höher eingestellt werden muss.

Kleiner Pro-Tipp: Nicht das fast-shutdown aktivieren!!11eins. Das shreddert ziemlich schwer bemerkbar und nur in seltsam seltenen Situationen die Verarbeitung. Mal ganz abgesehen davon:

If enabled, a fast shutdown sequence is used that doesn’t free each allocated block, but relies on the Zend Engine memory manager to deallocate the entire set of request variables en masse.

Sich auf die Garbage Collection der Runtime zu verlassen hat irgendwie was von Java. Und da haben wir was gegen (*duck* & *weg*).

Du hast alles falsch gemacht, Mirko!

Falls jemandem auffällt, dass ich den Opcache dazu anhalte, dass er alle 30 Sekunden nachsieht, ob ein Script vielleicht zwischenzeitlich auf der Platte geändert wurde und erneute in den Cache geladen werden sollte – ja, das trifft zu. Ist auch besser so in einer Umgebung, die ständig von einem bestimmten, seltsamen Menschen befummelt wird und der nicht ständig den Opcache neu per Hand befüllen möchte.

Optimierungsorgie Teil 2

Wie vorhin schon mal erwähnt, habe ich in den letzten zwei Wochen einige Optimierungsarbeiten an unserer MySQL-Datenbank vorgenommen.

Unsinn hoch Drei – Probierphase

Interessanterweise waren viele der Maßnahmen völlig für den Eimer – das habe ich aber erst seeeeehr spät festgestellt.

Beispiele

  • mysqltuner.pl immer wieder laufen lassen, der mir stoisch eine Erhöhung der tmp_table_size (und damit auch max_heap_table_size) empfiehlt.
  • Empfehlung, den innodb_buffer_pool_size auf 80% des installierten Arbeitsspeichers in den Wind geschlagen (20% für PHP? Nie im Leben) und gegen 50 und 60% getauscht.
  • query_cache an – und wieder aus – und wieder an – und wieder aus – man ist sich da im Expertennetz nicht einig: Einige verteufeln, andere bringen wieder den Standardspruch „your milage may vary“.
  • diverse Buffer hoch und wieder runter – meistens hoch

Irgendwann war dann die Datenbank so aufgeblasen, dass nur noch 2 oder 3 PHP-Instanzen ausführbar gewesen wären, wenn meine NAS mich das denn hätte so stark begrenzen lassen. Da ich für php mal sportlich

memory_limit = 300M

vorgesehen hatte (man weiß ja, WordPress mag es gerne ausufernd – falsch… aber das wusste ich da noch nicht) und in der Tat sich die PHP-Prozesse gerne mal so um die 200M reingetan haben, war irgendwann auch für den Mathe-Versager Mirko klar: Das passt alles nicht rein.

Hier liefen also ein halbes Dutzend PHP-Prozesse, eine Datenbank, mit der ich vermutlich die Deutsche Bank hätte versorgen können, ein OpCode-Cache, in den sämtlich 15.000 PHP Scripte reingepasst haben und noch diverse andere Dinge, die zusammen vermutlich so 12 bis 16GB Arbeitsspeicher hätten haben wollen – und ein paar lustige CPU-Kerne gleich noch oben drauf.

Katastrophenalarm – Wir werden geDDOSed.

Eines Morgens so gegen 11 dann der wahrgewordene Alptraum: Unser Webserver wird angegriffen!!!1eins

Wir verzeichnen dutzende Anfragen gleichzeitig, alle landen in getrennten PHP-Prozessen (soso, plötzlich können da auch 20 Prozesse gespawned werden, obwohl die Begrenzung viel niedriger lag). Die Datenbank braucht für Ömmelsabfragen plötzlich 70 Sekunden und mehr (vorher: Bruchteile einer Sekunde!).

Also ich per SSH in den Server (wie praktisch, dass ich auf dem Server ein renice-Script laufen habe, dass mir alle paar Minuten die SSH- und anderen kritischen Prozesse auf bequemere Prioritäten schiebt) und mit sehr viel Geduld im Minutenbereich die Datenbank freundlich um Beendigung gebeten. Daraufhin dann auch gleich den Webserver (der sowieso ohne Datenbank lustige Ausfälle zeigt bis hin zum Verzweiflungsselbstmord).

Puh. Intrusion Prevention auf die NAS gebügelt, irgendwer muss mal den Türsteher machen (Firewall wäre naheliegend, aber mit dem Käse läuft dann grad mal gar nix mehr so richtig – auch eine Möglichkeit Ruhe zu haben…). Die wiederum lutscht sich auch knapp 600 bis 800MB Arbeitsspeicher, wovon wir bekanntlich eigentlich schon im Zehnerpotenzbereich zu wenig haben.

Dann war Ruhe.

Nächster Tag – geht schon wieder los!

Am nächsten Morgen, wieder so gegen 11 – der nächste Angriff.

Da ich zwei Tage vorher eine Hoax-Mail mit der Bitte um Überweisung eines frechen Betrags erhalten habe mit der Ankündigung mir im Gegenzug das Geschäft dann nicht zu zerstören, habe ich langsam bisschen Muffensausen bekommen. Ich dachte „ok, das war kein Hoax, die A-Geigen meinen das so“.

Also wieder gleiches Programm. Mit Geduld und Spucke in die NAS und alles totgelegt. Auch gleich mal einen Neustart der NAS gemacht (nach wochenlanger Uptime… ich bekam feuchte Augen, echt) und die letzten Sicherheitsupdates installiert.

Aber dann hatte ich einen Idee… zwei Tage hintereinander, zwei mal praktisch dieselbe Uhrzeit… das klingt doch verdächtig nach „Cron“.

cron um 11
cron um 11

Und was sehe ich da? Da läuft ein Backupscript von mir höchstpersönlich.

Was macht das… isset Schuld?

ya-backup
ya-backup

Naja. Also…. wenn das jetzt den Server derartig überlastet, dann weiß ich auch nicht.

Dann fiel mir ein, was ich die Tage davor gemacht habe.