Kategorie: buntes, statistisches

Als ich damals meinen Blog benannte sahen leistungsstarke Server noch so aus.

Nun, die Server sind inzwischen etwas größer.

Und ich werde das Blog nicht umbennen.

„Der GC wird’s schon richtig“ passiert mir zu häufig bei Java-Applikationen, in diesem Fall eine nicht weiter aufwändige Web-Applikation mit ungefähr 400 Benutzern – zur Haupnutzungszeit müllt das Miststück den Heap in 20 bis 30 Minuten um rund 7 GB zu.

Ich vermute[1], dass die Entwickler beim XML-Parsen die Xerces-Instanz nicht sauber beenden, sondern auf den GC vertrauen, der dann ja schon irgendwann die nicht mehr genutzten Klassen finalisiert und _irgendwann_ aus dem RAM wirft. Bei uns ist dieses irgendwann rund 8 Stunden nach Ende der Hauptarbeitszeit erreicht, erst dann sinkt der Heap-Verbrauch der defakto seit *Stunden*[2] ungenutzten Applikation auf unter 1 GB.

Meiner Meinung nach krankt Java vor allem daran, dass es zu unsauberem programmieren verführt – und, total enterprisey, dann Frameworks über Frameworks gestapelt werden, ohne dass sauber designt wird.

Rant Ende.

[1] simples Class-Histogramm, auf den Code habe ich keinen Zugriff und zum Dekompilieren ist es noch nicht kritisch genug
[2] aufgrund unserer Kundenstruktur ist das Nutzungsverhalten stark zyklisch und vorhersehbar

nachdem ich dann innerhalb von 11 Tagen die Bahn ausgiebig nutzte (Augsburg-Bückeburg-Osnabrück-Augsburg-Marburg-Augsburg-Konstanz-Augsburg) habe ich erst mal keine Lust mehr auf „Alle reden vom Wetter. Wir nicht“ (wobei sich erstaunlicherweise die Verspätungen nur auf unter zwei Stunden aufsummierten, obwohl ich auch an den Tagen unterwegs war, an denen die DB empfahl, doch bitte nicht mit der DB zu fahren…).

Und am grässlichsten zum Rumstehen ist immer noch Kassel-Wilhelmshöhe, meiner Meinung nach wurde der Bahnhof so konstruiert, dass das Maximum an Wind exakt auf die Bahnsteige fokussiert wird.

Die Gesamttour mit den Umsteigebahnhöfen sah dann so aus…

(Karte basiert auf Germany location map.svg von NordNordWest, veröffentlicht unter CC-by-sa-3.0)

So ein Wohnzimmerhost hat Nachteile – es ist immer sofort ersichtlich, wann bei mir im Wohnzimmer jemand übernachtet…

(und ich habe meinen Guard-Status im Tor-Netz verloren – menno)

Gestern hat mein ISP dann das 16000er-DSL aufgeschaltet – schön zu sehen am Tor-Durchsatz, das Programm zieht wirklich alles an Bandbreite, was nur zu holen ist.

Ich werde mir das ein paar Tage anschauen und dann den erlaubten Durchsatz von Tor dementsprechend anpassen – aber das surfen ist auch jetzt schon deutlich angenehmer als vorher.

Auf ein paar der Authority-Directory-Servern gilt mein Tor-Knoten inzwischen als Stable und ist schnell genug, dass er das Flag „Guard“ erhalten hat – eine Kennzeichnung für die bevorzugte Nutzung als erster Knoten in der Anonymisierungs-Chain, ich werde mal abwarten, inwieweit das die Bandbreitennutzung noch ändert, ich bin gespannt.

Auf dem Xen-Host ist weiterhin tote Hose – der Monatsgraph ist dann doch eher langweilig.

Aber da wird sich auch erstmal nicht tun, ich spiele ja jetzt Projektmanager und werde mich da erst mal um weitere User Requirements kümmern (so ganz lehrbuch-best-practise-mäßig, habe ein Haufen Bücher dazu ins Büro geschleift) und das Redesign anpacken – aber dazu brauche ich erst mal eine belastbare Zusage vom Chef, dass wir einen feature freeze machen dürfen und uns neben der Planung und Durchführung des Redesigns nur noch um Bugs kümmern, ich möchte es vermeiden, dass wir uns verzetteln.

Na, mal schauen.

PS Zum Vergleich – so sieht die Last auf meinem Wohnzimmerserver mit YaCy, Tor und BackupPC aus:

…, es produziert viel Last.

Das ist eine Ansicht der Prozessorauslastung auf einer der Tomcat-Kisten – ich bin heute mehr oder weniger durch Zufall drüber gestolpert, automatische Warnmeldungen erhalte ich erst ab 80% Auslastung.

Auf der (virtuellen) Box läuft eigentlich nur eine einzige Applikation: Unsere Groupware in einem Tomcat-Container – spontan konnte mir mein Coder auch nicht verraten, was regelmäßig Samstags um Mitternacht losläuft und dann den Rechner für 15 – 20 Stunden ziemlich quält.

Durch die – ähem – etwas ungeschickte Logfile-Konstruktion (das Applikationslog wird beim durchstarten der Anwendung überschrieben) habe ich für letzten Samstag leider nichts mehr zum anschauen da, aber eines ist sicher: Sonntag kriege ich raus, was da warum losläuft :)

