Linux

Eben las ich die für mich als Linuxfan freudige Nachricht, dass nach dem iPod (ipodlinux.org) auch das iPhone mit Linux läuft. Zwar läuft es nur sehr puristisch, d.h. keine Treiber für WLAN, den Touchscreen, Bluethooth usw. - aber es läuft immerhin, wie man auf dem Video sehen kann. Und dank Bootloader kann man jederzeit wieder auch die normale Apple-Firmware booten, ohne vorher technischen Aufwand betreiben zu müssen.

Generell ist es ziemlich cool, Linux auf alle möglichen technischen Plattformen zu portieren. Natürlich stellt sich die Frage nach dem Sinn, benutzbar wird wohl in diesem Fall auch nie richtig werden. Dazu ist die ursprüngliche Oberfläche einfach zu schön und ausgereift. Aber interessant ist es auf jeden Fall

In der Vergangenheit waren ja die Linux-Implementierungen auch manchmal deutlich besser als das Original. Man denke da nur an XBMC, das MediaCenter für die alte XBOX damals. Absolut traumhaftes Programm, welches ich samt XBOX heute noch im Einsatz habe Ohne XBMC wäre die alte Konsole wahrscheinlich schon längst im Keller gelandet.

Die iPhone-Variante scheint sich sogar recht einfach installieren zu lassen (Anleitung), allerdings werden wohl wichtige Teile des NOR-Speichers überschrieben, um den Boatloader zu installieren. Das vorher erstellte Backup sollte man daher unbedingt sicher verwahren. Mir ist das ehrlichgesagt zu heiss, da ich auch kein Gerät übrig habe derzeit. Es kommt übrigens Ubuntu 8.10 zum Einsatz, natürlich in ARM-Architektur entsprechend der ARM-CPU im iPhone.

Bin sehr gespannt, was da noch auf uns zukommt, Linux rocks on ...

Sehr interessiert verfolge ich seit einiger Zeit die Entwicklung von MySql-Cluster 6.4, also der nächsten Generation. Die aktuelle 6.3.19 läuft zwar sehr schnell und stabil, dennoch gibt es noch Raum für Verbesserung und Optimierung. So bringt die 6.4 endlich das online hinzufügen von Nodes mit sich, so dass man dazu nicht den ganzen Cluster stoppen muss. Das macht die Skalierung sehr viel handlicher und minimiert die Downtimes enorm. Außerdem werden endlich Threads unterstützt, so dass man aus einem Server mit mehreren CPU's bzw. Core's endlich sinnvoll auslasten kann. Aktuell langweilen sich sämtliche CPU's/Core's fast die ganze Zeit, während auf einem die Hauptlast liegt.

Im Blog eines Entwicklers der MySql-AB kann man nachlesen, dass 8 Core's dann wohl die Idealbesetzung sind. Ein Glück, dass ich damals Boards mit 2 CPU-Sockeln in den Nodes verbaut hab

Vielversprechend sind auch die Benchmark-Werte aus Jonas's Blog, so erreichte er gestern in Tests mit SCI-Karten stolze 1 mio. reads/s - auf einem Node! Man kann sich vorstellen, was so ein Cluster mit 64 oder gar 128 Nodes dann beantworten kann. In der Theorie dann sogar 100 mio+ reads/s. Angeblich will er mit TCP-Optimierungen dann auch via Ethernet solche Werte erreichen (1000 bzw. 10000 MBit/s). Würde mir natürlich sehr gefallen, denn in meinen 1HE-Kisten ist kein Platz mehr für SCI-Karten

Im Laufe der Zeit habe ich die verschiedensten Caching-Methoden ausprobiert, um irgendwelche Web-Applikationen zu beschleunigen. In der Regel will man damit Datenbanken entlasten, vor Allem wenn gleiche Query's tausendfach ausgeführt werden. Allerdings ist es in manchen Fällen so, dass der Aufwand den Nutzen nicht rechtfertigt bzw. sogar die Last durch das Caching höher ist, als durch die ursprünglichen Abfragen. Ich will hier mal am Beispie einer klassischen WebApp mit MySql-Backend ein paar Caching-Varianten samt meinen Erfahrungen darstellen. Zuerst einmal 2 Methoden, wie man mit MySql-Bordmitteln schon etwas erreichen kann:

Der MySql Query Cache speichert direkt auf dem MySql-Server die Ergebnisse einzelner Query's und liefert bei erneuter Abfrage nur das Ergebnis aus, ohne die Datenbank selbst erneut zu durchsuchen. Ganz abgesehen von den üblichen Limitierungen wie RAM und Anzahl der Query's im Cache ist das eigentliche Problem hier, dass nach JEDER Änderung in der entsprechenden Tabelle (INSERT/UPDATE) die Ergebnisse neu aus der Datenbank gelesen werden müssen (siehe z.B. hier). Somit fällt für mich der dieser Cache maximal unter "nice to have". Eine unter Last stehende Datenbank (in die meistens auch immer UPDATES oder INSERTS kommen) kann er aber wohl kaum entlasten ...

Eine weitere Alternative sind Tabellen vom Typ MEMORY. Leider unterstützt MEMORY keine BLOB- oder TEXT-Spalten, was sie z.B. für Volltextsuchen ungeeignet macht. Dennoch sind sie eine gute Alternative, wenn der DB-Server aufgrund vieler komplexer Abfragen sehr häufig auf die Festplatte zugreifen muss. Für Session-Tabellen beispielsweise ziemlich gut geeignet. Man sollte allerdings nicht vergessen, dass die Last nicht gänzlich vom DB-Server weggenommen wird, schließlich muss er die Anfragen weiterhin beantworten. Auch spielt natürlich der auf DB-Servern meist nur wenig vorhandene, freie RAM eine Rolle.

