Mailinglisten-Archive |
Hallo, >>> man sich doch darauf einigen kann, mal die CPU-Auslastung pro >>> User zu begrenzen .... >>Also ganz bloed sind die Leute bei Strato oder Puretec ja auch nicht. > Hab ich auch nicht behaupten wollen, will ja keinen persoenlich anharnen. >>Genau das (Limits pro User) ist bei MySQL eben nicht moeglich, weshalb >>die Provider darauf achten muessen, dass nicht einzelne User den >>MySQL-Server in die Knie zwingen, wodurch alle anderen User des > Hmm, nun gibs aber doch das schoene nice, und der Server laeuft doch sicher > als eigener User. MySQL ist weiterhin multithreaded, was bedeutet, dass > jeder Zugriff einen eigenen Thread aufmacht. Wenn man nun insgesamt die > Threadprioritaet soweit gegen 20 laufen laesst, dass da nicht mehr viel Platz > bleibt, dann sollte es eigentlich nicht passieren, dass ein Server in die > Knie geht. Die boesen (weil lastigen) Threads wuerden sich somit ganz > wunderbar in den Strom der vorhandenen einordnen und mit sofortiger > Wirkung Platz machen, wenn da jemand was anderes will. Ich kann mal meine Erfahrung hier kundgeben : Ich bin Admin einer grossen Spiele-Community mit jeder Menge Hosted-Sites. Wir haben einen eigenen Datenbankserver, Pentium-III-700, 512 MB RAM, verbunden mit dem Webserver per Crosslink (pervers, aber geil ;) ). Pro Stunden fliessen ca. 2 GB von der Datenbank an den Webserver. So gut wie alle Hosted-Sites (ca. 300) haben eine Datenbank, Gesamttraffic belaeuft sich auf mehere GB am Tag vom Webserver. Unser Datenbank-Server langweilt sich die meiste Zeit ziemlich, ab und zu kommt mal eine groessere Welle von Prozessen, aber das legt sich nach kurzer Zeit wieder. Als noch die pconnects() erlaubt waren, waren schnell 400 MySQL-Prozesse am laufen, durch das Sperren dieser Function allerdings hat sich das alles komplett gelegt, und der Server ist auch bei groesseren Lasten voll funktionsfaehig. Thomas
php::bar PHP Wiki - Listenarchive