Software

Neues von der IBM Java Front. Wir haben die JVM inzwischen einigermassen stabil hingekriegt, nachdem wir MAXDATA so gesetzt haben, daß der native Heap für einen normalen Betrieb ausgereicht hat.

Da die Performance des Gesamtsystems aus diversen Gründen suboptimal war, wurde nach einer kurzen Evaluation die JVM einem Upgrade auf 1.5 unterzogen, da ein paar Tests einen Performance-Gewinn in der Grössenordnug von 30-40% versprochen haben (wohl hauptsächlich aufgrund eines verbesserten Garbage Collector). Bisher hat noch niemand nachgewiesen, ob die Performance damit wirklich besser geworden ist, da wir als Hauptursache des Problems -- binnen einer Stunde nach einem Start der Applikation wurde sie erst sehr langsam und stürzte dann mit einem Out-of-Memory ab -- einen etwas unkontrolliert wachsender Cache innerhalb der JVM identifiziert haben, den wir dann auch recht schnell bändigen konnten.

Seitdem die JVMs also wieder etwas länger laufen, gibt es das Phänomen, daß sie völlig unvermittelt stehenbleiben. Kein Eintrag im Log, truss zeigt keine Aktivität, man kann auch keinen Threaddump mehr schreiben. Nachdem wir mit etwas Mühe einen Speicher-Dump erzeugt haben, wurde die Ursache für den Stellstand von der IBM als ein ENOMEM in der libpthread identifziert. Juhu, schon wieder zu wenig native heap. Eine Überwachung mit svmon zeigt auch, daß sich der native heap mit der Zeit immer mehr füllt, selbst als wir noch etwas mehr Platz dafür freigeräumt hatten.

Ob wir damit einen Bug in der JVM gefunden haben oder sich der benötigte native heap schlichtweg drastisch vergrössert, ist noch nicht absehbar.

Meaningful error messages are good. Period. A lot of software badly sucks at this point. They throw "an error happened" or show a strange behaviour, but they don't say, that they cannot open a file because of missing access rights. I stress in application guidelines for java software, that every exception is getting caught and at least logged at an warning loglevel. This mechanism offers the possibility to increase the loglevel from the usual "ERROR" to something like "INFO" if we're debugging an issue.

Reale Crashtests in der Automobilindustrie sind kostspielig und zeitaufwendig. Eigentlich nicht notwendige Tests (etwa weil beim ersten Versuch vergessen wurde, den Kopf des Crashtest-Dummies zu montieren) sollten möglichst vermieden werden.
Braucht man allerdings ein Jahr später die Ergebnisse nochmals, dann wird man den Test nicht nochmals nachvollziehen; stattdessen holt man aus dem Archiv die Ergebnisse des gewünschten Tests. Das erspart einem unnötigen Stress mit dem Chef und beschleunigt die aktuelle Arbeit enorm.

Ähnlich verhält es sich bei Programmen. Aufwendig berechnete (Zwischen-) Ergebnisse werden vorgehalten, damit man bei Bedarf wieder darauf zurückgreifen kann, ohne die komplette Berechnung wiederholen zu müssen. Diese Zwischenspeicher nennt man üblicherweise Cache. (Die Hardware-Leute verwenden auch Caches, aber dort werden sie etwas anders verwendet. Ich beschränke mich hier auf die Software.)

Gespräch zwischen Software-Lieferant und Kunde:

Kunde: "Ich habe euch hier einen Speicherdump eurer Software; ich hab' mal versucht, eine Analyse zu machen, aber mein Rechner (1GB RAM) ist wohl zu klein dafür, hat eine diesbezügliche Fehlermeldung geworfen. Bitte macht ihr das, ist ja euer Job."

Lieferant: "So grosse Rechner haben wir nicht ..."

So geschehen im Jahre des Herrn 2007

Ich bin durch Zufall über einen wunderbaren Artikel gestolpert: Wie schreibe ich ein nicht-skalierbares Content Management System.

Es wird da allen Ernstes behauptet, das Datenbanken nur unnötige Komplexität haben und Personal brauchen, ein Filesystem dahingehend pflegeleicht und schnell sei.