Caching-Methoden, die sich außerhalb des SQL-Servers abspielen:

Zuerst einmal gibt es natürlich Flatfiles, also einfache Textdateien, in denen man temporäre Daten als Cache ablegen kann. Bei kleinen Ergebnismengen, keiner hohen Last auf dem jeweiligen System und ausreichender Plattenkapazität kann auch dies einen Gewinn bringen. Allerdings ist es oft nicht sehr elegant zu bewerkstelligen, die alten Files zeitnah zu löschen bzw. vorhandene Files zu aktualisieren. Ein Cronjob kann da z.B. natürlich Abhilfe schaffen, man sollte aber die Limitierungen des jeweiligen Filesystems im Bezug auf maximale Ordner- und Datenanzahl nicht vergessen. Außerdem steigt die Load auf einem Server sehr schnell an, wenn diese Files sehr oft und zahlreich geöffnet/geschlossen werden. Auch ulimit kann hier eine Rolle spielen, sofern zu klein gesetzt.

Dann gibt es natürlich noch SQLite, was sich z.B. für kleinere Sachen als Auslagerung sehr gut eignet. Allerdings stößt man bei größeren Sachen schnell an die Filesystem-Grenzen, außerdem hatte ich in meinem Anwendungsfall mit recht hoher Last auf dem System zu kämpfen, wenn sehr viele Abfragen (nur SELECT's) auf die SQLite-DB's eingingen (Zugriff via PHP/PERL). Da war in diesem Fall sogar dann die Speicherung in Flatfiles effektiver. Außerdem hat man wieder das Problem mit der Wartung, denn man muss dafür sorgen, dass in den SQLite-DB's stets halbwegs aktuelle Informationen aus der MySql-DB liegen - je nach Notwendigkeit.

Nun kommen wir zu meinem klaren Favoriten memcached. Ich habe es selbst zigfach im Einsatz und bin einfach begeistert. Vor Allem die eingebaute TTL ist wunderbar, so muss man sich nicht darum kümmern, alte Einträge mühsam zu entfernen etc. Auch läuft memcached sehr stabil, verbraucht quasi null Rechenleistung und kann wunderbar hunderte Anfragen parallel bearbeiten. Ein besseres Caching-System kann man sich kaum wünschen. Allerding sollte man die Limitierung von maximal 1 MByte je Objekt beachten. In der Praxis stößt man aber nur sehr selten an diese Grenze. API's für die gängigen Scriptsprachen stehen bereit, so dass man seine WebApp damit recht einfach mit effektivem Caching versehen kann. Natürlich braucht man, je nach gewünschter TTL und Menge der Objekte entsprechend Server mit viel freiem RAM. Ansonsten ist memcached eine klare Empfehlung! Ein weiterer Vorteil ist, dass selbst bei einem Ausfall des memcached-Servers die Applikation weiterläuft, nur eben ohne Caching. Dank der Möglichkeit, memcached-Server verteilt aufzubauen, sollte das aber i.d.R. nicht vorkommen.

Natürlich macht es nicht in jedem Fall Sinn, einen Cache zu verwenden. Wenn man eine Website mit 20 Besuchern am Tag hat, kann man sich beispielsweise getrost lieber SEO widmen als Caching Auch bei sich permanent ändernden Anfragen/Ergebnismengen macht ein Cache wohl kein Sinn. Aber überall, wo sich Anfragen über einen recht kurzen Zeitraum zigfach gleichen und die Last auf der Datenbank recht hoch ist, macht ein Cache vielleicht durchaus Sinn. Wichtig ist auch, dass die Infrastruktur noch fähig sein sollte, auch ohne den Cache auszukommen (bzw. den Ausfall zu kompensieren), zumindest teil- oder zeitweise.

Am Wochenende wurde endlich das Telco-Release von MySql 5.1.29-RC mit NDB 6.3.19 freigegeben. Es wurden massenhaft Bugs behoben (Changelog), weswegen ich es heut direkt eingespielt habe. Das ist immer ein Akt, es müssen schließlich zuerst alle Management-Knoten, dann alle NDB-Knoten und zu guter letzt alle Server, wo mysqld rennt, auf den neuesten Stand gebracht werden. Besonders lange dauert jeweils der Neustart von ndbd auf den NDB-Knoten. Je nach Speicherauslastung und Config kann dieser Spaß schnell mal eine Stunde dauern - je Node! Das nennt sich dann "Rolling Restart" und erspart einem, das ganze Cluster herunterzufahren, was logischerweisee mit einer Downtime der Applikation verbunden wäre.

Auf jeden Fall habe ich die Chance mal genutzt, um ein kleines Benchmark beim kompilieren zu fahren. Ich habe also einfach mal die Zeit gemessen, wie lange make von mysql-5.1.29-ndb-6.3.19 dauert. Konfiguriert wurde jeweils --with-ndbcluster.

Da ich nur auf 2 verschiedenen Servertypen (QuadCore Xeon's und 2x Dualcore Opteron's pro Server, je AMD64-Architektur) kompiliert habe, fallen die Ergebnisse recht klein aus. Oben erst immer noch ein Teil von /proc/cpuinfo, danach die Ausgabe von time make:

model name : Dual-Core AMD Opteron(tm) Processor 2216 HE
cpu MHz : 2394.091
cache size : 1024 KB

real 12m28.244s
user 10m16.459s
sys 2m9.580s

und

model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
cpu MHz : 3166.775
cache size : 6144 KB

real 8m52.463s
user 6m56.326s
sys 1m17.081s

Wenig überraschend, dass der Xeon schneller fertig ist. Ich finde den Vorsprung von 1/4 aber doch schon beachtlich. Mal schauen, was dann die neuen AMD-CPU's so bringen werden (wenn verfügbar).