datenklause.de » Support

Support-Anfrage

sirko — Mon, 20 Sep 2010 14:35:25 +0000

“Habt Ihr ffmpeg auf den Webservern installiert?“.

Nö. Die Leistung wäre ja da, aber wir wären ja schön blöd.

Support in Sütterlin-Schreibschrift

sirko — Thu, 05 Aug 2010 13:10:15 +0000

Ein Kollege zeigte mir gerade eine Mitteilung eines Kunden. In Sütterlin-~~Schreibschrift~~ Sauklaue. Man kann gerade noch lesen, was er will, nämlich seine Bankverbindung ändern, aber seinen Namen können wir beim besten Willen nicht entziffern.
Hmm.

Grütze zippen

sirko — Fri, 23 Jul 2010 14:03:26 +0000

Ein Kollege hat das hier umgesetzt, wir haben jetzt ein viel, viel genaueres Accounting auf dem Cluster. Die Intervalle zur Auswertung sind frei wählbar.
Und einige Kunden kriegen jetzt Anrufe.
Man kann sich gar nicht vorstellen, was der ambitionierte Webmaster so alles bastelt. Zum Beispiel “Grütze zippen”: Eine WordPress-Installation, die bei jedem Seitenaufruf ein 250MB-Backup erstellt. Was mit dem neuen Storage-System natürlich in Sekunden erledigt ist. Oder ein “Cache”, der zig-tausend mehrere Byte große Dateien anlegt, die dann zu Hunderten bei jedem Seitenaufruf nachgeladen werden.
Ich will bloss wieder zurück in der Urlaub. Machts gut.

Der sitzt.

sirko — Fri, 11 Jun 2010 12:09:39 +0000

Eben kam eine E-Mail eines “Netzwerkadministrators”. Sinngemäß:

Wir sind eine Spam-Bude, die mehr als 100 Mitarbeiter beschäftigt und monatlich mehr als 110.000.000 Werbe-E-Mails verschickt. Leider werden unsere E-Mails mit folgender Fehlermeldung abgewiesen:
“421 mail2.bytecamp.net Too many concurrent connections from your IP. Please try again later. See http://www.bytecamp.net/de/faq/email/zustellen.html”

Bitte nehmen Sie folgende Server in Ihre Whitelist auf: …

Meine Antwort:

…wir pflegen keine manuellen Whitelists.
Aber wenn einer Ihrer 100 Mitarbeiter technisch versiert ist, brauch er nur die von Ihnen zitierte Fehlermeldung lesen, und schon sind Sie in der Lage, sich selbst zu helfen.

Wie sich eine Insolvenz manchmal ankündigt…

sirko — Tue, 25 May 2010 12:10:54 +0000

Eigentlich sollte Geschäftsführern von Kapitalgesellschaften doch klar sein, dass jeder Insolvenzverwalter nicht nur die Augenbrauen hochziehen wird, wenn vor der drohenden Insolvenz offensichtlich Firmen-Vermögen beseite geschafft wurde. Und das Übertragen des Domain-Portfolios an den Ehegatten des Geschäftsführers ist ein solches – strafbares – Manöver.

IO-Killer

sirko — Tue, 13 Apr 2010 11:30:21 +0000

Wir hatten hier einen Kunden, der es geschafft hat, mit einer zweistelligen Anzahl von Script-Aufrufen am Tag ein echter IO-Killer zu werden.
Wie er das gemacht hat? Mit seiner php_error.log.
Ja, wirklich. In einem seiner Scripte ist ein Loop, die php_error.log wuchs in nur einer Stunde auf 116 MB. Es werden megabytegroße Brocken bei jedem Script-Aufruf via NFS zu den Fileservern übertragen.
Nein das war es noch nicht. Man versuche sich nur einmal vorzustellen, was passiert, wenn der Surfer bei seinem Browser den Reload-Button drückt und die Datei vom anderen Prozess ja noch gelockt ist, weil der megabyteweise Fehlermeldungen schreiben will, bis er durch die Laufzeitbeschränkungen gekillt wird. So etwas kann sich wunderschön hochschaukeln. Hossa!
Wir bauen uns jetzt ein neues Accounting-Tool. Das Accounting von FreeBSD mit sa ist ja ganz nett, aber zum Erkennen von Übeltätern bei kurzen Lastspitzen von IO auf einem Load Balanced Cluster völlig ungeeignet. Was wir brauchen, ist eine Auswertung für frei wählbare Intervalle und verschiedene Kriterien (CPU, Anzahl der Aufrufe, Disk-IO und CPU Storage Integral) auf allen Servern insgesamt und nicht eine Gesamt-Auswertung bis zum letzten Rotation der Accounting-Datenbank auf einzelnen Webservern. Scheint auf den ersten Blick ziemlich einfach umzusetzen zu sein, wir rotieren einfach jede Minute und schreiben die absoluten Accounting-Daten in eine zentrale MySQL-Datenbank. Und die kann man ja dann ganz einfach nach Belieben abfragen, sortieren oder sogar zusammengefasste Verlaufskurven für einzelne Kunden auf dem gesamten Cluster erstellen.

