Aufgrund eines Totalausfalles der Datenbank musste ich die Artikel nochmal neu einstellen und hab bei diesem Permalink leider nicht aufgepasst, weswegen er jetzt anders heißt.

Hier gehts zum gesuchten Artikel Probleme mit WordPress bei Freenet.de

Es ist verteufelt ruhig geworden, was das Thema Burma angeht. Nach den Solidaritätsaufrufen, die schon ein Jahr zurück liegen, gab es keine Nachrichten mehr zu dem Thema. Wurde das Land vom Erdboden verschluckt? Herrscht da jetzt Friede, Freude, Eierkuchen? Eher nicht.

Nur vereinzelt gibts mal neue Informationen, wie z.B. vor einigen Tagen, dass der burmesische Blogger Nay Myo Kyaw, Alias Nay Phone Latt, mundtot gemacht wurde. Und wen interessiert’s? Niemanden? Warum auch. Das Land ist weit weg, wirtschaftlich uninteressant und politisch unbequem.

Aber es interessiert nur scheinbar niemanden, denn ich für meinen Teil werde mal wieder mein Augenmerk darauf richten, und darüber berichten, was ich da so finde.

Nachdem ich mir das ein Script zum Verwalten den Festplatten-Status (ala APM) erstellt hatte, habe ich noch ein wenig weiter geforscht und herausgefunden, dass das auch einfacher und wesentlich effektiver geht.

Der Kernel hat selbst eine Tabelle in der alle IO-Aktivitäten dokumentiert werden, und zwar unter /proc/diskstats. Dort ist für jedes Laufwerk und auch jede Partition die IO-Statistik seit dem Systemstart hinterlegt mit folgender Bedeutung:

8 0 sda 47434 318408 1891202 356316 3533 7557 89756 101592 0 189596 457880

1. - (mir unbekannt)
2. - (mir unbekannt)
3. disk / partition name
4. reads issued
5. reads merged
6. sectors read
7. milliseconds spent reading
8. writes completed
9. writes merged
10. sectors written
11. milliseconds spent writing
12. I/Os currently in progress
13. milliseconds spent doing I/Os
14. milliseconds spent doing I/Os

Bei Partitionen sind wesentlich weniger Felder hinterlegt, ggf. haben die vorhandenen aber die gleiche Bedeutung. Für mein Script hat das aber keinerlei Bedeutung, da die Partitionen egal sind.

Ich habe das oben genannte Script jetzt so umgebaut, dass es mit dieser Tabelle arbeitet. Das bedeutet, dass das IO-Log-Flag im Kernel, was jede IO-Operation in die syslog schreibt, nicht mehr nötig ist. Wenn das “alte” Script benutzt wurde sollte das Flag mit echo 0 > /proc/sys/vm/block_dump zurück gesetzt werden. Damit wird die Log nicht unnötig aufgeblasen, was bei meiner kleinen 128MB Ramdisk, in der das komplette /var liegt, schon sinnvoller ist.

Die Installation und Verwendung des Scriptes ist immer noch die gleiche, so dass ich den originalen Eintrag nur ein wenig angepasst und mit der neuen Scriptversion versehen habe. Dort ist alles dokumentiert und dort kann das Script auch herunter geladen werden.

Um meinem Mini-Server dazu zu verhelfen, so wenig Strom zu verbrauchen und auch die Festplatten-Lebensdauer so wenig wie möglich zu strapazieren, habe ich eine Möglichkeit gesucht und auch gefunden, wie man die Festplattenzugriffe auf quasi Null reduzieren kann. Folgende Schritte waren hierzu nötig:

1. Die aktuellen Festplattenzugriffe ansehen

Wichtig ist in dem Zusammenhang, das man herausfindet, was denn so alles auf der Festplatte passiert. Das geht, in dem man per echo 1 >/proc/sys/vm/block_dump das Loggen einschaltet und dann per tail -f /var/log/syslog beobachtet, was da so alles passiert. Das sieht dann z.B. so aus

bash(8640): dirtied inode 1134246 (.bash_history) on sda2
pdflush(125): WRITE block 36440088 on sda2

Ist man fertig, sollte man das loggen per echo 0 >/proc/sys/vm/block_dump abschalten, denn wenn viel auf der Platte los ist, kann die Logdatei schnell sehr groß werden.

