Server-Tuning 4: OPcache, APCu, memcache, memcached

Dieser Artikel behandelt die Beschleunigung von PHP-Prozessen unter Linux mittels Nutzung von Hauptspeicher-Bereichen zur Speicherung von Daten über mehrere HTTP-Anfragen hinweg. Spezifisch wird auf Ubuntu (12.04 + 14.04) und Plesk 12 eingegangen; die meisten Ausführungen gelten allgemein. Zwei verschiedene Techniken ergänzen sich:

  1. Das Programm selbst:
    PHP-Quellcode wird grundsätzlich zur Ausführung in eine dafür vorbereitete Form namens Bytecode kompiliert; diese Form kann in einem sog. Bytecode Cache gespeichert werden (der zum laufenden Prozess gehört). Der Code wird also einmal kompiliert und mehrmals (bei Bedarf) ausgeführt.
  2. Daten die das Programm benutzt:
    Ein Hauptspeicherbereich wird als sog. Userland Cache reserviert und kann befüllt und anschließend viele Male abgefragt (und upgedatet) werden, ohne dass konventioneller Plattenspeicher (das Dateisystem) benutzt wird. Er wird meistens als Key-Value Store benutzt.
    • Das kann ein Speicherbereich des lokalen Servers sein, auf den mehrere Prozesse eines gemeinsamen Elterns zugreifen können. Für Linux grundsätzlich kein Problem, aber nicht alle Webserver-Architekturen unterstützen dies: PHP-FPM kann das, aber Apache FastCGI kann es nicht – jeder FastCGI-Prozess erhält einen eigenen Cachebereich. Hauptvorteil: Blitzschnell weil Direktzugriff im lokalen Hauptspeicher.
    • Alternativ kann ein unabhängiger Prozess den Speicherbereich verwalten, und den Zugang dazu beliebigen anderen Prozessen per TCP/IP oder Unix Sockets ermöglichen. Dies ist nicht ganz so schnell, hat dafür den Vorteil dass die Daten über mehrere Rechner verteilt werden können, wie z.B. bei Memcached. Ferner teilen sich hierbei auch FastCGI-Prozesse ein und denselben Speicherbereich; die Technik eignet sich somit auch für PHP-Sessionverwaltung.

Zend OPcache als Bytecode-Cache einsetzen

Bei Plesk-Systemen ist im System-Standard PHP5 seit PHP 5.5 das Zend OPcache-Modul standardmäßig dabei, ggf. diese Erweiterung laden / Aktivieren. Ubuntu 12.04 hat nur PHP 5.3, hierfür gibt es kein Zend OPcache. Beim Kompilieren einer eigenen PHP-Version einfach in den Configure-Optionen wählen und in php.ini aktivieren.

  • Denken Sie daran, dass in php.ini „memory_limit“ (deutlich) größer sein muss als „opcache.memory_consumption“.
  • Plesk’s Zusatzversion von PHP 5.6 setzt standardmäßig per /opt/plesk/php/5.6/etc/php.d/10-opcache.ini für VPSen (zu) hohe Werte: opcache.memory_consumption=128 / opcache.interned_strings_buffer=8. Diese lassen sich in den normalen Plesk PHP-Einstellungen nicht überbuttern – man muss die o.g. Datei anpassen.

APCu als Userland-Cache

Im Netz gibt es ausreichend Anleitungen zur Installation von APCu, die Quellen von APCu liegen auf GitHub, nur Übersichten / Tutorials sind absolute Mangelware. Hier auf StackOverflow eine Frage mit guter Antwort zu APCu, sogar mit Anmerkung des Autors Joe Watkins.

