Mailinglisten-Archive |
On Sun, 3 Dec 2000 15:32:28 +0100, Guido Haeger wrote: >> man sich doch darauf einigen kann, mal die CPU-Auslastung pro >> User zu begrenzen .... >Also ganz blöd sind die Leute bei Strato oder Puretec ja auch nicht. Hab ich auch nicht behaupten wollen, will ja keinen persönlich anharnen. >Genau das (Limits pro User) ist bei MySQL eben nicht möglich, weshalb >die Provider darauf achten müssen, daß nicht einzelne User den >MySQL-Server in die Knie zwingen, wodurch alle anderen User des Hmm, nun gibs aber doch das schöne nice, und der Server läuft doch sicher als eigener User. MySQL ist weiterhin multithreaded, was bedeutet, daß jeder Zugriff einen eigenen Thread aufmacht. Wenn man nun insgesamt die Threadpriorität soweit gegen 20 laufen läßt, daß da nicht mehr viel Platz bleibt, dann sollte es eigentlich nicht passieren, daß ein Server in die Knie geht. Die bösen (weil lastigen) Threads würden sich somit ganz wunderbar in den Strom der vorhandenen einordnen und mit sofortiger Wirkung Platz machen, wenn da jemand was anderes will. >gleichen MySQL-Servers mitleiden. Einige deutsche Provider haben >wegen entsprechenden Features bei den MySQL-Entwicklern nachgefragt >und waren auch bereit dafür zu zahlen. Gab offensichtlich keine >Resonanz... Schade ... wie sieht das dahingehend eigentlich bei PostgreSQL aus? Bin zwar grad am Buchlesen, aber man kann ja mal vornewegfragen. Ach apropos, um mal ins Toppic zurückzukommen: Da MySQL ja keine "Fremdschlüssel" unterstützt, muß sich doch der Programmierer selbst um die Konsisitenz seiner Datenbank kümmern. Gibt es da eine fertige Lösung, die aufpaßt, daß keine Daten in Felder eingegeben werde, die in der eigentlichen Datentabelle nicht vorhanden sind? Bei Postgres weis ich, daß das DBMS das tut, weils ja foreign Keys unterstützt, doch bei MySQL? In dem Zusammenhang hab ich irgendwie auch das Gefühl, daß MySQL eigentlich nix weiter macht, als unzusammenhängende Tabellen zu verwalten, kann aber auch ein Trugschluß sein. >Eine "Lösung" wäre aktuell eventuell ein MySQL-Dämon pro User, was aber >wohl auch nicht gerade trivial ist... ... speziell wenn man sich des Speicherhungers mal bewußt wird, wenn es sich um einige tausend Anfragen pro Stunde oder Minute handelt. >Ursache für die Probleme mit den MySQL-Servern bei diversen >Massenhostern ist in der Regel mangelndes Wissen seitens der User. Das Hmm, nunja, eigentlich sollten solche Systeme genau dagegen abgesichert sein, denn ein Hoster mit mehreren tausend Usern kann nicht erwarten, daß alle unfehlbar sind. >fängt mit schlechtem DatenbankDesign (z.B. fehlende Indexe) an, gute Datenbankdesign soll aber auch gelernt sein, und um mal schnell ne Seite zusammenzuhacken will nicht jeder kleine Webneuling gleich in die Sphären des Datenbankdesigns einsteigen. >erstreckt sich über grausamste Programme (in Schleifen werden die >DB-Server mit Anfragen bombadiert, die man mit einem sinnvollen >SQL-Statement erschlagen könnte) und endet bei vollkommen siehe oben, das soll zwar keine Rechtfertigung für die User sein, doch sowas passiert nunmal in großen Mengen, da sollte man sich drauf einstellen als Hoster, der sein Brot damit verdient. >unverhältnismäßigen Vorstellungen. Wenn ich einen 30Mark-Puretec-Tarif >habe, dann kann ich einfach nicht erwarten, das dort extrem >lastintensive Anwendungen mit mysql-basierenden High-Traffic-Chat oder >20 DB-Anfragen pro Seite vernünftig laufen. *Das* ist ein Argument, doch die Gier der Leute ist eben nicht zu bremsen :-) >Guido Haeger CU/2 sagt Hartwin -- _______________________________________________________________ | mailto:hartwin.rohde_(at)_gmx.net (Hartwin Rohde) | | klickto:http://www.in-berlin.de/User/harko/ | | foneto:030 - 44 34 11 55 | |--------------------------o funkto:0177 - 24 06 413 | | 2048 Bit / ID: 307CFA39 \___________________________________| | Fingerprint: B5 A1 F1 28 A4 D3 C2 B9 60 5A 8F 04 C8 9E AB 96 | \_______________________________________________________________/
php::bar PHP Wiki - Listenarchive