Update: Ich Depp, man sollte Verfahrensweisen nicht einfach so zwischendrin mal ändern – gotbrain hat ja vermutet, es läge am crontab, was ich beruhigt von mir weisen konnte. Warum ich auf diesem Server den Virenscan ausnahmsweise und untypisch aus /etc/cron.d/ ausführe, kann wahrscheinlich niemand beantworten…

Die ganze Idee von diesem Blog war ja ursprünglich mal, die Serverkonsolidierung mit Xen anhand von einem konkreten, wirklichkeitsnahen Beispiel zu erläutern – ich habe mich eindeutig nicht dran gehalten, doch als Ausgleich jetzt einmal ein Überbick, über das was war, ist und wird.

Ein Ausschnitt aus xentop ergibt zur Zeit folgendes Bild:

Zu den virtuellen Boxen im einzelnen ein paar Worte.

Caliban ist ein Debian-Server, genutzt für die alten Projekte mit einem MySQL 4.0, installiert direkt aus den Paketen von Sarge. Die Last auf dieser Box ist zur Zeit sehr hoch, da zur Zeit die Datenaufbereitung für ein Abschuss eines Projekts stattfindet – heute abend weise ich dem Ding mal mehr Speicher und eine weitere CPU zu (ich _mag_ Virtualisierung :) ). Caliban ist übrigens ein Uranus-Mond, Planeten sind hier traditionell Servernamen und ich führe das jeweils mit passenden Monden weiter…
Domain-0 ist der eigentliche Xen-Host, normalerweise war die Last bei tendentiell 0.0 – bis dann
Gruenehoelle kam, ein mit Intel VT virtualisierter Windows-2000-Server, der als File-, SQL- und Lizensierungsserver für dieses Produkt dient. Xen nutzt die VT-Prozessorerweiterungen mittels QEMU, was augenscheinlich noch nicht wirklich verlustfrei geschieht.
Mond ist ein Tomcat-Applikationsserver für die hauseigene Groupware, die Namensgebung hat selbstverständlich nichts damit zu tun, dass die Groupware auf den Mond geschossen werden soll, sondern ist einfach der Nachfolger für den Server Erde. Die Applikation ist sehr variabel in der Ausnutzung von Ressourcen, obwohl sie bei der Erstellung der obigen Tabelle kaum aktiv war, sind immer mal wieder die beiden zugewiesenen Prozessoren voll ausgelastet.
Neith ist der Tomcat für alle Test- und Demo-Versionen unserer J2EE-Applikationen, weiter nicht erwähnenswert, nur bei der Namensgebung mußte ich etwas mogeln – Venus hat keine Monde, aber 1672 dachte der Astronom Cassini, er hätte einen gefunden.
Phoebe dient als Webserver und ist natürlich ein Saturn-Mond.
Pomona ist ein MySQL-Server in der Version 4.1, mit etwas hängen und würgen läßt sich ein solcher auch unter Etch installieren. Pomona ist übrigens die Göttin des Obstsegens, da der ursprüngliche Server Apfelbaum hieß – absolut untypisch, nach Bäumen heißen hier sonst nur Desktops.
Upsand ist ein neu aufgesetzter Debian-Server mit Tomcat 5.5, MySQL 5 und Java 6, an diesem werde ich die Testversionen unserer Applikationen mit aktueller Basissoftware austesten, Ups And ist ein Sternensystem mit Exoplaneten, ich dachte mir, dass so überraschende Änderungen wie das verpassen von 2 Java-Releases und jeweils einem Major-Release von Tomcat und MySQL einen weit entfernten Namen verdienen.

Mein Laptop (so ein Billig-Fujitsu-Siemens, war ein Notkauf nachdem mein alter während der Diplomarbeit leider die Füße von sich streckte) hat ziemlich genau 1/8 der Leistung des Xen-Hostes, gegenübergestellt sieht das ungefähr so aus:

So unterschiedlich sind die beiden Boxen von der Grundlage her nicht – außer eben, dass der eine ungefähr acht mal so viel Leistung haben sollte.

Ich nutze jetzt meinen Laptop als reine Desktop-Büchse mit grafischer Oberfläche, diversen ständig laufenden Programmen (Instant Messenger, Mail, Browser – Zeug eben), auf dem Server sind einige virtualisierte Maschinen mit MySQL-Servern, Apaches und Tomcats am laufen – alles in allem eine diametral andere Nutzung.

Dies läßt sich auch an den Diagrammen zur CPU-Last erkennen, trotz permanent laufender Serverdienste (insbesondere die J2EE-Applikationen werden von etlichen Usern parallel genutzt) langweilt sich die große Box weiterhin…

Die Migration schreitet voran, heute habe ich alle unsere Testsystem in virtualisierten Kisten untergebracht und erneut einen Server abgeschaltet. Meine Quote dabei ist ganz gut, 13 mal Metall läuft noch, insgesamt habe ich in meiner Zeit hier zwei neue Kisten und eine alte angeschaltet – und im ganzen fünf rausgeworfen.

Zwar nicht ganz das, was der Abschalttag meint und auch etwas am Termin vorbei, aber immerhin. Drei der jetzigen Server werden noch in virtualisierte migriert, zwei fallen raus sobald die Projekte dazu abgeschlossen sind – es lichtet sich.