Nach eigener Beobachtung haben FastCGI-Prozesse tatsächlich je ein eigenes APCu Cache. Das ist ein starkes Argument für PHP-FPM bei Websites die viele Besuche haben und Userland-Cache stärker nutzen. FPM ist daher auch Voraussetzung dafür, dass APCu-Cache-Einträge automatisch konsistent bleiben, denn das Cache von einem FastCGI-Prozess könnte inhaltlich divergieren von dem eines anderen FastCGI-Prozesses. Fazit: Mit FastCGI dürfen nur „fixe“ Werte in APCu notiert werden, z.B. Basiswerte einer WordPress-Installation, damit sie nicht jedes Mal aus der DB gelesen werden müssen. Die Verwendung als klassischer Key-Value Store mit dynamischen Werten wird bei FastCGI nicht funktionieren! Für Plesk-Standard PHP-FPM wird mindestens Ubuntu 14.04 benötigt, dort gibt es PHP 5.5.9.

  • APCu ist schneller als verteilte Lösungen wie memcached / Xcache.
  • Wird von ownCloud bevorzugt (sicherlich nicht umsonst, die Entwickler sind gut).
  • ABER APCu ist nur auf dem lokalen Server, keine Unterstützung für Server-Cluster (daher schwer skalierbar).
  • Ferner gehen die Daten bei einem Neustart von Apache verloren…
  • Mancherorts wird behauptet das memcache(d) „einfach funktioniert“, während APCu manchmal Instabilität verursacht. Das kann ich aus eigener Erfahrung nicht bestätigen, bei mir läuft APCu stabil. Vielleicht haben Leute, die Probleme mit APCu behaupten, die Tatsache mehrerer Kopien bei FastCGI-Prozessen einfach nicht verstanden?
  • Mein ownCloud 8.0.3 scheint mit APCu trotz FastCGI stabil zu laufen, vorausgesetzt:
    a) APCu ist korrekt konfiguriert, und
    b) Der Server nicht an Hauptspeicher-Erschöpfung leidet.
    Denn ownCloud speichert hier nur lauter Pfade innerhalb seines Codes, fast alle vom Autoloader.
  • Weiteres zum Thema:
    Übersicht von Bytecode-Cache und User Data Cache Programmen
    Bericht über die Nutzung von APCu mit Xenforo unter PHP-FPM

memcache oder memcached?

Es gibt einen Daemon-Prozess namens memcached (gesprochen: mem-cache-D), der muss im Betriebssystem als eigenständige Größe eingerichtet werden (wenn er nicht schon da ist, sonst gibt es ein Installationspaket). Läuft er, so kann er von beliebigen anderen Prozessen per TCP/IP oder Unix Sockets angesprochen werden, um Werte (Objekte, Key-Value-Paare) in dem von ihm verwalteten Speicherbereich zu schreiben und lesen. Dank TCP/IP müssen diese Prozesse nicht einmal auf dem gleichen Rechner laufen, und memcache Clients kümmern sich meist selbst je nach ihrer Konfiguration ggf. um die Verteilung der Daten auf mehrere Server.

Gute Tutorials zu memcached gibt es z.B. hier, hier und hier.

Für PHP gibt es aus historischen Gründen zwei verschiedene Client-Module zur Auswahl:

Hier steht „Both are very similar, but the first one has a smaller footprint“. Das stimmt, aber dafür ist memcached jünger (von der Konzeption her) und kann mehr. Vergleiche der beiden gibt es zuhauf, z.b. hier, hier, hier und hier.

Installation APCu (plus igbinary)

Man kann das aktuelle APCu 4.0.7 sowohl für eigen-kompilierte PHP-Versionen als auch für das System-Standard PHP bequem per PECL installieren (standardmäßig ist APCu nirgendwo dabei). Was nicht funktioniert ist das Kompilieren von Zusatzmodulen für eine Plesk-Zusatzversion von PHP, hier fehlt das passende „phpize“. Für System-Standard PHP gibt es zwar ein APCu Ubuntu-Paket, das man per apt-get installieren kann – aber machen Sie das besser nicht, das installiert die fehlerbehaftete Version 4.0.2.

Mit der igbinary Erweiterung von PHP halbiert sich in etwa der Platzbedarf von String-Werten im User Cache – benutzen Sie sie als drop-in Ersatz für den PHP Serializer. Igbinary kann man auch als Serializer für PHP Session-Daten zusammen mit memcache(d) benutzen. Damit kann der für memcached verfügbare Hauptspeicher beinahe doppelt so viele Sessions aufnehmen.

Standard-PHP:
pecl install igbinary  (es gibt kein Ubuntu-Package für igbinary)
pecl install channel://pecl.php.net/APCu-4.0.7
(installiert /usr/lib/php5/{20090626|20121212}/apcu.so aber keine /etc/php5/{conf.d|mods-available}/apcu.ini)

Obige Möglichkeit ist insb. für Ubuntu 14.04 mit Standard-PHP 5.5.9 interessant – hier kann man Plesk’s Nginx + PHP-FPM einsetzen, mit Zend OpCache und APCu. Für eine selbst-kompilierte PHP-Version:

/usr/local/php568/bin/pecl install igbinary
/usr/local/php568/bin/pecl install channel://pecl.php.net/APCu-4.0.7

Siehe hier für APCu INI-Werte. Ich empfehle die Vorgabe defensiver Werte in /etc/php5/{conf.d|mods-available}/apcu.ini bzw. /usr/local/php568/lib/php.ini.

Installation memcache / memcached

memcached Daemon

Hier gibt es eine gute Anleitung zur memcached Daemon-Installation, und hier meine:

apt-get install memcached libmemcached-dev libsasl2-modules libsasl2-dev

Mit folgenden zwei Befehlen können Sie prüfen ob memcached läuft:

  • ps -ef | grep memcached
  • netstat -tap | grep memcached

Mehr Hauptspeicher nötig? (Default 64Mb): /etc/memcached.conf

PHP-Erweiterung memcache

Standard-PHP: apt-get install php5-memcache
Eigenes PHP: /usr/local/php568/bin/pecl install memcache

PHP-Erweiterung memcached

Standard-PHP: apt-get install php5-memcached

Wer aber memcached mit einer selbst-kompilierten Version von PHP braucht, hat ein Problem: Der entsprechende PECL-Aufruf scheitert, weil die Ubuntu-Version von libmemcached (Daemon) leider keinen Support für Cyrus SASL enthält. Man muss also die Quellen selber holen und mit Custom-Options zu ./configure arbeiten:

cd /usr/local/src/php-5.6.8/ext
/usr/local/php568/bin/pecl download memcached
tar zxvf memcached-2.2.0.tgz
rm memcached-2.2.0.tgz
cd memcached-2.2.0  # Now in /usr/local/src/php-5.6.8/ext/memcached-2.2.0
# Erzeugt die weiterhin nötigen Dateien im aktuellen Verzeichnis
/usr/local/php568/bin/phpize
# Erzeugt ein passendes Makefile - Siehe http://php.net/manual/en/install.pecl.phpize.php (Kommentar Brian)
./configure --with-php-config=/usr/local/php568/bin/php-config --enable-memcached --with-libmemcached-dir=no --disable-memcached-sasl --enable-memcached-igbinary
make
# make test - läuft nicht, falsche Umgebung
make install

Siehe auch: Memcached Konfigurationsoptionen auf php.net

memcached.serializer = igbinary  ; The default is igbinary if available and php otherwise

Debugging

Wenn ein PHP-Modul nicht geladen werden kann (PHP Fatal error) dann findet man die Meldung dazu in

Standard-PHP: /var/log/apache2/error.log
Eigenes PHP / Plesk: /var/www/vhosts/system/{domain}/logs/error_log

Es folgen ein paar Probleme, die ich überwinden musste:

  • PHP Startup: apc_mmap: mmap failed: in Unknown on line 0
    Nachzulesen hier und hier. „some APC process is requesting more SHM mmap’ed memory than the kernel or system config is willing to provide“.
    Fazit: APCu muss mit geringerem Speicherbedarf konfiguriert werden!
  • [error] mod_fcgid: process /var/www/cgi-bin/cgi_wrapper/cgi_wrapper(21423) exit(communication error), get unexpected signal 11
    Nachzulesen hier und hier.
    Fazit: Sinnvolle ini-Werte für APCu bereitstellen, am Besten gleich in der Standard-Ini-Datei bzw. conf.d.
  • Fatal Error Unable to allocate shared memory segment of 20971520 bytes: shmget: Cannot allocate memory (12)
    20971520 bytes = 20MB = Das was ich für Zend OpCache vorgesehen hatte.
    Fazit: Ich muss irgendwo (noch mehr) Hauptspeicher sparen!
  • PHP Warning: PHP Startup: memcached: Unable to initialize module
    Module compiled with module API=20090626
    PHP compiled with module API=20131226
    Lösung: Option –with-php-config=/usr/local/php568/bin/php-config hatte gefehlt beim ./configure

Tipp: Einige Probleme mit Speicherbedarf neigen zu verschwinden beim Aufstieg von einem VPS zum Dedicated Server…

Check this out too: „The reason is that suhosin memory limit may not exceed 2047M.“

Die PHP Session