Ich glaube, ich muss den Menschen mal einladen und zeigen, welche Probleme man kriegt, wenn man das Rad neu erfinden will. Wir setzen so ein filebasiertes Content Management System ein und haben sehr viel Spaß damit ...

Die letzte Zeit war es etwas ruhiger hier, aber anderswo hat es gewaltig geknallt.

Gegeben seien 2 Systeme, die gemeinsam auf ein Dateisystem lesend wie schreibend zugreifen müssen. NFS kommt aus diversen Gründen nicht in Frage. Dann bleibt im IBM-Umfeld GPFS übrig, das man dann auf SAN-Storage ablegt. Da man das Clusterfilesystem auch hochverfügbar haben will, wird das Filesystem auch gleich doppelt abgelegt auf zwei verschiedenen Storage-Systemen (quasi ein RAID 1 auf Schrank-Ebene).

Beide Systeme sind entsprechend grossem Blech virtualisiert (LPARs) und greifen mittels VIO auf das Storage zu. Jedes VIO hat daher Verbindungen zu beiden Storage-Systemen.

Dann ... fällt ein Storagesystem komplett aus. Zumindest derart, daß die Daten nicht mehr auf die Disks kommen. Und daß die Verbindungen zu diesem Storagesystem ausfallen. Tada, die Stunde der Hochverfügbarkeit hat geschlagen. Jetzt kann sich zeigen, ob das teure System sein Geld wirklich wert ist.

Was machen allerdings die VIO Systeme auf beiden Blechen? Sie fahren alle Verbindungen zu sämtlichen Storage-Systemen herunter. Auf beiden LPARs blockieren sämtliche I/O Aufrufe, während das Clusterfilesystem noch gemountet ist.

Diese Blockade der VIO Systeme lässt sich nur durch einen Reboot aufheben (nachdem das kaputte Storage auch richtig vom Rest der Umgebung abgetrennt wurde). Und weil die LPARs auch hängen, braucht man auch dort einen Reboot. Richtiges unmounten des Clusterfilesystems? Leider nicht möglich. Datenverlust bzw ein inkonsistentes Dateisystem ist zu erwarten.

Nach diesen Reboots und bangen Stunden, wie denn das Filesystem aussieht, die erlösende Nachricht: Hat wohl keine bleibenden Schäden erlebt. Nach dem Reboot konnten die Applikationen wieder hochgefahren und in Betrieb genommen werden. Was gut ist, denn ein Restore aus dem Backup hätte noch Tage gedauert, da ja nicht nur dieses System betroffen war; das Restore der weniger wichtigen betroffenen Systeme war dann 5 Tage später dran.

Jetzt hat es sich herausgestellt, daß die VIO da einen Bug gehabt hat; eigentlich hätten ja nur die Verbindungen zum defekten SAN-System gekappt werden dürfen. Das Testing des gefixten Treibers läuft...

Gegeben sei ein Clusterfilesystem (GPFS), das auf SAN liegt und auf zwei Knoten schreibbar gemountet ist. Man unterbreche jetzt entweder den Link zum SAN oder das Netzwerk, worüber die Synchronisation läuft (wozu hat man eigentlich IPMP?). Die Java-Anwendung, die auf das Clusterfilesystem Dateien schreiben will (sie arbeitet parallel auf beiden Clusterknoten und machen die Synchronisation über besagtes Clusterfilesystem), fällt natürlich auf die Nase. Verständlich, geht halt nicht anders. Nach ein paar Minuten ist wieder alles da, das Clusterfilesystem ist gemountet, man erwartet, daß alles wieder tut.

Ja, tut vordergründig auch. Die laufende Java-Anwendung kann bestehende Dateien öffnen, schreiben und auch korrekt wieder schließen. Nur, will man eine neue Datei anlegen, kommt weiterhin die Fehlermeldung " Ich habe gar kein Filesystem, wo ich drauf schreiben kann". Wunderbar. Schon allein die Detektion dieses Problems ist schwierig, weil diese Anwendung so wunderbar gestrickt ist, daß ihr das vollständig egal, daß die Schreibaktionen fehlschlagen. Sie jammert nur ein bisschen ins Log und gut ist. Dem Anwender gaukelt sie vor, alles sei erfolgreich gelaufen. Man könnte ihn ja mit einer Fehlermeldung überfordern.