Lampen in Berlin

sirko — Mon, 19 Oct 2009 13:31:03 +0000

In Berlin ist am Brandenburger Tor wohl gerade eine Menge los. In der Nacht zumindest. Auf unseren Servern deswegen auch, täglich eine siebenstellige Anzahl Aufrufe mehr. Auf den Lastkurven sieht man davon gar nichts. Der Cluster rennt.

1,2 GB Gästebuch

sirko — Tue, 15 Sep 2009 13:29:29 +0000

Ein Kunde bekam von uns eine Mail, in der wir seine 1,2 GB große Datenbank bemängeln. Er rief daraufhin heute an. Die Datenbank sei ausschließlich für sein Gästebuch (!) und er will es sich doch ersteinmal komplett durchlesen, bevor er dort Einträge löscht.
In solchen Momenten muß man sich am Support wirklich zusammenreißen, um nicht laut loszuprusten.

Kleine DDOS

sirko — Thu, 08 Jan 2009 14:33:23 +0000

Ein Kunde betreibt ein Postal zu einem CMS. Sein RSS-Feed wird immer populärer, pro Tag hat er einen Zuwachs von 50.000 Aufrufen. Gestern hatte er nun von 0 Uhr bis Mittag über 700.000 Aufrufe von diesem RSS-Feed. Auch wenn wir bei solchen Zugriffszahlen auf dem Web-Cluster bei weitem noch kein Rechenzeitproblem haben, wurde die Sache langsam haarig, weil alle Requests von unterschiedlichen IPs kamen und die Apache-Childs ja mit Keepalive auf eventuelle weitere Anfragen derselben Gegenstelle warten. Es ist einfach dumm, wenn eine Gegenstelle immer nur eine Anfrage macht und dann die Apache-Slots je Request für 15 Sekunden blockiert sind.
Für diese URL haben wir daher Keepalive deaktiviert und den Kunden auch überredet den RSS-Feed statisch vorzuhalten und nur alle 5 Minuten per Cronjob zu generieren.

Was geht nur im Kopf dieses Kunden vor?

sirko — Tue, 01 Apr 2008 11:34:56 +0000

…der sich dachte, ich betreibe auf meinem Shared-Hosting-Account mal einfach einen Adserver für Dritte mit über 4 Mio Aufrufen am Tag? Irgendwie scheint er das Wort Load Balancing mit unbegrenzter Rechenzeit gleichzusetzen (das bestätigt auch wieder mal die “Datenklauseln“).
Shared-Hosting-Angebote sind absolut ungeeignet für Adserver, da aus Sicherheitsgründen PHP als CGI-Variante läuft. Damit müssen mit jedem PHP-Aufruf erst einmal 60MB Speicher alloziiert, der PHP-Prozess gestartet, Libraries nachgeladen werden und vieles mehr. Hochgerechnet laufen gerade zwei wirklich schnelle Multi-Prozessor-Opteron-Server nur für diese Domain.
Wir haben ihm jetzt einen dedizierten Server mit PHP als Apache-Modul nahegelegt. Wenn er nicht einlenkt, werden wir ihm wohl kündigen müssen. Klar können wir sowas ab, aber es rechnet sich nicht. Und ich finde dieses Verhalten auch ziemlich unfair.