siege stirbt während Belagerung

max93

Well-Known Member
Hallo!

Ich versuche gerade 2 Server von mir ein wenig zu benchmarken. Da es sich um Webserver handelt, möchte ich dazu gerne siege verwenden.

Aber: wenn ich es ausführe, stirbt es an unterschiedlichen Stellen:

FreeBSD 5.4:
Code:
Segmentation fault (core dumped)
root@www:~# uname -srm
FreeBSD 5.4-RELEASE-p22 i386

FreeBSD 6.1:
Code:
Segmentation fault: 11 (core dumped)
root@www:~# uname -srm
FreeBSD 6.1-RELEASE-p10 i386

Auf beiden Servern habe ich es inzwischen geschafft, eine komplette Belagerung abzuhalten, was mich noch mehr verunsichert. Beide Server laufen seit über 1 Jahr in jeweils unterschiedlichen Rechenzentren ohne jegliche Ausfälle. Der Server mit 6.1 wurde gestern Nacht aktualisiert, buildworld- und buildkernel-Läufe (auch mit -j3) waren bis jetzt auf keinem der Server jemals mit seltsamen Meldungen abgebrochen.

Leider kann ich nicht mal eben einen Server vom Netz nehmen und die Hardware genauer untersuchen, zumal es ja auch keine weiteren Anzeichen für defekte Hardware gibt.

Hatte schonmal jemand mit siege ähnliche Probleme. Google liefert mir nur ganz wenige Stellen mit ähnlichen Problemen.

Danke & Ciao.
Markus Mann
];-)
 
Hatte schonmal jemand mit siege ähnliche Probleme.

Nein ich hatte noch keine Probleme mit dem Programm.

Je nach Deiner Motivation könntest Du ja versuchen rauszufinden weswegen das Prgramm abgestürtzt ist:
- System Call Tracing (ktrace, truss, strace)
- Library Call Tracing (ltrace)
- falls ein core file geschrieben wird: gdb
 
Hallo!

Je nach Deiner Motivation könntest Du ja versuchen rauszufinden weswegen das Prgramm abgestürtzt ist:
An der Motivation würde es hier gar nichtmal scheitern, aber ich habe das noch nie ernsthaft gemacht (und schon gar kein vernünftiges Ergebnis dabei erzielt) und bräuchte wohl jemanden, der mir dabei über die Schulter sieht und mir sagt, was zu tun ist und was die Ausgabe jetzt bedeutet. Hinzu kommt, dass ich kein Programmierer bin.

Danke & Ciao.
Markus Mann
];-)
 
An der Motivation würde es hier gar nichtmal scheitern, aber ich habe das noch nie ernsthaft gemacht (und schon gar kein vernünftiges Ergebnis dabei erzielt) und bräuchte wohl jemanden, der mir dabei über die Schulter sieht und mir sagt, was zu tun ist und was die Ausgabe jetzt bedeutet.
Guter Zeitpunkt zu beginnen :)

Ich kenne das Programme seit 2001, habe es aber seit längerem nicht verwendet.

Vielleicht komme ich Mitte nächster Woche mal dazu, bin aber bereits bei CURRENT.
 
Hallo!

Guter Zeitpunkt zu beginnen :)
Ja, ja ];-)

Vielleicht komme ich Mitte nächster Woche mal dazu, bin aber bereits bei CURRENT.
Da mein Problem sowohl mit 5.4, als auch mit 6.1 auftritt, spielt das vielleicht gar keine Rolle. Ich wäre dir jedenfalls dankbar, wenn du das testen würdest. Allerdings habe ich es auch bei mir Zuhause installiert, dort hatte ich noch keinen derartigen Absturz, aber die Werte sind von hier aus halt auch nicht so aussagekräftig, weil die beiden Server Daten mit gut 25 Mbit austauschen können, ich hier aber nur 2 Mbit habe.

Ganz interessantes Detail: Wenn der belagernde Server gerade mit dem Übersetzen von Software beschäftigt ist oder sonstwie IO-Last hat läuft siege einwandfrei durch. Zuletzt war es ein buildworld, eben war es die Übersetzung von screen und am anderen Server portsnap extract.

Doch Hardware? Warum aber ausschliesslich bei siege? Warum 2 unterschiedliche Server mit dem gleichen Problem?

Ciao.
Markus Mann
];-)
 
weil die beiden Server Daten mit gut 25 Mbit austauschen können, ich hier aber nur 2 Mbit habe.

Ganz interessantes Detail: Wenn der belagernde Server gerade mit dem Übersetzen von Software beschäftigt ist oder sonstwie IO-Last hat läuft siege einwandfrei durch. Zuletzt war es ein buildworld, eben war es die Übersetzung von screen und am anderen Server portsnap extract.

Doch Hardware? Warum aber ausschliesslich bei siege? Warum 2 unterschiedliche Server mit dem gleichen Problem?
Nochmal zum Mitdenken:
1. siege verstirbt auf den Client-Rechner, findest Du zu dem Zeitpunkte irgendwelche Meldung auf dem Server (unter /var/log, in access_log und error_log des httpd)?
2. das Problem tritt nur bei 2 Mbit auf?
3. I/O verhindert Abbrüche?

Ich hatte mal mit einem Programm unter Linux viel Spass weil sich in dem SUSE-Kernel der Sceduler verhedderte.
Sobald ich strace an den Prozess dranhing war das Problem weg!
 
Servus!

Nochmal zum Mitdenken:
1. siege verstirbt auf den Client-Rechner, findest Du zu dem Zeitpunkte irgendwelche Meldung auf dem Server (unter /var/log, in access_log und error_log des httpd)?
Das müsste ich nochmal checken, komme aber gerade nicht dazu.

2. das Problem tritt nur bei 2 Mbit auf?
Nein: Ich teste 2 Server in unterschiedlichen Rechenzentren von 2 unterschiedlichen Providern. Jeder Server ist mit 100 Mbit angebunden (Brutto gehen da 25-30 Mbit zwischen den beiden Servern).

3. I/O verhindert Abbrüche?
Ganz genau: "make buildworld", "portsnap fetch extract" und nochwas, was hauptsächlich auf der Platte "rummacht" auf dem Server, der gerade siege ausführte, sorgte für einen einwandfreien siege-Lauf.

Sobald ich strace an den Prozess dranhing war das Problem weg!
Das habe ich bis jetzt auch noch nicht testen können. In einer guten Woche sollte ich wieder mehr Zeit dafür haben, dann teste ich deine Anregungen nochmal.

Danke & Ciao.
Markus Mann
];-)
 
Back
Top