Mailinglisten-Archive |
Das Problem ist ziemlich einfach. Du musst die Zahl der maximal offenen File-Deskriptoren von 255 auf 65.000 oder höher setzen. Die Begrenzung befindet sich im Kernel in den Header-Dateien und sind kommentiert.... (Siehe nach SOMAXCONN). In neueren Kerneln (> 2.0.35 kannst Du das auch mit echo "65000" > /proc/kernel/....file-max oder so verändern.... Danach mußt Du MYSQL davon bescheid geben: Die Header Dateien müssen dafür unbedingt auf die neuen Werte gesetzt werden, damit das MYSQL Binary damit kompiliert wird. Danach kannst du bis zu 65000 Verbindungen simultan öffnen. Dasselbe gilt auch für den APACHE, der bei ca. 120 Virtuellen WWW-Servern dicht macht. Inzwischen haben wir bis 300 WWW-Server auf einer P166 Maschine - und alle haben ihre eigenen Log- und Errorfiles..... Für Squid gilt dasselbe - der meldet schon bei ./configure, daß zuwenig FD bereit stehen (damit kann man testen, ob die Kernelpatches auch wirksam waren.....) Alternativ beherrscht SQUID einen POLLING Modus, der die FD nich so strapaziert. Ich habe es damit geschafft, bis zu 100 Surfer über eine ISDN Leitung zu schicken....Squid wird dann wirklich rasendschnell... Wer sich z.B. Adabas -D oder Oracle für Linux gekauft hat, der ist gearscht: Die haben ihre Versionen statisch kompiliert - Die SQL Datenbanken sind somit im Profibetrieb wertlos. Ich habe das mit der PROMO Version von ADABAS - D erlebt - die ist inzwischen gnadenlos durch MYSQL ersetzt worden. Ich sehe nur eines, wenn MYSQL noch LOCKING Modi beherrscht und Stored Procedures einführt , dann werden ich auch Datenbanken bei Kunden (für ACCESS) auf MYSQL umstellen. Bezüglich MYSQL nochmal - Ich habe testweise einmal 500 simultane MYSQL Datenbanken auf Linux installiert - im User-Modus auf eigenen Ports - ohne Probleme (zumindest mit genug RAM....) die gehen in Kürze ans Internet.... Gru/3, Guido Stepken Tip noch: SUSE 6.0 hat einen Profi-Kernel mit dabei, der auf 1024 max. Filedeskriptoren gepatcht ist, für mich reicht das aber auch nicht aus..... -----Ursprüngliche Nachricht----- Von: Bodo Hoffmann <mysql_(at)_takeon.com> An: mysql-de_(at)_lists.4t2.com <mysql-de_(at)_lists.4t2.com> Datum: Donnerstag, 4. März 1999 22:42 Betreff: Re: Performance von MySQL ausreichend? >Das ist meine Premiere.. deshalb ersteinmal ein "Hallo" in die Runde. > > Ich bin froh, daß genau unser Thema hier angerissen wird. Wir haben ein > Problem bei den 91 gleichzeitigen Connections (bzw. bei uns steigt > der Server bei 120 aus..) > > Gibt es irgendeine Lösung, dieses signifikant aufzubohren? > > Nach http://www.mysql.com/crash-me-choose.htmy kommt für uns nähmlich > nur eine Informix-Lösung zur Auswahl .. aber ich würde mich ungern > von mySQL trennen .... > > Irgendeine Idee, was man machen kann, um mehr als 91/120 gleichzeitige > Connections hinzubekommen??? Wo muss ich dran drehen, um die "Standard" > Einstellung zu tunen ;-) > > Wir sind für jede Info dankbar ..... denn wir verzweifeln hier > gerade... > > Danke! > > Ciao bodo_.............. > > >Christian Mack wrote: >> >> Christoph Kiehl wrote: >> > >> > Hi, >> > >> > >>Gibt es vielleicht eine >> > >>Website wo verschieden Datenbanken verglichen werden? >> > > >> > >http://www.mysql.com/crash-me-choose.htmy >> > Die habe ich gestern auch noch gefunden. Wenn man dem glauben soll ist MySQL ja >> > unschlagbar ;). Ist dem wirklich so? Ich meine irgendwelche Nachteile muß MySQL >> > doch auch habe oder?? ;)) >> > >> > Christoph >> >> Hi Christoph >> >> Klar: >> MySQL hat keine Subselects, keine Transaktionverwaltung, keine Stored Procedures, kein Row-Level-Locking. >> Allerdings sind Subselects fuer 3.23.xx versprochen, und Stored Procedures ziemlich hoch in der TODO Liste. >> >> Aber die Performance ist wirklich die beste die ich bisher gefunden habe. >> Der obige Test geht uebrigens von den Standard-Einstellungen aus. D.h. man kann mehr herausholen. >> >> Auch der Support ist Spitze. >> >> Tschau >> Christian
php::bar PHP Wiki - Listenarchive