Mit der Zeit fanden wir heraus, dass dies wohl am eaccelerator liegt, worauf wir XCache versuchten, was anfangs einen besseren Eindruck machte. Nach 2-3 Tagen Betrieb unter Hochlast, trat wieder das selbe Problem auf.

Nach langem Suchen durch diverse Foren und Blogs, fand ich heraus, dass dies keine unbekannten Probleme sind, die einfach auf Bugs in diesen Opcode Cachern (eaccelerator und XCache) zurückzuführen sind und man solle doch APC (Alternative PHP Cache) nutzen.

Freudig stellte ich fest, dass APC nicht mehr bei jedem Update selbst kompiliert werden musste (phpize, configure, make, make install), sondern einfach via apt-get zu beziehen ist (unter Debian/Lenny, noch nicht unter Etch), das Paket nennt sich “php-apc”. Nicht, dass ich das Selbstbauen scheue, aber bei über 20 Webservern, die teilweise 32, teilweise 64 Bit Kernel haben, ist man froh, wenn man sich diese Arbeit sparen kann.

Nun läuft APC auch noch seit Wochen ziemlich stabil, ab und zu tritt noch ein 500er auf, aber dies hat andere Gründe (lighttpd backend overloaded), an denen wir arbeiten. Die APC-Config basiert auf den Standardwerten, abgesehen von “apc.stat_ctime”, welches auf 1 gesetzt ist, da der Cacher sonst nicht mit Dateiaktualsierungen via SVN klarkommt.
Performancetechnisch ist bis jetzt kein Nachteil gegenüber den beiden Konkurrenzprodukten festzustellen.
Weiterhin spricht die Tatsache, dass es offiziell von den PHP-Entwicklern supportet wird, ebenfalls für APC.

Fazit: Was spricht gegen APC? Warum werden so oft eaccelerator und XCache genutzt, obwohl es sich bei beiden noch um Beta-Versionen handelt (Version < 1)?

Hintergrundinfo (alles Lenny Pakete):
- php-apc Version: 3.0.19-2
- php-cgi Version: 5.2.6.dfsg.1-1+lenny2
- lighttpd Version: 1.4.19-5

Folgende Zeile in /etc/apt/sources.list eintragen:

deb http://ftp.debian-unofficial.org/debian/ etch main contrib restricted

Für Lenny muss hier lenny statt etch stehen, für Ubuntu ein stable.

Danach muss man den Publickey der Paketquelle importieren, die ID des Keys findet man heraus, indem man apt-get update macht und den Fehler am Ende der Ausgabe liest. In der folgenden Befehlsfolge, diesen dann austauschen. Für Etch sollte der Key im Beispiel stimmen, bei den anderen bin ich mir nicht sicher.

gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 394D199524C52AC3;
gpg --export --armor 394D199524C52AC3 | apt-key add -
apt-get update
apt-get install 3ware-3dm2-binary

Damit man nun auch “remote” darauf zugreifen kann, muss in der /etc/3dm2/3dm2.conf RemoteAccess auf 1 geändert werden.

Nun kann man sich auf http://xxx.xxx.xxx.xxx:888/ als Administrator, mit dem Passwort 3ware, einloggen.
Nicht vergessen, das Passwort noch zu ändern.

Das Bottleneck bei Memcache ist also nicht die größe des Arbeitsspeichers oder die eigentliche Gesamt-CPU-Leistung, sondern nur die Leistung des ersten CPU Kerns (CPU0 in top).

Ausschlaggebend ist hier auch nicht die größe des Caches oder die Anzahl der persistenten Verbindungen, sondern die Frequentierung. Der Haupt-Memcache-Cluster umfasst 16-32GB pro Server und kommt super mit seinen Aufgaben klar, nur der abgekapselte Teil für das neue Feature, der auf einem eigenen Memcacheserver arbeitet, welcher nur eine größe von 6GB umfasst. Hier werden pro Sekunde 3 Keys von rund 15000 Clients abgefragt. Die 40000 persistenten Verbindungen stellen hier kein Problem dar, was andere Tests bewiesen.

Server 2 (Kernel 2.6.24)

Hier ist noch zu erwähnen, dass 100% CPULast bedeutet, dass alle 8 Kerne ausgelastet sind, also 8*100%.

Nach genauerer Analyse, stellten wir fest, dass die 8 CPU-Kerne auf Server 2 ziemlich gleichmäßig ausgelastet wurden (15-20%), auf Server 1 bekam allerdings nur der erste Kern eine Last von bis zu 100%.
Grund hierfür ist (sehr wahrscheinlich), dass der neuere Kernel Threading unterstützt, der alte zwar auch, aber nicht in einem für MySQL nutzbarem Rahmen.

