Manchmal kommt irgendwann im Leben einer Anwendung der Moment wo die Anwendung langsamer erscheint. Ein wichtiger Aspekt bei der Ermittlung möglicher Ursachen ist die Anforderung der Anwendung in punkto Massenspeicher.
Anzeichen für IO-Probleme
Wenn die Performance der Website oder der Datenbank zu wünschen übrig lässt, muss Ursacheermittlung betrieben werden. Hierzu können Sie die Ausgaben der üblichen Unix Tools wie top oder atop heranziehen. Der IOWait Wert von top ist schon einmal ein guter Indikator. Atop ist in der Lage dies auch auch auf Prozessebene anzuzeigen und darszustellen auf welchen Massenspeicher die IO-Last im wesentlichen geht. Monitoringsysteme wie auch das HKN Servermonitoring zeigen hier historische Trends auf und liefern grafische Auswerungen. Im Zweifelsfall gern beim Support nachfragen.
OK, es sind IO-Probleme – und nun?…
Nachdem klar ist, dass es IO-Probleme sind, die die Anwendung verlangsamen, gilt es die Gründe dafür zu finden. Oftmals lässt sich die Menge an IO-Anforderungen durch Konfiguration der Anwendungen bzw. Stacks deutlich reduzieren. Hier kommen die Nutzung von Caching (Redis, Memcached), die Anpassung von Datenbankabfragen und vieles mehr in Betracht.
Manchmal bringt auch eine Änderung des Stacks die Lösung. Als Beispiel mag die in dem weit verbreiteten CMS Typo 3 integrierte Volltextsuche gelten. Die Standardsuche des CMS arbeitet datenbankbasiert. Bei großen Websites mit mehreren tausend Dokumenten wird diese Suche sehr ineffizient. Die eigentlichen Datenbankabfragen erfassen sehr viele Zeilen. Durch intelligentes Design dieser Abfragen könnte man das eigentlich lösen. In der Praxis geht dies aber nicht, weil die Abfragen vom Framework generiert werden. Die wirkliche Lösung in dem konkreten Fall ist dann die Nutzung einer externen Suchengine. Typo3 bietet hier Support für Apache Solr und Elasticsearch an.
Ist IO – kann aber nicht geändert werden
Natürlich gibt es auch Situationen, in denen die Steigerung der IO-Perfomance die einzige praktikable Lösung darstellt. Hierfür bieten wir Instanzen an, die auf lokaler SSD laufen. Dies stellt die höchstmögliche Performance sicher. Allerdings muss hierbei beachtet werden, dass die Instanz in der Cloud damit auf einen Computenode festgelegt ist. Wenn dieser Computenode ausfallen sollte, werden die Daten und damit die Anwendung erst wieder verfügbar, wenn der Node recovered ist.
Wir nutzen hierfür ein RAID-System, dies stellt jedoch keine Garantie dar. Somit ist diese Lösung für Anwendungen sinnvoll die ihre Redundanz anderweitig sicherstellen. Ein Beispiel hierfür ist ein Mysql Cluster auf Basis von Galera. Wie sich hier eine Umstellung auf Local SSD auswirkt, ist in der Grafik deutlich sichtbar.
Zwischen Local SSD und unserem Standardspeicher Angebot gibt es als dritte Speicheroption Cloudbasierte SSD. Dies vereinigt die hohe IOPS Leistung der lokalen SSD mit der hohen Verfügbarkeit des Cloudspeichers. Der Nachteil ist, die im Vergleich zur lokalen SSD etwas höhere Latenz. Ein Vorteil hingegegen ist die höhere Skalierbarkeit, d.h. wir können hier grössere Volumes bereitstellen als bei lokaler SSD.
Sowohl Local SSD als auch Cloud SSD sind auf Anfrage beim Vertrieb verfügbar.