Bei mir wurde schnell deutlich, dass alle Systemlogger in /var schreiben und Apache und MySQL auch ständig auf /var zugreifen. Die schlimmsten IO-Spamer waren allerdings kjournald und pdflush.

2. System-Zugriffe auf die Festplatte minimieren

Es kamen insgesamt zwei Möglichkeiten in Frage: 1. eine FlashDisk benutzen und 2. eine Ramdisk. Flash hat bei vielen Schreiboperationen ein Problem mit der Lebensdauer, eine RamDisk ist futsch, wenn der Rechner abschmiert.

Ich habe mich für die RamDisk entschieden, da man in definierten Abständen einfach per rsync die Daten auf die Platte schreiben kann. Dafür habe ich dieses “disk2ram” Start-Script erstellt, was das ganze komplett und sauber für mich erledigt. Dieses Script macht folgendes:

Nachtrag: der Teil im Script zum Neustart aller Prozesse enthielt einen Fehler und ist in der aktuellen Version korrigiert

• je eine dynamische Ramdisk für /tmp (128MB) und /var (256MB) erstellen. Diese verbrauchen nur so viel RAM wie Daten enthalten sind und sind von der Maximalgröße eingeschränkt
• je einen logischen Einhängepunkt für /var und /tmp auf der Festplatte erstellen, um später separat darauf zugreifen zu können
• einen Einhängepunkt für die RAM-Laufwerke erstellen
• Den Inhalt von /var und /tmp per rsync in die RamDisk schieben
• /var und /tmp mit den jeweilige RamDisks überlagern
• Alle laufenden Prozesse mit -SIGHUP neu starten

Es ist im übrigen nicht der komplette Inhalt von /var in der Ramdisk enthalten. Wegen der seltenen Benutzung und der Größe sind /var/cache, /var/lib/apt und /var/lib/dpkg nicht in den Ram verschoben und nur in die RamDisk rein gelinkt.

Man kann auf die einzelnen Daten von /var und /tmp auf der Festplatte und den Ramdisks über folgende Einhängpunkte erreichen:

/.disk2ram/tmp.state

/tmp auf der Festplatte

/.disk2ram/tmp.volatile

/tmp auf der Ramdisk

/.disk2ram/var.state

/var auf der Festplatte

/.disk2ram/var.volatile

/var auf der RamDisk

Folgende Befehle beherrscht das Script:

disk2ram start

Lädt wie oben beschrieben, alles in RamDisks und überlagert /var und /tmp

disk2ram sync

Schreibt alle geänderten Daten in den RamDisks auf die Festplatte zurück

disk2ram stop

Syncronisiert alle Daten auf die Festplatte wie bei sync, entfernt die RamDisks und die Überlagerungen von /var und /tmp

Da das ganze sehr Stressfrei ist kann man es einfach in den Systemstart mit aufnehmen, wenn man das Script unter /etc/init.d/disk2ram ablegt und per update-rc.d disk2ram start 36 S . stop 98 0 6 .
registriert. Dann wird es automatisch beim Systemstart geladen und schreibt beim System-Stop alles auf die Patte und wird sauber beendet.

Mit diesem Update-RC wird disk2ram als Systemscript behandelt und direkt nach dem Einbinden aller mounts aus der fstab gestartet. Gestoppt wird es als letztes der normalen Programme. Danach kommen nur noch systeminerne Dienste.

Damit nicht zwischendrin Daten verloren gehen Synchronisiere ich zusätzlich jeweils ein mal alle 24 Stunden per Cron die Daten auf die Festplatte. Dazu einfach die Datei disk2ram unter /etc/cron.d ablegen und mit den Rechten chown root /etc/cron.d/disk2ram und chmod 644 /etc/cron.d/disk2ram versehen.

3. Lesezugriffe abfangen

Jetzt sind noch viele Schreibzugriffe auf die Platte wegen dirtied inodes. Das ist relativ einfach zu bereinigen, da die meisten daher rühren, dass bei einem Lesezugriff auf eine Datei das Datum des letzten Zugriffes vermerkt wird, Und dieses Datum wird auf die Platte geschrieben, auch wenn die Datei eigentlich schon im Cache (nicht Ramdisk!) ist und gar nicht mehr von der Platte gelesen werden musste.