Rechnet man nun die CPU-Last auf Server 2 (neuer Kernel) mal 8 (pro CPUKern), stellt man fest, dass das Ergebnis in etwa der Last des ersten CPU Kerns von Server 1 (alter Kernel) entspricht.

Fazit: in absehbarer Zeit wird Server 1 auf Debian/Lenny upgegraded.

Nach langer Recherche im Internet und überprüfung der Paketversionen, viel auf, dass das PHP-Memcache Paket eine komplette Versionsnummer weiter war (statt 2.x nun 3.x).
In der Dokumentation bzw. dem Changelog fand ich dann zwei Gründe, für unsere Probleme.

1. Memcache nutzt eine Hashingmethode, um die abgelegten Keys auf den diversen Instanzen wiederzufinden (bei uns laufen insgesamt 14 Instanzen mit je 3GB auf zwei verschiendenen Servern). In Version 3 der API, hat sich dieses Verfahren standardmäßig geändert und musste via Configeintrag wieder auf “standard” gesetzt werden. (in der php.ini oder php5/conf.d/memcache.ini).
2. Die neue Memcache Version unterstützt zwar noch das alte Objekt “Memcache”, aber es wird empfohlen, das neue Objekt “MemcachePool” zu benutzen, welches die bekannten plus noch ein paar neue Methoden besitzt.

Nachdem beides geändert wurde, lief es auf dem Testserver optimal, selbiges wurde dann noch auf den Produktivservern umgesetzt. Nachdem wir dann, anhand überdurchschnittlicher CPU Load, bemerkten, dass der Opcode-Cacher eaccelerator noch neu Kompiliert werden musste (logisch eigentlich), lief alles wieder einwandfrei.

Der Webserver hat auf eth0 seine eigene externe IP (z.B. 80.xx.xx.103) und eine interne auf eth1, die uns hier aber nicht interessiert. Ich wusste, dass einfach ein virtuelles Loopback Interface erstellt wird (lo:0), welches die “shared”-IP haben wird. Gesagt getan, doch dann brach der Traffic zusammen und die Load dieses einen Webservers, schoss rapide in die Höhe. Problem war, dass der Server fröhlich auf alle möglichen ARP-Anfragen zu dieser IP antwortete.

Lösung:
die Datei /etc/sysctl.conf bearbeiten

# Optionen aktivieren
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
# ARP requests die von eth0/eth1 kommen nur mit
# einer IP beantworten, die auch dort konfiguriert
# ist, nicht lo (loopback) oder lo:0
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth1.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth1.arp_announce = 2

Danach sysctl -p /etc/sysctl.conf ausführen und das Problem ist gelöst.

Eine Datei besitzt unter Linux 3 Datumsattribute: Erstellt, Modifiziert, letzter Zugriff

Dies bedeutet, dass bei jedem Lesezugriff auf eine Datei, gleichzeitig ein Schreibvorgang stattfindet, der den Timestamp des letzten Zugriffes neu setzt. Mounted man das Dateisystem allerdings mit der noatime Option, wird dies verhindert.

In der /etc/fstab sieht das folgendermaßen aus:

/dev/sdb1 /var/www ext3  defaults,errors=remount-ro,noatime 0       0

Aber Vorsicht, es gibt Daemons und Tools, welche diesen Wert nutzen, vorher Informieren!

Zu beheben mit den folgenden zwei Befehlen

ethtool -s eth0 duplex full
ethtool -s eth0 speed 1000

ethtool ist via apt-get install ethtool zu bekommen.

Nach langer Suche, fand ich heraus, dass neue Platten bzw. frisch angelegte Raids, erstmal mit “msdos” gelabelt sind. Dieses Label muss auf gpt geändert werden.
Das zweite Problem ist, dass fdisk (sowie cfdisk und die anderen Ableger) nicht mit dieser Kapazität klarkommt.

Um diese große Partition nun anzulegen, wird mit parted gearbeitet.

> parted /dev/sdx (sda,sdb,hda oder was auch immer)
> mklabel gpt
> print (Die Ausgabe gibt die Gesamtgröße an, z.B. 3500G)
> mkpart primary 0 3500G

Diese Partition darf nicht mit fdisk bearbeitet werden, selbst fdisk -l zeigt falsche Daten an!

Um die Partition nun zu formatieren, kann man wie gehabt, mkfs.ext3 nutzen.