Der Anfang vom Ende von NetBeans?

Die Tage erreichte mich die folgende Mail:

Dear NetBeans Community:After thorough consideration, we have taken the difficult step to discontinue support for Ruby on Rails in the NetBeans IDE. Two main issues underpin this decision:

Java SE 7 and Java Development Kit 7 (JDK 7) are the next major releases of the Java SE platform, which Oracle is committed to deliver in 2011. A key objective of the NetBeans IDE has always been to offer superior support for the Java platform. To maintain that objective and capitalize on the JDK 7 release themes–multi-language support, developer productivity and performance–it is necessary that our engineering resources are committed to a timely and quality release of NetBeans IDE 7.0.

Second: Although our Ruby support has historically been well received, based on existing low usage trends we are unable to justify the continued allocation of resources to support the feature.

As of January 27, the Ruby on Rails module will be gone from development builds of NetBeans IDE 7.0. Developers who want to continue to use Ruby on Rails functionality in the NetBeans IDE should please visit the NetBeans Ruby Support page for details on how to do so going forward.

We remain committed to delivering a first-class product to our community of developers and users, and we encourage your feedback on our mailing lists and forums, on Twitter, or by writing to us.

Thank you for your continued support of NetBeans.
The NetBeans Team

Dies finde ich relativ bedauerlich. Ich nutze NetBeans seit langem als Entwickler für php-Seiten. So für meine Ausflüge in die Ruby on Rails Welt nutzte ich dann natürlich auch NetBeans. Nicht zuletzt aus dem Grund, weil es sowohl in der Windows-Welt wie auch auf Mac OS X gleich funktioniert.

Als Alternative habe ich mir schon mehrfach Eclipse angeschaut. Doch leider habe ich es nie stabil zum Laufen bekommen. Meistens scheiterte ich bereits mit dem Nachinstallieren diverser Erweiterungen.

Jetzt bleiben evtl. die Tools von JetBrains: PHPStorm und RubyMine. Letzere gibt es bis Mitte Februar zum Aktionspreis von 26,00 Euro plus MwSt.

John le Carré: Verräter wie wir

Mehr oder weniger zeitgleich mit dem neuen Roman von Frederick Forsyth, Cobra erschien der Roman Verräter wie wir von John le Carré. Ich muss sagen, dieses Buch liest sich bedeutend anstrengender als  Cobra. Die Handlung ist zu Beginn sehr viel als Erzählung der beiden Hauptfiguren geschrieben. Es wird immer wieder zwischen der Erzählung und der Gegenwart gesprungen. Gespickt wird dies durch häufige Anspielungen, die man zunächst nicht versteht. Dies macht die Handlung schwer zu verfolgen.

Im Roman selbst geht es um die Anbahnung eines Überlaufens eines Geldwäschers, der für die russische Mafia tätig ist. Mehr ist da nicht. Ich kann dieses Buch daher nur bedingt empfehlen. Ein zweites Mal lesen würde ich es auf keinen Fall.

Frederik Forsyth: Cobra

Den neuen Forsyth habe ich förmlich verschlungen. Er liest sich in einem weg. In diesem Roman geht es um ein (leider) zeitloses Thema: den globalen Kokain-Handel. Die Handlung ist nicht zu verwirrend, aber auch nicht gerade „straight on“. Einzig der bei jedem Forsyth vorhandene Schlussgag fällt diesmal nicht so überraschend aus. Er ist nicht so verblüffend wie der im Schakal zum Beispiel.

Auf jeden Fall ist das ein Buch, das man uneingeschränkt empfehlen kann. Jeder, der die anderen Romane von Frederick Forsyth gemocht hat, wird auch diesen gerne lesen.

Back to the roots

Nachdem ich nun die Nase voll habe und ich auf dem neuen vServer folgende Apache Einstellungen gemacht habe

StartServers                2
MinSpareServers             2
MaxSpareServers             2
MaxClients                  3
MaxRequestsPerChild       100

schlug mir der Support von vollmar.net, den ich bisher immer als sehr kompetent erlebt habe, allen Ernstes vor, ich möge doch die Ressourcen weiter herabsetzen, um zu sehen, ob dann das Swappen aufhört.