PHP speichert Session-Daten standardmäßig in Dateien auf der Festplatte. Durch Speicherung dieser Daten stattdessen im Hauptspeicher ist es möglich, Zeit zu sparen – die Website antwortet schneller mit der nächsten Seite. PHP sieht gleich zwei Maßnahmen vor, um die Session-Verwaltung zu verschlanken:

  • Die zu-speichernden Benutzer-Daten können als komprimierten Binärdaten statt in Originalform gespeichert werden.
  • Der Speicherort kann ein Speicherdienst wie memcache oder memcached sein (PHP sieht keine Möglichkeit für Session-Storage mittels APCu vor, wohl weil dies nur mit PHP-FPM funktionieren würde, nicht aber mit FastCGI-Prozessen).

Für die zu-beglückende Domain in Plesk | PHP Settings:

extension = igbinary.so
session.serialize_handler = igbinary

und dann entweder mit der memcache-Erweiterung:

extension = memcache.so
memcache.chunk_size = 131072
session.save_handler = memcache
session.save_path = "tcp://localhost:11211"

oder mit der memcached-Erweiterung:

extension = memcached.so
session.save_handler = memcached
session.save_path = "localhost:11211"

Tipp: WordPress verwendet keine PHP Sessions, nutzt nur ein Login-Cookie, siehe hier.

Anwendungen

WordPress

Hier gibt es grundsätzlich folgende Möglichkeiten:

  1. Beschleunigung der PHP-Ausführung mittels Zend OPcache
  2. Caching fertiger Seiten am Server, damit die aufwendige Erstellung der Seiten nur gelegentlich erfolgen muss. Dies kann in Plattendateien erfolgen, oder noch besser im Hauptspeicher.
  3. Caching von Objekten (Werten) im Hauptspeicher, die bei der Ausführung der WP-PHP-Skripte praktisch immer gleich sind, z.B. bzgl. der Pfade innerhalb WordPress, oder die mühsam aus der (stöhnenden) Datenbank sonst geholt werden müssten, aber von Mal zu Mal gleich bleiben.

Möglichkeit 1 haben wir bereits oben behandelt.

Möglichkeit 2 hängt stark davon ab, welches Seitencache-Plugin man nimmt:

  • Mein bisheriges Liebling Comet Cache kann bislang nur Plattendateien – ein Request für APCu / memcached steht schon länger im Raum, ist aber bis jetzt in Planung, und wird womöglich dann nur in der Bezahlversion auftauchen…
  • Hyper-Cache erlaubt es, einen beliebigen Pfad zum Cache-Verzeichnis anzugeben. Wie hier erläutert *, kann Man das im System bereits vorhandene Shared-Memory Datei-System (Ubuntu: /run/shm) einsetzen (und open_basedir nicht vergessen!). Das funktioniert, aber es gibt ein Problem mit der Größe: /run/shm hat nur 4 MB Platz, ein normales Cache-Volumen für eine lebendige Website beträgt ein Mehfaches davon – es reicht also nicht. Wer sich traut – ggf. neben Plesk – ein weiteres Hauptspeicher-Dateisystem einzurichten, kann das tun!
    * Allerdings ein wenig veraltet: Lite Cache wurde in Hyper-Cache integriert, wird nicht mehr gepflegt.
  • Der Autor des oben verlinkten Beitrags schwört auf WP-FFPC. Ich habe es selbst probiert, auf dieser Website: WP-FFPC lohnt sich nur bei Websites die laufend besucht werden. Es hat keine aufwendigen Prüfungen wann sich eine Seite geändert hat wie bei Comet Cache, stattdessen ist die Seite „cache frisch“ für eine bestimmte Zeit, Default 300 Sekunden. Wird eine Seite also für 300 Sekunden nicht besucht, erlischt es aus dem Cache, wird beim nächsten Besuch neu gebaut. Man kann zwar die Cache-Zeit beliebig hoch setzen, aber dann wenn man die Seite ändert muss man das Cache manuell löschen.
    Mein Fazit: Bei Websites, die weniger als durchschnittlich alle 5 Minuten besucht werden (~300 Mal / Tag) bei Comet Cache bleiben.
  • Der Platzhirsch W3 Total Cache soll wenn richtig und vollständig konfiguriert eine Menge bringen; es kann neben dem Dateisystem auch mit Memcached, Xcache und APC (nicht APCu). Als besonderes Schmankerl kann es zudem alle JS-, CSS- und HTML-Dateien der Website vor Auslieferung komprimieren (minify). Dafür muss man eine Menge konfigurieren, und Änderungen in .htaccess in Kauf nehmen (der bei mir von iThemes Security ohnehin stark ergänzt wird). Vielleicht werde ich es an einem verregneten Sonntag probieren; und ansonsten die Kirche im Dorf lassen – denn wenn Ihr Cache das Dateisystem nutzt und Ihr Server genügend Hauptspeicher noch frei hat, dann wird Linux ohnehin die häufig verwendeten Dateien im Hauptspeicher haben (eingebautes Cache des Dateisystems).

