Mailinglisten-Archive |
Hallo Herr Dr, hallo Liste, Werner Stuerenburg schrieb: > When watching top, things go nicely for a while. If there is high > load, it is significant that mostly httpd processes are shown, > very seldom a mysql process. > > All of a sudden, the picture changes. Some mysql processes show > up with status column showing D instead of R, meaning > "uninterruptible sleep" versus "running". Da warten die mysqlds imho auf IO, dh. auf die Festplatte. Was sagt der CPU-State system im top ? (Siehe auch http://lists.debian.org/debian-devel-0106/msg01071.html ) > I thought about bad queries or faulty code, but the data below > does not back this idea. Hmm, ich habe trotzdem das Gefühl, dass hier MySQL den Fuss auf der Bremse hat. Ich habe ein ähnliches Problem auf bauernhofurlaub.com gehabt, wenn dort Crawler kamen. Während die Abfragen generell sehr schnell ablaufen, verlangsamen sie sich deutlich, wenn sie mit anderen Abfragen konkurrieren müssen. Kommen dazu noch Dinge wie ein file_sort oder temporary tables im Mysql, möglichst noch nur 128 MB speicher und ein klein eingesteller Buffer, vielleicht noch ein Softraid dazu - dann bremsen sich die ganzen IO-Abfragen gegenseitig aus, während der Crawler weiterhin fröhlich neue Anfragen abfeuert. Aktiviere mal das Loggen von Slow_queries im Mysql, der Default-Wert von IIRC 10 Sekunden ist ein guter Wert. Wenn bei den hohen Loads dort viele Queries zu finden sein sollten, dann ist Mysql-Tuning mit Buffergrössen, HEAP-Tables und neues setzen von indizes angesagt. (Bei mir hat das gezielte Setzen von Indizes und die Betrachtung ihres Effektes mit Explain sehr viel gebracht, weil ich dort gelernt habe, dass Mysql laengst nicht immer von sich aus die besten Indizes nutzt, sondern manchmal wirklich mit der Nase drauf gestossen werden muss, welcher Index für genau diese Query denn am besten funktioniert. ) Vielleicht hilft ja meine Herumraterei, wenn nicht: welcher Kernel ist das ? Viele Grüße - johann
php::bar PHP Wiki - Listenarchive