Apache2 Speed absolut unzumutbar

[ephigenie]

ok - da ist die Datenbank ja wirklich noch mini.
Da kannst du getrost die key_buffer auf 384 oder kleiner setzen - hauptsache der ist mindestens genausogroß wie die indexe. Wenn du allerdings innodb nutzt - solltest du den key_buffer evt. noch kleiner stellen.

für eine ~50-100Mb Datenbank hast du der Innodb mit 1024Mb mehr als ausreichend Speicher gegeben - aber deine Sync Methode ist zwar recht sicher O_DIRECT aber nicht unbedingt schnell - bzw. es kann sein - dass deine Performance dadurch stark beeinträchtigt ist.

Filesystem sync ist immer eine Gradwanderung zwischen Zuverlässigkeit /bzw. Datenintegrität und Geschwindigkeit. I.d.R. gilt dabei je mehr Geschwindigkeit destoweniger Sicherheit hat man.

Du hast selber in deiner Config z.B. schon SYNC_BINLOG = 0 was bei laufendem Binlog einen deutlichen Performanceschub bringt, aber dafür sorgt, dass wenn dein Server, deine MySQL abschmiert u.U. die Master-binlogs im Eimer sind. d.h. du musst dann deine Replikation neu aufsetzen usw...

Innodb an sich ist eine recht robuste Datenbank - die auch einen Absturz i.d.R. durch ihre "Selbstheilungskräfte" ganz gut übersteht - Innodb ist zudem in der Lage Transaktionen zu garantieren, sprich die Daten sind sicher auf die Festplatte geschrieben. Wenn man nun versucht in Richtung Performance zu optimieren, muss man sich u.U. darauf einlassen das evt. mal nach einem Abstand eben die letzten Datensätze es nicht garantiert auf die Festplatte schaffen können.

Folgende Option bestimmt wie auf die Festplatte geschrieben wird :
innodb_flush_method

Zur Auswahl stehen unter Unix für innodb verschiedene Syncmethoden:
littlesync
O_DIRECT
fdatasync
O_DSYNC
nosync

O_DIRECT ist schon recht ok - in meisten Fällen - aber es kann unter Umständen schneller (aber auch ein wenig unsicherer mit littlesync/nosync ) gehen.

Zudem auch noch das von mir angesprochene
innodb_flush_log_at_trx_commit

Hierbei gehts nicht um die Art des Syncs sondern um den Zeitpunkt.
1 ist hier der Standard und benötigt um ACID kompatibel zu sein.
Wenn du auf die Daten der letzten Sekunde vor dem Crash verzichten kannst - dann eben 0

Sollte deine Anwendung keinen Two-Phase-Commit mit XA-Transaktionen benutzen, kannst du dieses Feature abstellen (ich geh bei vbulletin davon aus, dass es nicht genutzt wird) und
innodb_support_xa = 0

damit ausstellen, was hilft disk I/O zu reduzieren weil ein zusätzlicher disk-flush bei der Transaktions - Vorbereitung damit wegfällt.