Man mache jetzt aus irgendeinem Grund einen Restart. Sehr schlechte Idee. Nach dem Restart ist natürlich von den angelegten Dateien nix mehr da. Wenn man die Logfiles nicht auch noch auf dem Clusterfilesystem liegen hat (immer eine sehr gute Idee, die Logfiles lokal auf Platte zu haben), kann man die Reste identifizieren und vielleicht eine Abschätzung machen, wo denn überall Nach(t)arbeit notwendig ist.

Man lerne: "HA-Cluster" und entsprechendeclusterfähige Dateisysteme sollten man nicht einfach mal kaufen (selbst wenn I** draufsteht), sondern zumindest mal ernsthaft mit der eigenen Applikation testen. Sonst macht man nämlich aus einem 5minütigen Netzwerkausfall in der Nacht die verlorene Arbeit von 20 Benutzern an einem Tag.
Ausrede: Beim S*-Cluster in der vorigen Umgebung war das nie ein Problem. Es gab schlichtweg keine Ausfälle des Clusterfilesystems.

Der Auftrag heute: Eine JVM mit 2G Heap (bitte keine Fragen, warum man soviel Heap braucht) unter AIX stabil zum Laufen bekommen. Bisher crasht das alle paar Tage, weil der native heap voll ist und das ganze dann sang- und klanglos umfällt.
(Der native heap ist der Teil des Heaps, der von dem nicht-Java Code innerhalb einer JVM gebraucht wird. Wenn man von einer Sun-JVM kommt, interessiert das einen überhaupt nicht. Da stellt man einfach eine Heapgrösse von 2 Gigabyte ein und fertig. Alles läuft stabil.)

Beginnend mit einer Dokumentation auf IBM Developerworks, die einem mit Begriffen bewirft, die man eigentlich gar nicht wissen will; dann der IBM Java diagnostics guide, der einem für AIX erstmal die Grundlagen der Speicherverwaltung erklärt (warum interessiert mich, daß alles segmentbasiert ist und man mittels geeigneter Umgebungsvariablen eine gewisse Menge dem Java-Heap zur Verfügung stellen kann? Ich will doch nur eine stabile JVM mit 2GB Heap!); am Ende findet sich dann noch diese Seite, die noch einen anderen Weg erklärt, wie man das unter einem aktuellen AIX hinkriegt (vorher aber kriegt man wieder die Schemata der Speicherverwaltung erklärt). Ob das ganze Zeugs funktioniert, habe ich noch nicht testen können.
Und am Ende stellt sich wahrscheinlich heraus, daß die JVM der AIX Heap-Fragmentation zum Opfer gefallen ist.

Himmel, ich will kein nicht die Interna verstehen, ich will nur eine JVM zum Laufen bringen. Ist das so schwer? Mit einer Sun-JVM mach ich einfach nur -Xmx2048m und es läuft.

(Ja, die IBM-Doku ist nicht schlecht. Aber wenn die das ganze einfach mal richtig (einfach) machen würden, bräuchte man das alles gar nicht.)

Völlig unverständliche Einschränkungen, die man nicht erwartet, aber wenigstens ist alles einwandfrei dokumentiert:

Auf dem Gang vor dem neuen Büro hängt ein Motivatiosbildchen, das wohl mal als gute Idee gedacht war, aber inzwischen längst dem mentalen Filter aller Vorbeigehenden anheim gefallen zu sein scheint, wenn man so das alltägliche Chaos betrachtet.



Im Gegensatz zu Hipp Babynahrung, wo der Firmenchef selbst in der Fernsehwerbung auftritt und seinen Spruch "Und dafür stehe ich mit meinem Namen" loslässt, wird diese Aussage niemandem in den Mund gelegt. Schade eigentlich, denn damit ist mal wieder klar, wer diesen Standpunkt, der so plakativ im Raum hängt, vertritt. Nämlich niemand. Das plakative "wir" hat dann nämlich dieselbe Bedeutung wie das "Toll, ein anderer macht's" "Team".