Mehr geht aber nicht, da sonst der Apache erst gar nicht mehr gescheit antwortet. Auch das Setzen von Limits bei PHP selbst wurde vorgeschlagen. Aber auch das wird nichts bringen, da dann höchstens Skripte abbrechen. Vielleicht könnte man in der Tat ein wenig an MySQL rumdoktorn. Aber ich denke, das wird dann auch nicht mehr viel bringen.

Ich bleibe dabei: Der neue vServer ist einfach zu schwachbrüsting, um ein LAMP-System, wie es out-of-the-box von Debian lenny mitkommt zu bedienen.

Aus diesem Grund habe ich dann doch wieder alles auf den alten vServer zurück geschraubt.

Und weiteres Rumgestocher

Ich habe den Tag heute damit verbracht, auch auf dem alten vserver einen aktuellen Apache samt aktuellem php zu installieren.  Ich wollte nun endlich einen Vergleich zwischen alt und neu haben. Und siehe da, auf dem alten Server sieht die Speicherauslastung wie folgt aus:

Mem:    128000k total,    53408k used,    74592k free,        0k buffers
Swap:  4194296k total,   399980k used,  3794316k free,        0k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP COMMAND
29499 mysql     15   0  124m  18m 5036 S  0.0 15.0   0:00.06 105m mysqld
 7540 www-data  15   0 18476 9624 2564 S  0.0  7.5   0:00.00 8852 httpd
 7544 www-data  15   0 18472 9620 2564 S  0.0  7.5   0:00.00 8852 httpd
 7547 www-data  15   0 18476 9624 2564 S  0.0  7.5   0:00.02 8852 httpd
 7548 www-data  17   0 18476 9624 2564 S  0.0  7.5   0:00.01 8852 httpd
 7549 www-data  15   0 18476 9624 2564 S  0.0  7.5   0:00.00 8852 httpd
 7541 www-data  18   0 18472 9624 2568 S  0.0  7.5   0:00.01 8848 httpd
 7543 www-data  15   0 18472 9644 2564 S  0.0  7.5   0:00.04 8828 httpd
 7546 www-data  19   0 18472 9644 2564 S  0.0  7.5   0:00.02 8828 httpd
 7545 www-data  15   0 18464 9644 2564 S  0.0  7.5   0:00.02 8820 httpd
 7542 www-data  15   0 18476 9732 2640 S  0.0  7.6   0:00.04 8744 httpd
 7534 root      18   0 18116 9676 2868 S  0.0  7.6   0:00.01 8440 httpd

Der neue Server hingegen verbraucht deutlich mehr Speicher:

Mem:    127828k total,   121268k used,     6560k free,      636k buffers
Swap:   262136k total,    95884k used,   166252k free,    19144k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP COMMAND
 7548 mysql     20   0  222m 4332 1700 S  1.0  3.4   0:44.74 218m mysqld
 1629 www-data  20   0  125m 1408  884 S  0.0  1.1   0:01.84 124m httpd
 1627 www-data  20   0  124m 1388  876 S  0.0  1.1   0:01.82 123m httpd
 1628 www-data  20   0  124m 6356 1104 S  0.0  5.0   0:01.57 118m httpd
  402 root      20   0  118m  556  384 S  0.0  0.4   0:17.96 118m rsyslogd
 1632 www-data  20   0  124m  17m 1608 S  0.0 14.4   0:01.83 106m httpd
 1624 root      20   0  106m 1184  728 S  0.0  0.9   0:00.08 105m httpd
 1631 www-data  20   0  124m  21m 2596 S  0.0 17.6   0:00.52 102m httpd
 1630 www-data  20   0  125m  22m 2800 S  0.0 18.4   0:02.41 102m httpd

Auf dem alten Server läuft WordPress wie erwarten so, wie man sich das vorstellt.  Mittlerweile frage ich mich, was man überhaupt auf dem neuen Server machen kann, ohne dass er sich tot-swappt. Ich bin schon kurz davor, alles auf dem alten Server weiterzubetreiben. Nur wollte ich das Updaten der Distribution vermeiden…

Erste Erkenntnisse

Ich habe heute erste Schritte zur Anaylse unternommen:

Zunächt habe ich wie vom Provider vorgeschlagen den swap-Speicher komplett deaktiviert. Ich dachte mir aber schon, dass dies keine gute Idee sein kann. Der Apache konnte dann erwartungsgemäß keine Child-Prozesse mehr forken.

Also habe ich mich daran gemacht, den Apache und PHP selbst zu kompilieren. Erstes lief straigt forward durch. Bei PHP musste ich dann aber schon anfangen zu tricksen. Ich merkte schon, dass das Compilieren recht lange dauerte. Ein kurzer Blick ins laufende

vmstat 1

zeigte auch gleich, wohin der Hase läuft. Auch hier war der Kernel mächtig am Swappen. Es kam sogar soweit, dass der Vorgang abbrach, weil der virtuelle Speicher ausging.

Nun gut. Ich habe also erstmal ein zusätzliches Swap-File angelegt. Das ist zwar nicht performant. Davon war ich aber sowieso schon meilenweit entfernt. Nach gefühlten Ewigkeiten war PHP dann doch glücklich compiliert. Voller Hoffnung startete ich diesen Apache. Doch leider zeigte sich hier das gleiche Schreckensbild.

Ein paar kurze Versuche mit simpleren php-Skripten ließen ein etwas besseres Bild. Die Frage ist daher, ob vielleicht WordPress nicht ein Hauptgrund ist. Da aber ja auch das Compilieren von PHP zunächst auf die Bretter ging, denke ich, dass einfach der Hauptspeicher von 128MB für diesen virtuellen Server zu klein. Das Verrückte ist, dass auf meinem alten virtuellen Server diese 128MB völlig ausreichen sind. Vermutlich ist der Wechsel von 32-Bit auf 64-Bit, die leider nicht vorher zu erkennen waren, der Grund für diesen Speicherhunger.

Als Notmaßnahme habe ich nun erstmal die Anzahl der Apache Prozesse auf 2 (in Worten zwei) zurückgeschraubt!

Mal schauen, was aus meiner Support Anfrage wird. Ich sehe zwei Alternativen. Entweder ich gehe zurück auf den alten Server. Dort habe ich zumindest schon die aktuellen Orte der Debian-Quellen eingetragen. Oder aber ich stelle um auf mehr Hauptspeicher. Mit nur 128MB ist aber dieser Server aus meiner Sicht nicht zu gebrauchen.

Ein Umzug

Nach nun recht langer Ruhe auf diesem Blog, habe ich mich dazu entschlossen, mal was neues auszuprobieren:

Ich habe auf WordPress umgestellt. Aber nicht nur das. Ich habe dies zum Anlass genommen, auch meinen virtuellen Server, den ich bei vollmar.net angemietet habe, zu aktualisieren.

So habe ich also mich die letzten Tage damit befasst, den neuen Server einzurichten, um dann WordPress zu installieren. Dies geht auch recht zügig — aber dann…

Ich machte mich zunächst an den Import der alten Meldungen – samt Kommentare. Das war meine Vorgabe. Und siehe da, mit ein bisschen Stöbern klappte das recht gut.

Der nächste Schritt war die Layout-Anpassung. Da muss ich gestehen, habe ich (zunächst) den Stecker gezogen. Um mein altes Layout zu übernehmen, hätte ich doch zu sehr in die Materie eintauchen müssen. Also habe ich das erstmal zurückgestellt.

Nach dem Umschalten war die Entäuchung erstmal ziemlich gross. Grottenlahm war der Auftritt. Bei jedem Request swappte das System munter vor sich hin. Was hatte ich geändert?

  • Statt Apache 1.3 ist’s nun ein Apache 2.2
  • Statt selbst-compiliert nun das Debian Paket
  • Statt MySQL 4 nun MySQL 5
  • Statt selbst geschriebenes CMS WordPress

Ich stellte sehr schnell fest, dass der Apache viel Speicher fraß und ihn nicht mehr hergab. Also habe ich erstmal die Ressourcen dort begrenzt. Weniger Prozesse, weniger Keep-alive. Schön finde ich es nicht. Aber es tut’s erstmal. Vielleicht baue ich mir dann doch nochmal einen eigenen Apache samt eigenem php….

Was das Layout betrifft, so werde ich mich sicherlich damit auch noch befassen, zunächst muss es aber erstmal ein Standard Theme sein.