Möglichkeit 3: Das APCu Object-Cache Plugin kann grundsätzlich immer eingesetzt werden, es setzt keine oder sehr hohe Timeout-Werte. Ob das insgesamt ein Ersparnis bringt – gegenüber der Notwindigkeit das APCu-Modul zu PHP hinzu zu laden und das Cache anzubinden und bedienen, hängt aber auch von der Besuchsfrequenz ab (MaW: bei wenigen Besuchen verzichte darauf). Achtung: Es handelt sich hierbei um kein konventionelles Plugin sondern ein „Drop-In“, beachten Sie die besonderen Installationshinweise dort. Es ist aber trivial – das Zip entpacken und eine Datei per FTP hochladen – fertig.
PHP Ini-Werte hierfür: extension = igbinary.so / extension = apcu.so / apc.serializer=igbinary

ownCloud

ownCloud freut sich auf ein Hauptspeicher-basiertes Cache, das er in folgender Reihenfolge sucht:
1. xcache, apc, apcu
2. Ein Redis Server (hier Redis Installieren).
3. Ein Memcached Server (via memcached.so – mit „d“)

Um sicher zu stellen dass ownCloud nicht versucht, ein nicht-vorhandenes Redis Server anzubinden (Bug in OC 8.0, behoben in 8.1), lade eines von Xcache / APC / APCu oder konfiguriere explizit in seinem config.php ein Memcached Server. Da Xcache and APC beide auch ein Bytecode Cache enthalten, wir aber nun das Standard Zend OPcache nutzen, ist hier APCu wohl die beste Wahl (Installation siehe oben). Bei mir funktioniert es, ich verwende APCu mit folgenden Ini-Werten:

realpath_cache_size = 128K
opcache.memory_consumption = 24
opcache.interned_strings_buffer = 2
opcache.revalidate_freq = 5
extension = igbinary.so
extension = apcu.so
apc.shm_size = 2M
apc.serializer = igbinary
session.serialize_handler = igbinary

NICHT VERGESSEN: Nach Editieren von config/config.php als root ein chown zum Webserver-UID!

Ich hätte genauso gut memcached nehmen können; da ich FastCGI verwende gibt es ein APCu Cache zu jedem FastCGI-Prozess, wobei nur ca. 160 KB vom APCu’s 2MB benutzt werden – eine Platzverschwendung wenn mehrere Prozesse parallel laufen, die es mit Memcached nicht gäbe. Dafür ist der Zugriff auf die Werte schneller, da er durch direkten Speicherzugriffe stattfindet.

Ansonsten befolgen Sie die guten Anweisungen im ownCloud Admin-Handbuch, Kapitel Server Tuning & Performance Tips.

Monitoring Tools

Die Messung vom tatsächlichen Verbrauch an Hauptspeicher ist hier ziemlich unerlässlich – lässt man z.B. OPcache mit einem Standard-Wert von 128 MB laufen und bräuchte tatsächlich nur 16 MB, verschenkt man mit jedem PHP-Prozess schlappe 112 MB.

Zend OPcache: Verwende das Zend OpCache Control Panel.

APCu: Verwende das APCu Info-Panel.

Beide oben verlinkten Tools sind jeweils nur eine Datei (ocp.php bzw. apc.php) die man in das Domain-Verzeichnis deponiert und per Browser aufruft.

Memcached: Da es sich hierbei um ein autark laufender Prozess handelt fällt die Überwachung etwas aufwendiger aus. Tipps fand ich hier und hier. Mann kann es manuell am Server per telnet abfragen:
telnet localhost 11211 / stats / quit
Wer es graphisch sehen will, kann eine eigene Subdomain für das phpMemcachedAdmin Web-Tool spendieren. Herunterladen, entpacken, aufrufen – geht problemlos und erzeugt eine recht anschauliche Ausgabe.

