PHP / MySQL / Linux Stories » Linux allgemein

APC statt eaccelerator oder XCache

Michael — Mon, 15 Jun 2009 19:44:41 +0000

Lange plagten wir uns mit dem Problem, dass die Webserver nach ein paar Tagen Betrieb 500er warfen (500 – Internal Server Error). Dies ging dann ein paar Sekunden so (nur 2-3) und danach lief alles wieder glatt. Das ganze passierte wahllos mal auf diesem, mal auf einem anderen Webserver.

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

]]>

Debian/Ubuntu: 3dm2 installieren

Michael — Fri, 02 Jan 2009 21:32:36 +0000

Eine nette grafische Oberfläche für 3Ware Raid Controller, stellt 3dm2 dar. Wenn man dieses nicht selbst kompilieren möchte, kann man auf Binaries zurückgreifen. Der einfachste Weg, geht über die Paketverwaltung aptitude (apt-get).

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.

]]>

Skalierbarkeit von Memcache

Michael — Sun, 14 Dec 2008 21:13:05 +0000

Bei der Entwicklung bzw. den Lasttests eines neuen Features, viel uns auf, dass regelmäßig Memcacheverbindungen abbrachen oder gar nicht erst aufgebaut werden konnten. Nachdem lange nach dem Grund geforscht wurde, viel uns auf, dass selbst eine einfache Memcache-Statistik-Abfrage mehrere Sekunden dauerte oder sogar abbrach (nur während Spitzenlastzeiten).
Erst top verriet uns, wo das Bottleneck aufzufinden war.
Auf einem Memcacheserver läuft eine Memcached Instanz mit 16 Threads auf 8 Kernen (2CPUs á 4 Kerne), die Last verteilte sich recht gut, doch beim genaueren Betrachten viel auf, dass ausschließlich die erste CPU, dauerhaft 0-1% idle hatte und nicht die User- oder Systemlast der Grund hierfür war, sondern durch Memcached ausgelöste Software-Interrupts (%si in top), welche sich teilweise mit über 60% auf der ersten CPU bemerkbar machen. Es wurde ein weiterer Server dazugeschaltet, wodurch die Idlezeit der CPU auf 20-30% stieg und alles wieder schnell lief.

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.

]]>

Kernel 2.6.18 (Debian/Etch) vs 2.6.24 (Ubuntu/Hardy)

Michael — Fri, 17 Oct 2008 23:13:33 +0000

Beim analysieren der Auslastungen, der verschienden Server, viel uns auf, dass 2 unserer Datenbankserver, welche exakt die gleiche Aufgabe bei exakt gleicher Belastung, zwar in etwa die gleiche Load hatten, die CPU Last aber stark differierte.

Server 1 (Kernel 2.6.18)

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.

]]>

Upgrade auf Lenny und das PHP-Memcache Problem

Michael — Sat, 11 Oct 2008 20:21:36 +0000

Seit kurzem laufen alle unsere Webserver mit Debian Lenny. Im Vorfeld testeten wir das ganze auf einem Testserver, wobei auffiel, dass Memcache einige Keys nicht mehr fand und sich allgemein sehr komisch verhielt.

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.

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).
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.

]]>

Loadbalancing und ARP

Michael — Tue, 23 Sep 2008 06:45:35 +0000

Wir betreiben ca. 20 Webserver, alle laufen über eine HA-Loadbalancer-Lösung (High Availability). Hier gibt es zwei Möglichkeiten, wie das ablaufen kann. Zum einen NAT-Based, zum andren via direkt-return routing. Wir nutzen zweitere Möglichkeit, da sie performanter ist und weniger stark die CPU des Balancers belastet.
Beim direct-return routing wird der hereinkommende Traffic über den Loadbalancer zum Webserer geleitet, diese Antwortet dann aber nicht über den Balancer, sondern direkt.
Wichtig hierbei ist, dass die Domain auf eine bestimmte IP zeigt (z.B. 80.xx.xx.25), diese IP muss zusätzlich auf JEDEM Webserver eingerichtet werden. Und hier kommen wir zum Problem, vor dem ich vor kurzem stand.

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.

]]>

Mehr Performance für ext3

Michael — Sat, 06 Sep 2008 14:52:21 +0000

Wenn es um eine Hightraffic Seite geht, muss man im Sinne der Performance, oft Abstriche machen, wenn es um Datenkonsistenz geht. Ein Parameter, der beim mounten eines ext3-Dateisystems wunder vollbringt, ist noatime.

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!

]]>

GBit Netzwerkkarte läuft nur noch auf 100MBit und/oder Half-Duplex

Michael — Sat, 06 Sep 2008 14:20:41 +0000

Passiert ab und zu, selbst unser Ansprechpartner im Rechenzentrum, hat hierfür keine Erklärung.

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.

]]>

Mehr als 2 TB partitionieren/formatieren (ext3)

Michael — Sat, 06 Sep 2008 14:18:55 +0000

Beim Einrichten eines Backup-Servers mit ca 5,7TB Gesamtkapazität (Raid5), stand ich vor dem Problem, dass es mit den Standardtools nur möglich war, maximal 2TB ordentlich zu partitionieren.

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.

]]>