Tja, es gibt so Tage im Leben eines Admins die tun weh, aber sind nötig: ich spiele im Moment mit einem Spam-Filter (DSPAM) herum, der seinen Statistikdaten in einer SQL-Datenbank speichert. Der Spamfilter unterstützt eine ganze Reihe von Datenbanktreibern, unter anderm PostgreSQL und MySQL und ein paar andere non-client-server Datenbanken (SQLite etc.). Ich hab also gewohnheitsgemäß zuallererst zu PostgreSQL gegriffen - lief auf der Kiste ja eh schon.
Nunja, am Anfang etwas zäh und die Kiste wurde etwas unter Damp gesetzt, aber ich habe ein paar Tipps im Netz gefunden mit denen man PostgreSQL für DSPAM Beine machen konnte. Danach lieft der Rechner zwar nicht begeisternd schnell, aber deutlich fixer als vorher. Also mal ne Nacht durchlaufen lassen.
Nunja, am nächsten Tag das böse Erwachen: tonnen von blockierten Prozessen, schweinelangsame Updates gegen die Datenbank, tödliche Performance beim Umlernen einer Mail: 12 Minuten Laufzeit keine Besonderheit. Autsch. Der Dump der Datenbank ist zu dem Zeitpunkt schon 100 MB gross. Das ganze ist irgendwie nicht so begeisternd, wenn die Systemlast so immer zwischen 3 und 6 pendelt ...
Ok, also in den sauren Apfel beissen und den KarteikastenMySQL installiert und konfiguriert. Danach dann den Exim wieder hochgefahren und die wartenden Mail einsortiert. Effekt: totale Load-Explosion. Loads oberhalb von 30 und dann irgendwann schlug der Watchdog zu und bootet. Oh shit.
Alles klar, mal nachgeguckt was eigentlich in der Kiste steckt: jau, nur 256 MB Speicher und der MySQL-Server geriet massiv ins Pagen. Da kann er nu ja nix für, wenn ich einfach zu wenig Speicher habe. PostgreSQL hatte damit weniger Probleme, weil das Speichermanagement von PostgreSQL wesentlich statischer ist und der Server nicht so viel Speicher in der Grundkonfiguration an sich reisst.
Ok, Jutta hat mit ihrem Linux-Kasten den Speicher getauscht und jetzt hat der Server 512 MB Speicher, das reicht ihm für den Zweck. Und die Systemlast mit MySQL drauf ist deutlich besser als alles vorher. Ok, ich könnte sicherlich auch PostgreSQL mit grösserer Konfiguration zu besserer Performance bringen, aber das Problem war den Symptomen nach bei PostgreSQL die massive Anzahl paralleler Updates und die Multiversion-Transaktions-Technik des Servers - die war in diesem konkreten Fall definitiv im Weg.
Merke: MySQL ist zwar weiterhin nur ein glorifizierter Karteikasten und MyISAM definitiv das eigentlich dümmste Tabellenformat das man wählen kann, aber keine Technik ist so blöd das man sie nicht doch ab und an brauchen könnte. Wenn die Daten nämlich völlig transaktions-fremd sind - weil der SQL-Server eben einfach nur als Datenablage missbraucht wird, ohne das es ein echtes fachliches Datenmodell mit grosser referentieller Integrität vorliegt - sollte man eben einfach keine Datenbank benutzen deren Schwerpunkt dem genau entgegensteht. Da ist MySQL und MyISAM schlicht und einfach die bessere Wahl.
Besser als Berkley-DB oder andere In-Process-Datenbanken ist es allemal, denn die können nur über File-Locking verlässlich arbeiten und bei den massiven parallelen Updates die DSPAM nunmal macht (er lernt - je nach Einstellung - bei jeder Mail und aktualisiert so seine statistische Basis) ist eine Datenbank auf Filesystembasis denkbar ungünstig.
Jetzt werde ich mal die nächste Nacht abwarten und schauen wie sich DSPAM mit dem nächtlichen Mailberg abmüht und wie das System morgen aussieht, wenn mehrere tausend Mails durchgerauscht sind (ja, wir verbraten mit nur zwei Usern gigantische Mengen an Mailtraffic - liegt primär an Bergen von Spam, Bergen von administrativen Mails diverser Systeme und Bergen von Mailinglisten). Mal schauen ob das System morgen noch genauso fix ist wie heute. Ich fürchte ja das ich bei den Mengen an Mail auch die MySQL-Basis für DSPAM an den Rand des Möglichen treiben werde ...
Update: also bis jetzt siehts sehr gut mit der Load aus, der Karteikasten hat also tatsächlich mal die Nase vorne 
