Wir brauchen mehr Serverpower
Ja genau, blocati hatte die letzten Wochen und Monate auf dem alten Server mächtig zu kämpfen und wir brauchten mehr Serverpower. Anfang letzten Jahres zog blocati auf den V-Server von meinem besten Kumpel um (blocati blockiert) und Anfang diesen Jahres bekam dieser mickrige Strato-V-Server ein aktuelles Debian Etch als Betriebssystem und ein ispCP Omega als Administrationsgrundlage verpaßt. Das Ergebnis war eine längere und recht aufwendige Fummelei, um den V-Server überhaupt halbwegs stabil zum laufen zu bekommen, da dieser durch die aktuelle Software bedingt mit dem viel zu klein dimensionierten Speicher der Strato-V-Server nicht so recht klar kam. Es gab dadurch 2 Wochen lang ständig die geliebten 500er Fehler von ispCP bzw. eigentlich von dem fastcgi-mod, welches bei ispCP aus Sicherheitsgründen Verwendung findet. Die gröbsten Probleme waren dann zwar seit Anfang Februar behoben, aber gelegentlich hing sich blocati immer noch auf - in ganz seltenen Fällen auch gleich der ganze Server. Meist lief nach etwa 5min alles wieder - aber eben nicht immer. Wegen dieser Probleme und weil es ohnehin schon längst geplant war, haben wir dann gestern blocati und die Domain mit den Buch-Rezensionen von Cati 
auf einen neuen Server verschoben: einen dicken Dedicated Server mit AMD X2 5600+ und 2GB RAM im Hetzner-Rechenzentrum. Auf dem Server sind bisher nur ein paar wenige kleine Domains drauf und nur eine davon schafft es durch ihr extrem grafiklastiges Forum trotz nur weniger Besucher in die Traffic-Regionen von blocati zu kommen. Für die nächsten Monate/Jahre sollte die Power also mehr als ausreichen und solange nicht allzu viel neues dazukommt, ist der jetzige Server auch bedeutend schneller im Seitenaufbau 
Logisch, so ein Umzug geht natürlich nicht völlig problemlos von statten - durchgeführt haben wir das ganze gestern Abend so gegen 19 Uhr und bei mir dauerte es einige Stunden, bis ich überhaupt das erste mal das Weblog hier vom neuen Server bekam. Auch ein ipconfig /flushdns auf meinem Windows-Rechner und ein Neustart meiner Fritz!Box (wo haben die da eigentlich den DNS-Cache versteckt? 
) halfen nicht weiter. Tja und nachdem ich gestern Abend bereits den neuen Server kurzzeitig zu sehen bekam, müssen mir heute früh wieder irgendwelche DNS-Server alte Daten geliefert haben, denn erst seit ca. 9:30 Uhr bekomme ich nicht mehr die im Kommentarbereich des alten Servers eingefügte Server-Umzugsmeldung. Nun denn, theoretisch kann man noch bis ca. 19 Uhr heute Abend gelegentlich mal den alten Server zu sehen bekommen - die TTL (Time to Life) des alten DNS-Servers war wie allgemein üblich auf 86400s eingestellt. Also nicht wundern, wenn da mal’n roter Hinweis auftaucht, das sollte sich heute noch legen 
Veröffentlicht von admin am Wednesday, den 26. March 2008 um 10:02 Uhr in IT (Technik und Internet).
Am 30. March 2008 um 18:04 Uhr
Auch nach dem Serverumzug gab es gelegentlich noch Probleme bei blocati. Vor allem dieses dämliche Yappy (eine aus 99% Spam bestehende “Gästebbuch-Community”) brachte es gelegentlich fertig, den Server gut runterzuziehen, weil diverse User Bilder von blocati direkt in die Gästebücher einbinden. Auch andere ähnliche Portale wie knuddels und eine Vielzahl von Foren bedienen sich ganz gerne mal an unserem Bildmaterial
Nun gut, diese Obergrenzen haben wir entsprechend angepaßt und jetzt sollte das gehen. Außerdem habe ich das am häufigsten verwendete Bild mal eben auf die meistverwendete Größe bei den Chat-Communities und Foren angepaßt und liefere dieses nur noch in 400×300 Pixeln aus. Ergebnis: 30-40% weniger Traffik pro Tag, krass 
Da dies über die kleine Copyrightnotiz in den Bildern aber auch den ein oder anderen User bringen dürfte, dulde ich das ganze bisher. Na jedenfalls hatten wir direkt nach dem Umzug ein bissel die Logfiles und Serverlast beobachtet - der Hammer war dabei eine Minute, in der über 60 mal Bilder von blocati durch Yappy-User abgerufen wurden und gleichzeitig kame neben mehreren Bots auch noch echte User vorbei. Das reichte dann dafür aus, dass die Standardwerte für die gleichzeitigen Zugriffe und entsprechende fast-cgi-Prozesse überschritten wurde und ein oder zwei User mit Sicherheit nichts zu sehen bekamen
Was leider immer noch etwas nervt, ist ein Fehler, der irgendwo im Adminbereich gelegentlich auftaucht und bei dem sich der zugehörige Prozess festfrißt. Anschließend muss man dann 5min warten, bis der Server diesen automatisch terminiert und man weiterarbeiten kann. Normale User sind davon nicht betroffen, man selbst ist dann halt nur kurzzeitig arbeitsunfähig
Ich hab zwar schon einiges aus dem Adminbereich gekillt und den Sourcecode heftig ausgemistet, aber irgendwas hakelt da immer noch und dank fehlender (aussagekräftiger) Fehlermeldung weiß ich bisher nicht so recht, was das Problem verursacht. Im sql-log findet sich nur eine kurze Noziz, dass ein Select nicht ausgeführt werden konnte - die select-Paramter werden aber nicht mitgeloggt und somit fehlt der Ansatzpunkt zur Fehlersuche … mpf ^^ Naja, zum Glück passiert das in der Regel erst, wenn man mehrfach hintereinander Artikel editiert und gespeichert hat. Auf anderen Servern habe ich damit jedoch keine Probleme und das obwohl bei mir überall noch ältere WordPress-Versionen laufen, bei denen ich nur die für mich relevanten Bugs manuell behoben habe. Genau das schließt allerdings auch die Hoffnugn auf Besserung durch WordPress-Updates aus, eben weil ich kein standardkonformes und updatefähiges WP mehr habe, sondern eine recht stark optimierte und umfangreich überarbeite ältere Version … Wäre aber auch langweilig, alles immer so zu machen, wie es 95% der anderen tun 