Dazu in der /etc/fstab einfach die Option noatime verwenden werden statt z.B. relatime und dann einfach den Rechner neu starten, damit die Option wirksam wird. Noatime verhindert, dass eben diese Datumsangaben geschrieben werden und verhindert so sehr viel IO-Spam.

Meine fstab sieht z.B. so aus:
/dev/sda1 / ext2 noatime,errors=remount-ro 0 1
/dev/sda2 /filestore ext2 noatime 0 2

Nicht über das ext2 wundern, dazu komme ich jetzt.

4. KJournald zur Ruhe zwingen

Als das alles erledigt war, gab es keine “sinnvollen” Festplattenzugriffe mehr, nur noch die von kjournald und pdflush. Darüber habe ich bisher folgendes herausgefunden:

pdflush ist nicht böse.

Wenn etwas auf die Festplatte geschrieben werden soll, wird das nicht sofort ausgeführt. Dafür gibts unter Linux den Cache, den man mit top auch sehen kann. Alle Daten, die geschrieben werden sollen werden erst mal im Ram zwischengelagert. Ist dann mal Zeit oder eine gewisse Zeit abgelaufen kommt pdflush und schreibt eben diese Daten dann wirklich. Standard sind wohl 30 Sekunden, die maximal vergehen bevor die Daten geschrieben werden. Das beschleunigt die ganzen Festplattenaktivitäten enorm und sollte einfach so bleiben wie es ist.

kjournald ist halb böse

Das ist ein Dienst der das Journal vom Dateisystem ext3 auf dem Laufenden hält. Das Journal erhöht die Datensicherheit bei Plattenproblemen und kann für ein schnelleres Auffinden von Dateien sorgen. Es ist also eigentlich nützlich und unter Linux ist ext3 DER Standard. Aber er schreibt Standardmäßig alle 5 Sekunden irgendwas auf die Festplatte. Was genau das ist, habe ich noch nicht herausgefunden.

Also hieß es, kjournald zur Ruhe zu bringen. Den Intervall zum Schreiben kann man pro Partition als mount-Option “commit=[CENTISECOND]” einstellen. Da ich aber nicht weiß, was es für Probleme bringt, wenn ich den Wert z.B. auf 24 Stunden stelle, habe ich das erst mal gelassen und einen anderen Weg gewählt, nämlich ein “Downgrade” auf ext2.

Der Unterschied von ext3 zu ext2 ist eigentlich NUR das Journal, der Rest ist gleich. Das ist auch der Grund, warum man Problemlos zwischen beiden hin und her wechseln kann. Folgendes muss man dafür machen:

in der Datei /etc/fstab “ext3″ in “ext2″ ändern

In der fstab den Dateisystem-Typ aller Platten, die auf ext2 gewechselt werden sollen, entsprechend anpassen, da sonst beim Neustart nach den Änderungen das System nicht mehr hochfahren will

Das System im “Recovery-Modus” booten

Das ist nötig, da die Festplatte die als / verwendet wird, nur im Read-Only Modus angepasst werden kann oder wenn sie gar nicht eingehangen ist.

“root” im Menü auswählen

…

mount

Nachsehen, welche Festplatte wo eingehangen ist

umount /

Alle Festplatten, die auf ext2 wechseln sollen, aushängen

tune2fs -O ^has_journal /dev/sda1

Die Hat-ein-Journal Markierung von den gewünschten Festplatten entfernen

fsck /dev/sda1

Das Journal entfernen. Das passiert bei einem Check automatisch. Ohne diesen Schritt ändert sich gar nichts

reboot

Das System wieder ganz normal starten

Danach kann man wieder in die IO-Log (siehe oben) sehen und die Stille genießen. Bei mir gibt es nur noch Festplattenaktivitäten, wenn jemand per FTP was hoch lädt oder sich per SSH eingeloggt wird und beim Synchronisations-Cron alle 24 Stunden. Apache, MySQL und das System selber schweigen komplett.

Nächste Schritte

ext3 ist schon sicherer als ext2. Ich werde also noch suchen, was dieser 5-Sekunden-Spam zu bedeuten hat und ob man den bedenkenlos auf 24h stellen kann.

Nachtrag: der journal-spam scheint irgendwo am System zu hängen. Ich habe eine ext3-HD als /home verwendet und die wird nicht zugemüllt. Das wirft nur noch mehr Fragen auf

