Welp, so far the last few days of cvs cuts have proven rock solid against the mass dirty client drop bug. Using a 386dx-40 and today's pull from cvs, we were able to get 400 clients on the server in one channel, and kill them all at once without so much as a hiccup from the ircd.
Welp, bis jetzt die letzten Tage der cvs Schnitte haben Felsenkörper gegen die schmutzige Klient Tropfenmassenwanze geprüft. Mit einem 386dx-40 und einem heutigen Zug von den cvs,WAREN wir in der Lage, 400 Klienten auf dem Bediener in einer Führung zu erhalten und töten sie in einem Zug außen soviel als hiccup vom ircd.
Joshua Coombs x386.net
Am Mittwoch, 30.10.02 um 22:06 Uhr schrieb Joshua Coombs:
Welp, so far the last few days of cvs cuts have proven rock solid against the mass dirty client drop bug. Using a 386dx-40 and today's pull from cvs, we were able to get 400 clients on the server in one channel, and kill them all at once without so much as a hiccup from the ircd.
Sehr gut!
Hast du ein Test-Programm geschrieben oder wie erzeugst du die 400 Clients?
Grüße Alex
On Thursday, October 31, 2002, at 10:31 AM, Alexander Barton wrote:
Sehr gut!
Hast du ein Test-Programm geschrieben oder wie erzeugst du die 400 Clients?
I've been using a one line script to start a bunch of epic clients in bot mode. I have a few friends helping with this, each machine generally can host about 100 to 150 clients. We then killall -9 the clients at the same time to simulate the mass drop. We're now trying to figure out the optimal amount of clients to expect a 386 to handle and how to tweak freebsd for it.
Ich habe einen eine Linie Index benutzt, um ein Bündel epic Klienten im BOT Modus zu beginnen. Ich habe einige Freunde, bei diesem zu helfen, jede Maschine kann ungefähr 100 bis 150 Klienten im Allgemeinen bewirten. Wir dann killall -9 die Klienten gleichzeitig, zum des Massentropfens zu simulieren. Wir versuchen jetzt, aus der optimalen Menge der Klienten darzustellen, um 386 zu erwarten, um anzufassen und wie tweak freebsd für es.
Epic script: #!/bin/sh while true; do nice epic -b -c #/bin -n k`date +%s | cut -c 4-11` portland.me. us.x386.net ;sleep 1; done
Joshua Coombs
Am Donnerstag, 31.10.02 um 17:03 Uhr schrieb Joshua Coombs:
I've been using a one line script to start a bunch of epic clients in bot mode. I have a few friends helping with this, each machine generally can host about 100 to 150 clients. We then killall -9 the clients at the same time to simulate the mass drop. We're now trying to figure out the optimal amount of clients to expect a 386 to handle and how to tweak freebsd for it.
Ah, alles klar. Du hast also MAX_CONNECTIONS auf einen höheren Wert gesetzt -- richtig?
Ich bin gerade dabei, dieses statische Limit zu entfernen, so daß der Server "beliebig viele" Clients verwalten kann. Dauert aber noch ein wenig, vielleicht wird es dieses Wochenende fertig.
Grüße Alex
Alexander Barton writes:
Am Donnerstag, 31.10.02 um 17:03 Uhr schrieb Joshua Coombs:
I've been using a one line script to start a bunch of epic clients in bot mode. I have a few friends helping with this, each machine generally can host about 100 to 150 clients. We then killall -9 the clients at the same time to simulate the mass drop. We're now trying to figure out the optimal amount of clients to expect a 386 to handle and how to tweak freebsd for it.
Ah, alles klar. Du hast also MAX_CONNECTIONS auf einen höheren Wert gesetzt -- richtig?
Ich bin gerade dabei, dieses statische Limit zu entfernen, so daß der Server "beliebig viele" Clients verwalten kann. Dauert aber noch ein wenig, vielleicht wird es dieses Wochenende fertig.
Yes, we've raised it to 3000 for most tests. If possible could you set it up such that you can choose between 'unlimited' clients or a hard max at compile time? Being able to tune mem usage based on a max client count is turning out to be a good tuning tool for the 386's we're deploying on. Larger machines may not need the limit. We prefer a last check to keep a machine from sprialing out of control.
Ja haben wir es bis 3000 für die meisten Tests angehoben. Wenn möglich, konnten Sie es herauf so einstellen, daß Sie zwischen ' unbegrenzten ' Klienten wählen können, oder ein hartes Maximum an Kompilierzeit? In der LageSEIEND, den mem Verbrauch abzustimmen, der auf einem maximalen Klient Zählimpuls basiert, fällt aus, ein gutes abstimmendes Werkzeug für des zu sein wir 386s entfalten an. Größere Maschinen können möglicherweise nicht die Begrenzung benötigen. Wir bevorzugen eine letzte Überprüfung, um eine Maschine vom Sprialing aus Steuerung heraus zu halten.
Joshua Coombs
Joshua Coombs wrote:
Yes, we've raised it to 3000 for most tests. If possible could you set it up such that you can choose between 'unlimited' clients or a hard max at compile time?
Sounds good - especially for my beloved 68k-based Macs running NetBSD.
BTW: It's very nice of you that you let your original posts translate into German but I think all readers here speak English and the quality of the German texts is quite lousy. Compare:
Because by machine translated German must seem just as grausig as just as generated English. No sheet metal box of this world speaks one of our human languages sufficiently well, in order to obtain satisfying results, which are understandable enough, in order to offer a genuine advantage in relation to a purely English text. The ' German ' translation attempts offer however a certain maintenance value. I hope, this German text am similarly merrily translated.
Regards Götz
Für die Muttersprachler hier das Original:
Denn maschinell übersetztes Deutsch muß gar ähnlich grausig anmuten wie ebenso generiertes Englisch. Kein Blechkasten dieser Welt spricht eine unserer menschlichen Sprachen ausreichend gut, um zufriedenstellende Ergebnisse zu erzielen, die verständlich genug sind, um einen echten Vorteil gegenüber einem rein englischen Text zu bieten. Die 'deutschen' Übersetzungsversuche bieten jedoch einen gewissen Unterhaltungswert. Ich hoffe, dieser deutsche Text wird ähnlich lustig übersetzt.
Am Donnerstag, 31.10.02 um 19:11 Uhr schrieb Joshua Coombs:
Yes, we've raised it to 3000 for most tests. If possible could you set it up such that you can choose between 'unlimited' clients or a hard max at compile time? Being able to tune mem usage based on a max client count is turning out to be a good tuning tool for the 386's we're deploying on. Larger machines may not need the limit. We prefer a last check to keep a machine from sprialing out of control.
An optional hard limit will be no problem to implement and seems quite important for me. Therefore it will be there :-)
Anoter problem is the already implemented dynamical allocation of channel structures: there is _no_ hard limit (except of out of memory) actually. And a hard limit would cause trouble in the network by bringing servers out of sync (server A has channel X, server B not ...).
My upcoming patch for "unlimited" connections will add a generic API to access the connection structures (actually an array is accessed directly -- no good for dynamic allocation) but internally still allocate memory "en block": if there is no space left for a new connection, a bigger memory block is requested, everything copied and the old one freed.
Disadvantage: memory will never be freed (no problem on modern systems with intelligent virtual memory management).
Advantage: the new API functions can internally still use the old array-based functions to access the connection structures.
"Someone" has to fix this up in another patch ... ;-)
Regards Alex
-
Alexander Barton -
Götz Hoffart -
Joshua Coombs