Der ganze Linux-Hauptspeicher: Das kostenlose Tool smem steht für Ubuntu als Paket zur Verfügung:
apt-get install smem
Tipps dazu fand ich hier und hier. Hier wird einem Appetit gemacht auf Bar- und Pie-Charts, was smem auch erzeugen würde. Leider haben wir per SSH-Zugang zu einem entfernten Server keinen graphischen Display:
TclError: no display name and no $DISPLAY environment variable.
Die Text-Ausgaben sind jedoch schon recht hilfreich.

Ganzer Linux-Server per Web: Ich fand über diesen Artikel spannende Tools, und aufgrund mehrerer Vergleiche mir vorgenommen, Zabbix bei Gelegenheit anzuschauen. Als einfache Zwischenlösung habe ich in einer extra dafür angelegten Subdomain eZ Server Monitor eingerichtet. Es läuft ohne Anpassung, einige Aspekte lassen sich ganz einfach konfigurieren.

Error Logs: Nachdem ich zufällig eine Logdatei von 1,5GB Größe fand, schrieb ich folgenden Bash-Script – passen Sie die Mail-Daten und ggf. Specials Ihren bedürfnissen an!

#! /bin/bash

###
### Check for large (runaway) webserver and PHP error log files, report via Mail
###
### The error log files are expected where Plesk 12 and Ubuntu put them
###
### Also tests if remaining disk free space less than 20GB
###
### Tim Reeves, E-Mail versteckt; JavaScript wird benötigt.
###
### Last edit: 2015-05-17
###

loglog=/tmp/loglog
hn=$(cat /etc/hostname)
errs=N

# start logfile
echo "Subject: Error-Logs $(cat /etc/hostname) $(date "+%Y-%m-%d")" > $loglog
echo "To: YOUREMAIL" >> $loglog
echo "" >> $loglog

# Plesk's domain-specific error logs
# They collect "File does not exist" messages from attacks
cd /var/www/vhosts/system
for errlog in $(ls  */logs/*error_log)
do
  size=$(stat --printf="%s" $errlog)
  if [ "$size" -gt 150000 ]; then
    echo "/var/www/vhosts/system/$errlog = $size" >> $loglog
    errs=Y
  fi
done

cd /var/www/vhosts/system
for errlog in $(ls  */logs/*error_log)
do
  size=$(stat --printf="%s" $errlog)
  if [ "$size" -gt 50000 ]; then
    echo "/var/www/vhosts/system/$errlog = $size" >> $loglog
    errs=Y
  fi
done

# Apache domain-non-specific error log
errlog=/var/log/apache2/error.log
if [ -f "${errlog}" ] && [ -s "${errlog}" ]; then
  size=$(stat --printf="%s" $errlog)
  if [ "$size" -gt 50000 ]; then
    echo "$errlog = $size" >> $loglog
    errs=Y
  fi
fi

# PHP-FPM domain-non-specific error log
errlog=/var/log/php5-fpm.log
if [ -f "${errlog}" ] && [ -s "${errlog}" ]; then
  size=$(stat --printf="%s" $errlog)
  if [ "$size" -gt 0 ]; then
    echo "$errlog = $size" >> $loglog
    errs=Y
  fi
fi

# Nginx domain-non-specific error log
errlog=/var/log/nginx/error.log
if [ -f "${errlog}" ] && [ -s "${errlog}" ]; then
  size=$(stat --printf="%s" $errlog)
  if [ "$size" -gt 0 ]; then
    echo "$errlog = $size" >> $loglog
    errs=Y
  fi
fi

# Specials - ownCloud
errlog=/var/www/vhosts/YourPathToOwnCloud/data/owncloud.log
if [ -f "${errlog}" ] && [ -s "${errlog}" ]; then
  size=$(stat --printf="%s" $errlog)
  if [ "$size" -gt 10000 ]; then
    echo "$errlog = $size" >> $loglog
    errs=Y
  fi
fi

# Specials - PHP error logs reassigned via ini_set('error_log', ...)
cd /var/www/vhosts/YOURDOMAIN
for errlog in $(ls */logs/phperrs.txt)
do
  size=$(stat --printf="%s" $errlog)
  if [ "$size" -gt 2000 ]; then
    echo "$errlog = $size" >> $loglog
    errs=Y
  fi
done

# Check remaining free disk space
avail=$(df -k / | tail -1 | awk '{print $4}')
if [ "$avail" -lt 20000000 ]; then
  echo "Disk has less than 20GB free" >> $loglog
  errs=Y
fi

if [ "$errs" = Y ]; then
  # send status mail / backup log file
  /usr/sbin/sendmail -t -f YOUREMAIL -F "YOURNAME" < $loglog
