Fedora – PHP 7 – ZipArchive

Wer mit Fedora 25+ die Meldung „PHP Fatal error: Uncaught Error: Class ‚ZipArchive‘ not found in /www/pages/….“ sieht, wenn er eine Webanwendung installiert, der braucht folgenden Fix:

libzip-1.1.3-1.fc25.x86_64
php-pecl-zip-1.13.5-1.fc25.x86_64

Dafür das in die Konsole eingeben:

dnf install php-pecl-zip

und dann ggf. noch einen Neustart seines Webservers, wenn man PHP als Modul einsetzt, was man nicht machen sollte.

PHP-CGI verbraucht zuviel Speicher

Dieser Beitrag ist aus der Kategorie:

„Was kann da schon schief gehen“

Speicher ist billig, aber doch endlich und nicht beliebig nachrüstbar.  Es kann also Situationen geben, wo man Speicher einsparen muß, weil andere der irrigen Meinung, waren, das mit dem Speicherverbrauch  wäre kein Problem.

Aber der Reihe nach:  Was ist überhaupt das Problem ?

PHP als CGI ausgeführt, verbraucht pro Start > 400 MB Speicher fürs Nichtstun.

Beispiel:  „php-cgi -a“ startet PHP ohne irgend was zu machen.

In einer zweiten Konsole läßt man sich mit pmap anzeigen, wer in dem Prozess was an Speicher belegt:

pmap {pid of process}

Beispielausgabe ( gekürzt : Warum kommt später )

[root@xxx]# pmap 5408
5408:   php-cgi -a
0000560d00b44000   3724K r-x– php-cgi
0000560d010e6000    536K r—- php-cgi
0000560d0116c000     16K rw— php-cgi

00007fce773f8000     28K r-x– libcrypt-2.23.so
00007fce773ff000   2044K —– libcrypt-2.23.so
00007fce775fe000      4K r—- libcrypt-2.23.so
00007fce775ff000      4K rw— libcrypt-2.23.so

total           420372K

Genau, 410 MB und nicht eine Anweisung ausgeführt. 3.7 MB gehen für den PHP-Interpretercode selbst drauf, ok. 2 MB gehen alleine für die libcrypt drauf.

Und jetzt der Grund wieso die Ausgabe gekürzt ist: PHP benutzt 75 Libs => ~ 160 MB Speicherverbrauch … bei jedem Script!

Bei der Analyse ist aber aufgefallen, daß auch eine Locale eingebunden wird:

-rw-r–r– 1 root root 110562112 22. Dez 12:01 /usr/lib/locale/locale-archive
-rw-r–r– 1 root root         0 22. Dez 12:01 /usr/lib/locale/locale-archive.tmpl

Auch bekannt als 107 MB und diese Datei wird in jeden PHP Prozess geladen,  der läuft. Keine Gnade.

Locale  – was sind das ?

„Locals“ sind keine Eingeborenen, sondern nur die Informationen über jene, also Zahlensysteme, Schreibrichtung, Datumsformat, Gewichte, Längen usw. . Wer mal sehen will, welche auf seinem Linux installiert sind, gibt das ein : locale -a

Da kommen Sachen von Sprachen, wo man nicht mal sagen kann, wo die passenden Länder sind 😉

Irgendwann hat Red Hat mal entschieden, daß die einfach alle Sprachen des Planeten ausliefern, weil dann der User nicht mehr machen muß. Stimmt.

Auf einem Desktopsystem ok. Aber auf einem Server ist das nicht ok und deswegen muß das auf ein gesundes Maß gedrückt werden. Das macht man mit  : /usr/sbin/build-locale-archive -v -l „de:en:ru:jp“

„Oh… geht ja gar nicht“ ????

Doch geht, aber nur mit Trick Siebzehn aus der „Erschiesst den Trottel Ecke“.

Die obige Locale-Archiv-Datei kommt mit dem Paket „glibc-all-langpacks“ auf den Server. Damit kommt aber auch ein TEMPLATE File mit, aus dem man sich genau das Archiv selbst bauen kann, wenn man eben nicht alles haben will.

Ihr habt’s erfaßt, das wäre zu einfach gewesen 🙁

Die Templatedatei ist nämlich LEER und damit nicht zu gebrauchen. Ihr Fragt Euch jetzt : „Wie bekommt man so ein Template?“ hmm.. Tja.. aus dem Repo jedenfalls nicht und doch, bekommt man. Jetzt wird es lustig, wir kopieren das vorhandene Archiv als Template für sich selbst ! Ja, richtig, mit der Faust durchs Auge: In your Face Red Hat!

Also eingegeben:

cp locale-archive locale-archive.tmpl
/usr/sbin/build-locale-archive -v -l „de:en:ru:jp“
locale -a

und schon ist das File keine 107 MB  mehr sondern nur noch 7 MB und auch das halte ich für extrem viel Schrott für 4 Sprachen. Aber jetzt lädt das php nur noch 7 MB rein. Das macht in der Endabrechnung dann 25% weniger RAM Verbrauch.

Als nächstes muß man rausfinden, wieso die Libs jeweils 2 MB verbrennen, wenn die nur 70k groß sind. Aber das ist eine andere Geschichte aus dem |-: La-La-La-Land 😐 .