Außerdem gibt es trotz kompletter inaktivität der Festplatten Probleme mit dem Power-Management, so dass die Platte nach 1 Sekunde direkt wieder ausgeht oder immer an bleibt. Beides ist nicht wirklich wünschenswert.

Nachtrag: Die Probleme mit dem APM sind leider gravierend, so dass ich es komplett abgeschalten habe.

Noch ein Nachtrag: der cron (/etc/init.d/cron) ist beim Booten manchmal vor diesem Script dran. Auch der versteht das HUP-Signal zum Neustart nicht, weswegen ich ihn in das Script per Hand eingefügt habe. Da ist allerdings Vorsicht geboten, denn nicht auf allen Systemen ist der Name gleich. Ggf. muss das Script dann angepasst bzw. ein Link von /etc/init.d/cron auf den richtigen Namen gesetzt werden.

Was auch noch angesprochen wurde ist, dass es Probeme gibt, wenn unterhalb von /var irgendwelche anderen Dinge eingehangen sind. Ein Mountpoint scheint nur auf eine Stelle zu zeigen und nicht mit ihr verbunden zu sein, was ggf verwirrende Resultate haben kann. Im aktuellen Script sind nur die Unterpunkte /var/run und /var/lock beachtet worden, weil nur die auf meines System existieren. Wenn andere Dinge eingehangen sind, muss das Script angepasst werden.

Nachtrag: mit MySQL und apparmor gibt es in dieser Konfiguration scheinbar gravierende Probleme. Eine Lösung habe ich dafür noch nicht.

Nachtrag: Die Ursache für die MySQL-Probleme sind gefunden und gefixt. Allerdings muss in dieses Script noch eine allgemeingültige Neustart-Funktion eingefügt werden. Ansonsten müssten alle auf /var verweisenden Prozesse im Script mit ihrem Init-Script neu gestartet werden.

Mit dem neuen Opera-Mail und der ziemlich guten IMAP Unterstützung bin ich ja sehr zufrieden, nur zwei Sachen machen mich wuschig.

1. Dass die IMAP-Ordner sich so leicht schließen lassen. Ich brauche sie immer offen und meine Struktur ist, von Outlook übernommen, sehr verschachtelt. Schließe ich aus versehen mal INBOX muss ich etliche Unterordner per Hand wieder öffnen. Das sollte man irgendwie unterbinden können, nur weiß ich noch nicht wie.

2. Die immer wieder auftauchenden und komplett Sinnfreien Filter. In der .opera/index.ini steht, nach dem Abrufen der Mails unter anderem folgender Filter:

[Index 44]
Name=E-Mailsnuranmich
Id=200000123
Parent Id=0
Type=2
Keyword=E-Mailsnuranmich
Visible=1
Account Id=0
Model Type=0
Model Age=5
Model Flags=125
Sort Type=0
Sort Ascending=1
Selected Message=0
Hide from other=0
Auto filter=0
Expanded=0
Mark Match As Read=0
Inherit Filter=0
Update Frequency=10800
Last Update Time=0
File=
Search Text=
Search Field=0
Search Current Message=0
Search Start Date=0
Search End Date=0
Search is Regexp=0


Wenn ich den Filter lösche und wieder Mails abrufe, erscheint der Filter wieder. Ich hab auch in der INI mal Visible auf 0 gesetzt. Das wird automatisch auch wieder auf 1 angepasst, sobald ich Mails abrufe. Ebenso erscheinen sie wieder wenn ich die INI per Hand editiere und sie entferne.

Es sind auch immer die gleichen Filter: 1-today, 4-current, today, sales, Forwarded, E-Mailsnuranmich

Ansonsten noch einige, die sich aus ominösen Wörtern in den E-Mails ergeben. Projektnamen z.B. oder aber einfach nur “G”, was aber ein verwendeter, abgekürzter Projektname ist.

Hat jemand eine Idee? Mich nerven die Dinger nämlich.

Nachtrag: Ich habe herausgefunden, dass es wohl die “Tags” aus Zimbra sind. Wenn ich die dort entferne, lassen sich die alle Filter bis auf Forwarded auch löschen. Allerdings habe ich noch nicht herausgefunden, wie man Zimbra das automatische anlegen dieser Tags abgewöhnt. Eine Einstellung dafür ist irgendwie nicht zu finden