Seite 1 von 2
Nach Umzug des Boards: Absenden von Postings sehr langsam
Verfasst: 28.01.2008 15:16
von ThE_CaPtAiN
Hallo!
Ich bin neu hier und hoffe mir kann jemand bei meinem Problemchen helfen.
Ich bin mit meinem Forum (
http://www.nintendofans.de/forum) auf einen neuen Server umgezogen. Das Forum selbst ist super-schnell, aber seit dem Umzug ist das "Posten" sehr langsam.
Konkret: Wenn man eine Antwort oder ein neues Topic verfasst hat und auf "Absenden" klickt, dauert es elendslange, bis etwas passiert. Teilweise ist das Posting relativ schnell im Topic sichtbar. Für den Poster dauert es jedoch sehr lange, bis er zurückgeleitet wird.
Details zum Forum:
- Das Forum ist in Maßen gemoddet. Zur Fehlerbeseitigung habe ich aber die posting.php und die common.php durch Ihre Originale ausgetauscht, was nicht geholfen hat.
- Server Alt war PHP 4 und MySQL 4.1.22
- Server Neu hat PHP 5 und MySQL 5.0.32
Weiß jemand, woran der "Lag" liegen könnte? Sonstige "INSERTS" in die Datenbank in anderen Skripten gehen rucki-zucki.
Verfasst: 07.02.2008 23:24
von ThE_CaPtAiN
Ich bin inzwischen so verzweifelt, dass ich netten Menschen, die mir (unter Zurverfügungstellung der Zugangsdaten zu meinem Server) helfen können, auch eine kleine finanzielle Zuwendung, soweit sie mein studentisches Budget erlaubt, anbiete.
Ich brauche wirklich dringend Hilfe zur Lösung des Problems.
Verfasst: 07.02.2008 23:38
von d23
Ist es dein eigener Server ? Oder nur Webspace ?
Eine nicht passende MySQL Konfiguration kann solche Probleme verursachen - vor allem da das Forum ja nicht klein ist. Hast du mal eine Datenbankreparatur/optimierung via phpmyadmin versucht ?
Verfasst: 08.02.2008 09:14
von ThE_CaPtAiN
Es ist nur Webspace, der Server wird mit 7 Leuten geshared. Ich habe allerdings bestimmte Zusicherungen bzgl. mir zugeteilter Prozessorlaufzeit und Arbeitsspeicher.
Einen OPTIMZE auf alle Tables hatte ich bereits versucht. Danach schien mir das Posten etwas schneller. Ich habe es nun nochmal gemacht und mir scheint es wieder etwas schneller. Optimal ist es aber immer noch nicht, zumal alle anderen INSERTs in anderen Skripten wirklich sehr schnell laufen.
Die MySQL Installation sieht so aus:
auto increment increment 1
auto increment offset 1
automatic sp privileges ON
back log 50
basedir /usr/
binlog cache size 32.768
bulk insert buffer size 8.388.608
character set client utf8
(Globaler Wert) latin1
character set connection utf8
(Globaler Wert) latin1
character set database latin1
character set filesystem binary
character set results utf8
(Globaler Wert) latin1
character set server latin1
character set system utf8
character sets dir /usr/share/mysql/charsets/
collation connection utf8_unicode_ci
(Globaler Wert) latin1_swedish_ci
collation database latin1_swedish_ci
collation server latin1_swedish_ci
completion type 0
concurrent insert 1
connect timeout 5
datadir /var/lib/mysql/
date format %Y-%m-%d
datetime format %Y-%m-%d %H:%i:%s
default week format 0
delay key write ON
delayed insert limit 100
delayed insert timeout 300
delayed queue size 1.000
div precision increment 4
engine condition pushdown OFF
expire logs days 10
flush OFF
flush time 0
ft boolean syntax + -><()~*:""&|
ft max word len 84
ft min word len 4
ft query expansion limit 20
ft stopword file (built-in)
group concat max len 1.024
have archive YES
have bdb NO
have blackhole engine NO
have compress YES
have crypt YES
have csv YES
have dynamic loading YES
have example engine NO
have federated engine YES
have geometry YES
have innodb YES
have isam NO
have merge engine YES
have ndbcluster DISABLED
have openssl DISABLED
have query cache YES
have raid NO
have rtree keys YES
have symlink YES
init connect
init file
init slave
innodb additional mem pool size 1.048.576
innodb autoextend increment 8
innodb buffer pool awe mem mb 0
innodb buffer pool size 8.388.608
innodb checksums ON
innodb commit concurrency 0
innodb concurrency tickets 500
innodb data file path ibdata1:10M:autoextend
innodb data home dir
innodb doublewrite ON
innodb fast shutdown 1
innodb file io threads 4
innodb file per table OFF
innodb flush log at trx commit 1
innodb flush method
innodb force recovery 0
innodb lock wait timeout 50
innodb locks unsafe for binlog OFF
innodb log arch dir
innodb log archive OFF
innodb log buffer size 1.048.576
innodb log file size 5.242.880
innodb log files in group 2
innodb log group home dir ./
innodb max dirty pages pct 90
innodb max purge lag 0
innodb mirrored log groups 1
innodb open files 300
innodb rollback on timeout OFF
innodb support xa ON
innodb sync spin loops 20
innodb table locks ON
innodb thread concurrency 8
innodb thread sleep delay 10.000
interactive timeout 28.800
join buffer size 131.072
key buffer size 16.777.216
key cache age threshold 300
key cache block size 1.024
key cache division limit 100
language /usr/share/mysql/english/
large files support ON
large page size 0
large pages OFF
lc time names en_US
license GPL
local infile ON
locked in memory OFF
log OFF
log bin ON
log bin trust function creators OFF
log error
log queries not using indexes OFF
log slave updates OFF
log slow queries OFF
log warnings 1
long query time 10
low priority updates OFF
lower case file system OFF
lower case table names 0
max allowed packet 16.776.192
max binlog cache size 4.294.967.295
max binlog size 104.857.600
max connect errors 10
max connections 100
max delayed threads 20
max error count 64
max heap table size 16.777.216
max insert delayed threads 20
max join size 18446744073709551615
max length for sort data 1.024
max prepared stmt count 16.382
max relay log size 0
max seeks for key 4.294.967.295
max sort length 1.024
max sp recursion depth 0
max tmp tables 32
max user connections 0
max write lock count 4.294.967.295
multi range count 256
myisam data pointer size 6
myisam max sort file size 2.147.483.647
myisam recover options OFF
myisam repair threads 1
myisam sort buffer size 8.388.608
myisam stats method nulls_unequal
ndb autoincrement prefetch sz 32
ndb force send ON
ndb use exact count ON
ndb use transactions ON
(Globaler Wert) OFF
ndb cache check time 0
net buffer length 16.384
net read timeout 30
net retry count 10
net write timeout 60
new OFF
old passwords OFF
open files limit 1.024
optimizer prune level 1
optimizer search depth 62
pid file /var/run/mysqld/mysqld.pid
port 3.306
preload buffer size 32.768
protocol version 10
query alloc block size 8.192
query cache limit 1.048.576
query cache min res unit 4.096
query cache size 16.777.216
query cache type ON
query cache wlock invalidate OFF
query prealloc size 8.192
range alloc block size 2.048
read buffer size 131.072
read only OFF
read rnd buffer size 262.144
relay log purge ON
relay log space limit 0
rpl recovery rank 0
secure auth OFF
server id 1
skip external locking ON
skip networking OFF
skip show database OFF
slave compressed protocol OFF
slave load tmpdir /tmp/
slave net timeout 3.600
slave skip errors OFF
slave transaction retries 10
slow launch time 2
socket /var/run/mysqld/mysqld.sock
sort buffer size 2.097.144
sql big selects ON
sql mode
sql notes ON
sql warnings OFF
ssl ca
ssl capath
ssl cert
ssl cipher
ssl key
storage engine MyISAM
sync binlog 0
sync frm ON
system time zone CET
table cache 64
table lock wait timeout 50
table type MyISAM
thread cache size 8
thread stack 131.072
time format %H:%i:%s
time zone SYSTEM
timed mutexes OFF
tmp table size 33.554.432
tmpdir /tmp
transaction alloc block size 8.192
transaction prealloc size 4.096
tx isolation REPEATABLE-READ
updatable views with limit YES
wait timeout 28.800
Verfasst: 08.02.2008 09:48
von d23
Gibt es einen SSH-Zugang ? Ein Überblick über die Prozesse wäre nicht schlecht, um zu sehen, wo der Flaschenhals liegt
Verfasst: 08.02.2008 09:55
von ThE_CaPtAiN
Nein, leider nicht. Aber bei den MySQL-Prozessen sieht es jedenfalls nicht gerade nach Überlastung aus.
Ich kann meinen Host aber vielleicht bitten mal ein paar "Snapshots" zu machen.
Verfasst: 08.02.2008 10:00
von d23
Das Problem ist ziemlich sicher Richtung Datenbank zu finden - der Server reagiert an sich recht flott, was Ärger mit Apache+PHP nahezu ausschließt...
Hast du den
Page Generation Time MOD verbaut - der würde Aufschluß geben, was am meisten Zeit braucht.
Verfasst: 08.02.2008 10:21
von ThE_CaPtAiN
Ich habe das MOD mal eingebaut und ein längeres Posting verfasst, das wieder einige Zeit gebraucht hat...
Page generation time: 24.5909s (PHP: 0% - SQL: 100%) - SQL queries: 24 - GZIP enabled - Debug on
Ok~ay. Das ist in der Tat ein interessantes Ergebnis.
Verfasst: 08.02.2008 10:27
von ThE_CaPtAiN
Ich habe mir mal die MySQL Queries während eines Postings angeschaut:
Query time 144 Copying to tmp table SELECT m.word_id\n FROM phpbb_search_wordmatch m...
Query time 16 Locked DELETE FROM phpbb_search_wordlist\n WHERE wor...
Verfasst: 08.02.2008 10:32
von d23
Hab grad selber:
Page generation time: 154.5174s (PHP: 0% - SQL: 100%) - SQL queries: 24 - GZIP enabled - Debug on
Definitiv der MySQL Server - das ist der Insert in die "posts_text"-Tabelle, welcher hängt oder das Aktualisieren der Wordmatches für die Suche.
Einzeiler lässt er recht schnell durch.
In Anbetracht der obigen Konfiguration des MySQL Servers denke ich, dass die die Größe der Puffer zu klein gewählt ist. Ob dein Hoster diese ändern wird, ist so eine Sache, da das den Arbeitsspeicher-Verbrauch drastisch erhöhen würde.
Code: Alles auswählen
key buffer size 16.777.216 - hier würde ich statt 16M 64M vorschlagen (128M wäre noch besser)
sort buffer size 2.097.144 - hier würde ich 8M bzw. 16M vorschlagen
table cache 64 - hier würde ich 128 bzw. 256 vorschlagen
Vorerst, gibt es denn einen phpmyadmin ? Ich würde mir gerne die Datenbank einmal anschauen