symlink.ch
Wissen Vernetzt - deutsche News für die Welt
 
symlink.ch
FAQ
Mission
Über uns
Richtlinien

Moderation
Einstellungen
Story einsenden

Suchen & Index
Ruhmeshalle
Statistiken
Umfragen

Redaktion
Themen
Partner
Planet

XML | RDF | RSS
PDA | WAP | IRC
Symbar für Opera
Symbar für Mozilla

Freunde
Benutzergruppen
LUG Switzerland
LUG Vorarlberg
LUGen in DE
SIUG
CCCZH
Organisationen
Wilhelm Tux
FSF Europe
Events
LinuxDay Dornbirn
BBA Schweiz
CoSin in Bremgarten AG
VCFe in München
Menschen
maol
Flupp
Ventilator
dawn
gumbo
krümelmonster
XTaran
maradong
tuxedo

 
verheised - never again
Veröffentlicht durch maol on Tuesday 12. December, 22:51
Aus der /.-wo-bist-Du? Abteilung
Braindump maol Was für ein ereignisreicher Tag!
Am Vormittag die Nachricht, dass Heise's Jürgen Kuri eine Artikel über uns bringen wird, daraufhin fieberhaftes Feilen an der Pressemeldung, und am Nachmittag dann die Bombe: als der Artikel veröffentlicht wird, ist unser Rechner völlig überlastet.

Zum Glück hat unser Admin bit sofort reagiert und durch verschiedene Tuningmassnahmen wieder eine gute Performance hingebracht... seine Meldungen von der Front:
Date: Tue, 12 Dec 2000 15:45:21 +0100 (CET)
Bei knapp 400 simultanen Connections ist's nicht ganz einfach,
die Oberhand zu behalten...
 
Wir werden ge'Heise't!

Date: Tue, 12 Dec 2000 15:59:32 +0100 (CET)   
- Ram: zu 80% gefuellt (20 Simultane connections)
- CPU: OK
- Netz: leer :-)
 
Pro Child (aktive TCP-Connection) brauchen wir 12 MB Memory. 400
Clients * 12 MB => 4,8 GB Memory. Das sind 4 Server a 1 GB + ein
separater Image-Server...
 
Ich hoffe schwer, dass das nicht Standard wird!  
 
Ich bin noch etwas am tunen - vielleicht krieg ich die SYN_SENT
Verbindungen noch runter.

Date: Tue, 12 Dec 2000 16:22:24 +0100 (CET)   
Ach ja, die Performance bessert sich. Wir haben immer noch an die
300 offene TCP-Links, dafuer werden sie massiv besser behandelt.
Ich hoffe, die optimalen Parameter bald gefunden zu haben.
 
Ach ja, es ist geil, dem access_log zuzusehen ;-)
Permanent 5-10 Hits/s ;-)

Date: Tue, 12 Dec 2000 19:23:33 +0100 (CET)   
                        default  symlink
Timeout                 300      30
KeepAliveTimeout         15       3
MinSpareServers           5      10
MaxSpareServers          10      15
StartServers              5      10
MaxClients              150      30

Der Timeout ist bei mir seit eh und jeh auf 30 Sekunden - alles
andere bringt CGIs ohne Output zu ewigen Irrlaufern.
 
Die Werte StartServers, MinSpareServers und MaxSpareServers hatte
ich bereits letzte Woche auf akzeptable Werte gebracht - so
alloziert Apache ca. 60% des verfuegbaren Memorys.
 
Max Clients war erst auf 20 gestellt - waehrend der Heise
Schlacht habe ich diesen Wert auf 30 erhoeht. Die
ueberschuessigen Childs werden sehr rasch gekillt und der Rest
der Maschine wird in den Swap gedrueckt. Der Wert war genug tief,
dass ich die ganze Zeit funktionierende rootshells offen halten
konnte :-)

Der fatalste Wert ist KeepAliveTimeout. Netscape haelt Sockets
offen bis der User eine andere Site besucht oder den Netscape
schliesst. Der Parameter bestimmt, wann der Webserver von sich
aus die Verbindung schliessen soll - aufgrund einer
Tuning-Anweisung aus dem Apache-Manual lag dieser auf 300
Sekunden. Die ersten 20 Symlink-Besucher hatten somit eine coole
Performance, der Rest schaute in die Roehre... Zwischen 15:30 und
16:00 habe ich den Wert sukksessive auf 3 Sekunden reduziert und
damit eine kontinuierliche Bewaeltigung der Abfragen erreicht.

