Apache2 Speed absolut unzumutbar

[ephigenie]

du bist ein Spassvogel - installier doch bitte erstmal bc ansonsten hast du doch nix sinnvolles an output im tuning-primer...

ansonsten benutzt du innodb fürs Forum ?
Wenn ja solltest du mal :
innodb_flush_log_at_trx_commit = 0 setzen.

das Flusht dann ungefähr im sekundentakt anstatt atomar.
Das hilft i.d.R.
aber nat. nur bei innodb.
Der Rest der my.cnf sieht ganz ok aus.

Ansonsten kann ichs nur nochmal wiederholen ... schau dir mal eaccelerator an. deinen php-opcode optimizer kenn ich nicht - und der wird im output von php5-cgi -m auch nicht erwähnt ...

[IncheZ]

http://ubuntuusers.de/paste/17318/ sorry, bin etwas verplabnt momentan -_-

also, da der output, werd mir eaccelerator anschauen.

frage: wie bekomm ich raus ob innodb drauf ist, hab am sql server nichts verändert.

sorry für mein unwissen...

zu eccelerator:

hab nach der anleitung auf eaccelerator.de versucht, allerdings bekomm ich folgenden fehler:

Code:

b0x:~/eaccelerator-0.9.5.2# $PHP_PREFIX/bin/phpize  
-bash: /usr/bin/phpize: No such file or directory

kannste mir sagenw as ich falsch mache.

(is ein etch server)

mfg

[joximu]

http://www.howtoforge.net/eaccelerator_php5_debian_etch

[IncheZ]

danke, so, eAccelerator läuft anscheind:

Code:

[PHP Modules]
bcmath
bz2
calendar
ctype
date
dba
dom
eAccelerator
exif
filter
ftp
gd
gettext
hash
iconv
imap
json
libxml
mbstring
mcrypt
mhash
mime_magic
mysql
mysqli
openssl
pcre
PDO
pdo_mysql
posix
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
zip
zlib

[Zend Modules]
eAccelerator

jetzt bräucht ich nur paar tipps für die DB zu beschleunigen.

[joximu]

ich wüde mal im pma die Laufzeitinformationen ansehen - da gibt's manchmal tipps, wenn bestimmte Werte nicht so gut sind...

[ephigenie]

das macht tuning-primer.sh ganz nett

apropos : ist deine Seite jetzt wieder in Betrieb oder nicht ?
Ich wunder mich nur - weil ~2000 queries in 2,5 h ist nicht grad viel - das rauscht bei mir in 5-10s durch...

Also setz deine Seite mal wieder richtig unter Last und dann lass den tuning-primer.sh nach > 48h Laufzeit der MySQL nochmal laufen.


Btw. schau bitte im phpmyadmin welchen Typ deine Tabellen haben (myisam/innodb) wie groß die Indexe (zusammen) sind - und wie groß die Datenbank insgesamt.

(natürliche alle Angaben nur zu der DB die du auch entsprechend heavy nutzt).

[IncheZ]

Also is innodb.

Die DB Größe der beiden HauptDB`s:
33,5 MB Indexe: 93,989
5MB Indexe: 7,9844

mfg Inchez

P.S: ne, lief gestern nochne tunter volllast

[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.