(In "capital letters" kann man sehr viel schreiben, wenn man es nicht umsetzen muss.)

Die allermeisten Webmaster sind an den Zugriffszahlen auf ihre Webseiten interessiert und benutzen Werkzeuge (awstats, modlogan, webalizer), die ihnen diese gewünschten Zahlen aus den Logfiles der Webserver extrahieren. Allerdings sind diese Zahlen notorisch unzuverlässig, da sie nur einen sehr kleinen Einblick gewähren, wie oft Zugriffe auf die Webseite erfolgen; interessante weitere Informationen (beispielsweise wie oft ein Benutzer auf die Webseite zugegriffen hat oder in welcher Reihenfolge er die Seiten auf der Webseite durchstreift) kann man daraus aber nicht herauslesen.

Bei der täglichen Arbeit ist mir letzthin ein Ant-Problem umgekommen, das im Kontext meines Artikels aufgetreten ist. Das Problem war, daß gewisse Properties von einem zur Ausführungszeit bestimmten Wert abhängig gemacht werden sollten; in meinem Fall war, daß IP-Adressen abhängig von dem Namen der Maschine eingetragen mussten.

wenn ihr meint, daß Euer (Web) Content Management System jede Änderung an einer Seite aufzeichnen und abspeichern soll, ist das eine gute Idee. Nicht so toll ist es allerdings, wenn alle Daten im Dateisystem liegen. Nun gut. Wenigstens habt Ihr daran gedacht, die älteren Versionen nicht in dasselbe Verzeichniss zu speichern wie die aktuelle Version; stattdessen baut ihr aus den internen IDs der Seiten (man nehme jeweils die Hashes der paar Verzeichnissnamen im logischen Pfad zu dieser Seite und hängt hintendran nochmals einen Hash über den Rest und schon hat man diese ID) einen Verzeichnissstruktur und schmeisst dort diese älteren Versionen wieder rein. So einfach, so gut.

Verschlüsselte Verbindungen sind oftmals ein Muss; sobald in irgendeiner Art vertrauliche Daten (und seien es nur Passwörter für das Einloggen auf einer bestimmten Seite), sollte man gesicherte Verbindungen benutzen.

Viele web-basierte Anwendungen prüfen deshalb, ob sie bei der Durchführung bestimmter Aktionen (beispielsweise bei der Verarbeitung persönlicher Daten) die Daten über eine verschlüsselte Verbindung erhalten. Das geht noch ziemlich einfach, wenn diese Anwendung die Verschlüsselung direkt durchführt; dann steht die Information "Diese Daten kamen über eine verschlüsselte Verbindung" nämlich direkt zur Verfügung.

Nachdem ich die eigene Webseite mehrere Jahre lang offline mit der Website Meta Language gepflegt habe, ist dieses System einer etwas grösseren Umstrukturierung der Seite zum Opfer gefallen; schlussendlich hatte ich auch keine Lust mehr, dieses Verhau aus Perl-Skripten und m4-Makros zu verstehen und zu erweitern, um ein paar Annehmlichkeiten in die Seite einzubauen.

Deshalb bin ich jetzt schon seit einiger Zeit auf der Suche nach einem kleinen CMS, mit dem ich meine Webseite pflegen kann. Meine Ansprüche daran sind dabei gar nicht so riesig:

• Implementierungssprache beliebig, auch wenn ich im Moment Java vorziehen würde.


• Datenbank: Keine, postgres oder mysql


• Editieren über ein Webinterface


• Einfache Benutzerverwaltung


• Erscheinungsbild anpassbar (Templates oder ähnliches, wobei das Selbstgestalten/Anpassen auf meine Wünsche kein Problem ist).


• Erweiterbar (für eigene Spielereien)

Der Open-Source Markt ist bezüglich dieser Ansprüche in Hinsicht auf Java-Implementierungen leer. Nicht existent. Nix. Entweder Frameworks oder gleich auf Gross-Unternehmen ausgerichtet.

(Warum ich kein PHP mag: Bauchgefühl. Aber scheinbar werd' ich nicht darum herumkommen.)