Mit der aktuellen Belastung von 2-3 Hits/s kommt der Server auf
alle Faelle klar, einen zweiten Heise-Anfall sollte er auch
ueberstehen.

Ich hoffe, genug schnell reagiert zu haben (Heise kam waehrend
meiner Kaffeepause) und wuensche Euch noch froehliches Symlinken!
Hoffentlich hat er hiermit Recht, und Euch allen wünsche ich jetzt auch noch gute Nacht und viel Spass an symlink.
<müde>maol</müde>

Neuer, modularer Installer | maol Medienstar  >

 

 
symlink.ch Login
Login:

Passwort:

extrahierte Links
  • maol
  • Heise
  • Netscape
  • bit
  • Artikel
  • Mehr zu Braindump maol
  • Auch von maol
  • Kolumnen
  • Die Sicherheit von BIND
  • Use the Sauce!
  • XWorkplace
  • wtf is bender?
  • endlich - nicht mehr Amizeit
  • menu system tweaks
  • dpkg 1.8.3
  • symlink auf linux-community.de
  • Kernel 2.4 und netfilter
  • Kolumnen: Die erste OS/2 Kolumne
  • Diese Diskussion wurde archiviert. Es können keine neuen Kommentare abgegeben werden.
    Wir werden ge'Heise't (Score:2, Tiefsinnig)
    Von tim am Wednesday 13. December, 01:42 MET (#2)
    (User #152 Info)
    Ich glaube das ist schon vielen so gegangen. Wer eine Tickermeldung bei Heise reinbringt, hat zumindest fuer einen Tag gewonnen.

    Man sollte ueberlegen, ob man ge'Heise't mal in den Duden bringen sollte. Oder wahlweise auch das Unwort des Jahres vorschlaegt. *g*
    -- This space is for rent

    Tuning? (Score:1)
    Von alvi am Wednesday 13. December, 06:01 MET (#3)
    (User #169 Info) http://afussen.com
    Zum Glück hat unser Admin bit sofort reagiert und durch verschiedene Tuningmassnahmen wieder eine gute Performance hingebracht...

    Hum... hat sich die Performance wirklich wegen dem 'Tuning' verbessert, oder einfach nur weil der Ansturm zurueckgegangen ist? Die einzigen veraenderten Parameter die im Artikel erwaehnt wurden sind ein paar Apache Parameter die nicht wirklich viel ausmachen...

    Der fatalste Wert ist KeepAliveTimeout. Netscape haelt Sockets offen bis der User eine andere Site besucht oder den Netscape schliesst.

    Soviel Resourcen nimmt ein offener Socket aber nicht weg... im Vergleich zu DB-Transaktionen und HTML-rendering (durch Perl). Wuerd' mich echt interessieren: Hat bei gleicher Benutzerzahl dieser Parameter wirklich die Antwortezeiten des Servers verbessert?

    Re:Tuning? (Score:3, Informativ)
    Von kruemelmonster (kruemelmonster@tedaldi.net) am Wednesday 13. December, 07:54 MET (#4)
    (User #3 Info) http://www.symlink.ch
    Dass Problem war, dass zum offenen Socket hin auch noch die Kompilierten Perl-Script's im Cahce gehalten werden, was dann pro Verbindung 12MB Speicher kostet. Und dies, bis der User den Netscape schliesst oder auf eine andere Site wechselt.
    Wenn man den Timeout nun verkürzt, schliesst der Apache die Verbindung von sich aus und das RAM wird wieder freigegeben. Damit wird zwar die Antwortzeit für den einzelnen User schlechter, aber es können mehr User innert kürzerer Zeit bedient werden.

    Grüsse

    Marco
    --
    auch die Zehe ist ein Laufwerk
    Re:Tuning? (Netscape keepalive verhalten bug?) (Score:1)
    Von 2ri (arthur.at.korn.ch.ban.spam) am Wednesday 13. December, 09:38 MET (#7)
    (User #20 Info)
    Pro offener verbindung gehen wegen mod_perl ca 20MB drauf, die apache parameter waren also alles andere als wirkungslos.

    Stellt sich die frage: ist das verhalten von Netscape ein bug oder ein feature?

    Re:Tuning? (Netscape keepalive verhalten bug?) (Score:2, Informativ)
    Von stoney am Wednesday 13. December, 11:39 MET (#9)
    (User #197 Info)
    > Stellt sich die frage: ist das verhalten von Netscape ein bug oder ein feature?

    Einb Feature. Falls der Server die Last nicht
    abkann, muss der Admin Gegenmassnahmen ergreifen. Falls der Server niedrig ausgelastet ist, ists egal und der TCP-connect()-Overhead faellt weg.
     
    Slashdot # 780
    Symlink # 197
    Re:Tuning? (Score:1)
    Von DawnRazor (thomasb at trash.net) am Wednesday 13. December, 21:36 MET (#12)
    (User #8 Info) http://www.trash.net/~thomasb/
    Soviel Resourcen nimmt ein offener Socket aber nicht weg... im Vergleich zu DB-Transaktionen und HTML-rendering (durch Perl).

    Auf Symlink läuft mod_perl. mod_perl prekompiliert die Perlskripte, die dann dauernd im Speicher gehalten werden. Dies bringt einen grossen Performanceschub, da nicht jedesmal ein Perl-Interpreter geforkt werden muss. Allerdings ist die Kehrseite der Münze, dass jeder Child vom Apache mehr Memory braucht.

    Hum... hat sich die Performance wirklich wegen dem 'Tuning' verbessert, oder einfach nur weil der Ansturm zurueckgegangen ist? Die einzigen veraenderten Parameter die im Artikel erwaehnt wurden sind ein paar Apache Parameter die nicht wirklich viel ausmachen...

    Doch doch, die machen viel aus. Wenn Du den ganzen Artikel gelesen hättest, wüsstest Du, dass jede TCP-Connection 12Mbytes Arbeitsspeicher braucht (da für jede offene Connection ein Child da sein muss). Durch die Aenderung dieser Parameter wird verhindert, dass zuviele Connections gleichzeitig offen sind.

    Re:Tuning? (Score:1)
    Von alvi am Thursday 14. December, 06:58 MET (#13)
    (User #169 Info) http://afussen.com
    Doch doch, die machen viel aus. Wenn Du den ganzen Artikel gelesen hättest, wüsstest Du, dass jede TCP-Connection 12Mbytes Arbeitsspeicher braucht (da für jede offene Connection ein Child da sein muss).

    Hab's schon gelesen, aber diese 12MB-Berechnung ist etwas zu simpel.

    Der Punkt ist dieser: Wenn der Server wie verrueckt ueberrannt wird, so dass pro Sekunde mehrere Childs geforkt werden, wird der Server mehr mit forken, 'perlen' und mit DB-Zugriff beschaeftigt sein, und ge-'idelte' childs werden auspaged. 'KeepAliveTimeout' wurde von 15 auf 3 Sekunden korrigiert, nach meiner Berechnung wird der Schaden damit nicht viel kleiner sein:

    • Der Artikel sagt: 20 simlutane connection (= 12*20) entspricht 80% Ram -> wir haben um die 300MB Speicher
    • Als der Ansturm etwas runter ging, hatte es um die 10 Hits/sec
    • Dh, alle 3 Sekunden werden 3*10*12MB=360MB geforkt -> Die Machine ist immernoch hoffnungslos am pagen.
    Darum war die Frage legitim, auch nach lesen des Artikels. ;)
    Re:Tuning? (Score:3, Interessant)
    Von maol (maol at symlink.ch) am Thursday 14. December, 10:53 MET (#14)
    (User #1 Info) http://www.maol.yi.org
    Dh, alle 3 Sekunden werden 3*10*12MB=360MB geforkt -> Die Machine ist immernoch hoffnungslos am pagen.

    Ist AFAIK eine Fehlüberlegung. Wir haben die Anzahl geforkte Childs auf 20 beschränkt, also sind immer max. 20*12MB RAM belegt durch httpds. Was die Wartezeiten verursachte war die Tatsache, dass jeder dieser 20 Clients 5 Minuten (300 Sekunden) bei uns in der Leitung hing, neue Leute also keine Chance auf einen Connect hatten.
    Bei 3 Sekunden ist der Durchsatz an Usern viel höher, da schon nach drei Sekunden ein httpd wieder frei ist für eine neue Connection.

    maol
    --
    schneelos, glücklos, das grosse Los

    guter test bevor... (Score:0)
    Von Anonymer Feigling am Wednesday 13. December, 09:15 MET (#5)
    guter test ge'heise't zu werden. bevor man vielleicht mal geslashdot wird :)
    Statistiken anschauen (Score:3, Informativ)
    Von pfr am Wednesday 13. December, 09:17 MET (#6)
    (User #4 Info) http://www.math.ethz.ch/~pfrauenf/
    Ganz interessant ist es, wenn man heute (am Tag nach der Ticker-Meldung) die Statistiken von Apache anschaut. Der 12. Dezember ist da ganz klar als starker Ausschlag in den Tages­Grafiken zu sehen. In der stündlichen Auslastung kann man (unter der Annahme, dass die vorhergehenden Tage eher verschwindenden Anteil haben) ausmachen, dass der Ansturm zwischen 14:00 und 15:00 Uhr eingesetzt hat und erst gegen Feierabend wieder deutlich gesunken ist.

    .oO( Die meisten Leute lesen den Ticker scheinbar vom Arbeitsplatz aus. )

    Die Referer­Statistik zeigt, dass etwa 3200 Hits mit einem Referer von Heise zu Symlink gekommen sind. Ein Vergleich der Länderstatistik mit der des Vormonats (aus dem Testbetrieb) zeigt, dass viele Leute aus der Schweiz, Deutschland, Österreich und .net zu uns gekommen sind. Allerdings waren ziemlich wenig Österreicher da: lesen die den Ticker nicht oder haben die schon sowas ähnliches?
    --
    Kühe geben keine Milch, die Bauern nehmen sie ihnen weg!

    Re:Statistiken anschauen (Score:1, Informativ)
    Von Anonymer Feigling am Wednesday 20. December, 14:13 MET (#16)
    Wenn man beachtet das Germany 80 Mill Einwohner hat und Österreich 8 Mill. dann schaut es für die Österreicher schon besser aus 26% zu 3%
    User Feedback (Score:1)
    Von markus_b am Wednesday 13. December, 10:34 MET (#8)
    (User #124 Info) http://www.markus.org

    Ich bin einer der User, der durch den Heise Newsticker auf symlink.ch gestossen ist. Dies allerdings erst gegen Abend (18:30). Da ist mir die Performance nicht besonders negativ aufgefallen.

    Symlink ist Super !

    Markus

    Re:User Feedback (Score:1)
    Von Ventilator (ventilator auf parodia punkt zee haa) am Wednesday 13. December, 14:13 MET (#10)
    (User #22 Info) http://www.mp3.com/bri
    Na, dann aber unbedingt weitersagen! =:-)
    --
    Diesen Satz bitte nicht lesen!
    Re:User Feedback (Score:1)
    Von dadith am Wednesday 13. December, 18:01 MET (#11)
    (User #116 Info)
    Mir ging es aehnlich, mein Account wurde mir um 17:20 zugemailed, d.h. ich war so gegen 17:15 das erste mal auf Symlink und die Seite war schneller da als Slashdot normalerweise. Die Mail kam auch prompt an, keine Spur von Lag.
    Und das mit dem Symlink ist super koennte ich nur unterstreichen, wenn Symlink das <u> Tag nicht filtern wuerde.

    Dadith
    Auch interessant zu wissen... (Score:1)
    Von Cobalt am Thursday 14. December, 18:46 MET (#15)
    (User #210 Info)
    ...das der 'verheised'-Beitrag der mit den meisten Views ist. Fehlt der Seite wohl noch ein bisserl an richtigen Info ^___^ Das wird schon!

    Linux User Group Schweiz
    Durchsuche symlink.ch:  

    Never be led astray onto the path of virtue.
    trash.net

    Anfang | Story einsenden | ältere Features | alte Umfragen | FAQ | Autoren | Einstellungen