fi

exit 0


# Notes on CRON
# /var/spool/cron/crontabs seems no longer used, Vixie Cron uses /etc/cron.d BUT... (man cron)
# Like /etc/crontab, the files in the /etc/cron.d directory  are  monitored
# for  changes.  In  general,  the  system  administrator  should  not  use
# /etc/cron.d/, but use the standard system crontab /etc/crontab.
# So append this line to /etc/crontab (which seems - for a change - not to be modified by Plesk)
# 44 4 * * * root [ -x /usr/local/sbin/checklogs.sh ] && /usr/local/sbin/checklogs.sh >/dev/null 2>&1

Kommentare (3) Schreibe einen Kommentar

  1. Hallo,

    Vielen Dank für den Tutorial. Ich habe derzeit ein Fehler den ich nicht beheben kann. Auch nach einigen Neuinstallationen bliebt der Fehler aufrecht.

    PHP Warning: PHP Startup: Unable to load dynamic library ‚/usr/lib/php5/20090626/apcu.so‘ – /usr/lib/php5/20090626/apcu.so: cannot open shared object file: No such file or directory in Unknown on line 0

    Habe bereits apc.ini Datei, php.ini Dateien kontrolliert und dort sind überall „extension=apc.so“ eingetragen.

    Wissen Sie vielleicht wo das Problem liegen kann?

    lg

    Antworten

  2. 1) „extension=apc.so“ sollte „extension=apcu.so“ lauten, aber verm. ein Tippfehler im Kommentar

    2) Denn /usr/lib/php5/20090626 ist das Verzeichnis vom Standard-PHP von Ubuntu 12.04 also PHP 5.3.10. Die Erweiterungsdatei gehört nicht zur Standard-Menge, man muss sie extra laden – und zwar NICHT per apt-get, da gibt es nur die fehlerhafte Version 4.0.2

    3) /usr/bin/pecl install channel://pecl.php.net/APCu-4.0.7

    Antworten

  3. Guten Tag,

    ich habe einen Server mit Ubuntu 14.04 LTS Server 64bit + Plesk 12.0. Nun wollte ich entsprechend Ihrer Anleitung php5-memcached mit igbinary zur Session-Speicherung installieren.
    Da ich auf dem System akutell „nur“ das vorhandene PHP 5.5.9 benutze, habe ich natürlich nicht die in Ihrer Anleitung beschriebenen Pfade für die selbst kompilierte PHP-Version.

    Ich bin folgendermaßen vorgegangen:
    memcashed installieren:
    =======================
    #sudo apt-get update
    #sudo apt-get install memcached

    Installation igbinary:
    ======================
    – Installation PECL: apt-get install php-pear
    – igbinary: pecl install igbinary
    (ergab Fehler mit Hinweis, dass PHP5-dev istalliert werden muss: apt-get install php5-dev)
    – nun in /etc/php5/mods-available/memcached.ini: memcached.serializer = igbinary

    in PHP.ini (in Plesk UI PHP-Einstellungen hinzufügen):
    extension=igbinary.so
    session.serialize_handler=igbinary
    igbinary.compact_strings=On

    Installation PHP5-Memcached-Erweiterung:
    ========================================
    #apt-get install libmemcached-dev
    #cd /usr/local/bin
    #pecl download memcached
    #tar zxvf memcached-2.2.0.tgz
    #rm memcached-2.2.0.tgz
    #cd memcached-2.2.0
    #/usr/bin/phpize
    #./configure –with-php-config=/usr/bin/php-config –enable-memcached –with-libmemcached-dir=no –disable-memcached-sasl –enable-memcached-igbinary
    #make
    #make install

    Ergebnis:
    – Memcashed läuft
    – igbinary ist installiert
    – Installation php-memcached: make install ergab keine Fehler
    -> jedoch wurde php-memcached nicht richtig installiert! Innerhalb von PHP ist es nicht verfügbar.
    Istalliere ich php-memcached über: apt-get install php5-memcached, dann läuft es ohne Probleme, jedoch nur mit dem PHP-Serializer und nicht mit igbinary. :/

    Könnten Sie mir bitte Hinweise geben, was ich anders machen muss oder ergänzen müsste?
    Meine Linux-Kenntnisse sind leider noch ziemlich gering und ich wälze mich meist nur duch Anleitungen durch…
    Vielen Dank!

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.