[MasterofDisaster]

Liebe Boarduser,

Nun muss ich auch einmal die Hilfe in diesem Bereich des Boards in Anspruch nehmen. Da ich mir im rootforum nur Kommentare wie: "als Serveradmin muss man das doch selber wissen" eingefangen habe (als wirklich unbegründete Reaktion auf genau das selbe Posting wie dieses) hoffe ich hier auf eine andere Resonanz

Auf einem Debian-Server bei Strato (P4 2.8, 1GB RAM) sind 50 Webhosting-Kunden, unsere Obergrenze pro Server. Traffic läuft ingesamt nichtmal 200GB über die Kiste im Monat, wird also sonst eigentlich nicht wirklich ausgenutzt.

Auf dem System laufen neben einem amavis/Maia-Mailguard, MySQL4 ein Apache2 worker threaded mit PHP4/5 über fastcgi/suexec - alle in aktuellsten Versionen.

Soweit, so gut. Auch hier nehme ich aber gerne Vorschläge an. An der trennung der Dienste arbeiten wir derzeit bereits, das ist uns bekannt, das Webserver und Datenbankserver und Mailserver auf einem Gerät nicht gerade optimal ist. Trotzdem sei gesagt, dass die Maschine gute Dienste leistet und alle mehr als zufrieden sind, wir bekommen nur gutes Feedback, v.a. weil wir durch mod_security schon viele vor dem Forentod durch verplante Updates retten konnten.

Back to topic:
U.a. betreibt ein Kunde auch ein Forum auf PHPBB2-Basis, welches bisher maximal 10 fastcgi-Threads und mit nice 1 lief. Das habe ich jetzt heute erstmal auf 4 Threads und nice 5 runtergeschraubt. Bisher hat das Board mit etwa 30 gleichzeitigen Usern und bisher etwa 70.000 Beiträgen abends regelmässig für top-Werte über 2.5 gesorgt. Ich weiß, dass die natürlich auch mit Vorsicht zu genießen sind, aber das System wird schon merklich langsamer. Als Enduser bekommt man das zumindest abends teilweise mit. Nicht tragisch, aber ich will vorbeugen bevor es Reklamationen gibt. Ich möchte natürlich die Board-Kunden demnächst auf einen weiteren Server auslagern. Aber Basiswissen schadet ja nicht:

Sind 30 User und die "paar" Postings für die Maschine zu viel?
Neben diesem Board laufen noch 2-3 andere, die aber mit 5-6 Usern gleichzeitig nicht als ernsthafte Bedrohung zu sehen sind.

Ich würde mich über Erfahrungswerte in dem Bereich sehr freuen!
Auch Tuning-Tips sind willkommen!

[MasterofDisaster]

Server Software: NOYB
Server Hostname:
Server Port: 80

Document Path: /forum
Document Length: 320 bytes

Concurrency Level: 10
Time taken for tests: 9.795940 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Non-2xx responses: 108
Total transferred: 58428 bytes
HTML transferred: 34560 bytes
Requests per second: 10.21 [#/sec] (mean)
Time per request: 979.594 [ms] (mean)
Time per request: 97.959 [ms] (mean, across all concurrent requests)
Transfer rate: 5.82 [Kbytes/sec] received

Nach einigen Optimierungen ist es jetzt kaum merkbar, trotzdem scheinen mir diese Antwortzeiten für ein PHPBB recht schlecht?!?

[eraser]

Wie ist es denn mit den Logfiles? Loggen Apache und evtl sogar mysql mit? Ist das wirklich notwendig?

Bei 30 gleichzeitigen Usern die sich gerade in einem Forum wild durchklicken merkt man das sicherlich auf einer solchen Maschine, wenn noch soviele andere ebenfalls dort gehosted sind. Viele Tipps gibt es da nicht.. das ist vielleicht auch der Grund für die schlechten Antworten.

Interessant wäre noch zu wissen, ob das alles selbst kompiliert wurde. Für dich ist evtl. interessant zu wissen, dass Debian eine der schlechtesten Distribution ist, was mysql und deren Performance angeht.

[MasterofDisaster]

Moin Eraser,

Trotzdem Danke für Deine Antwort

Ja, ich hatte mir so langsam ähnliches gedacht. Ausserdem bringen mir gleichbare Boards auf anderen Server beim Benchmarking sogar noch schlechtere Ergebnisse, daher scheine ich vielleicht auch ein wenig die Ansprüche zu hoch geschraubt zu haben.

Das Debian die unperformantesten Pakete hat ist mir bekannt, darum sind auch bis auf Postfix alle anderen Dienste von Hand kompiliert.

Ich konnte jetzt ein paar Prozent Geschwindigkeite durch Justierung der Apache Worker-Einstellungen und der PHP-Einstellungen erreichen. Ausserdem habe ich die maximalen dauerhaften mysql-Verbindungen in der php.ini eingeschränkt pro user und habe die my.cnf ein wenig geändert (Timeouts runter, maximale Paketgröße gesenkt).

Hat schon wer Erfahrungen mit Apache 2.2 und MySQL5? Bringen Updates (ausser Problemen mit PHP beim letzteren) Geschwindigkeitsvorteile?

[Bestrafer]

Hast du eAccelerator / memcache in Verwendung?

[MasterofDisaster]

Gestern installiert und ausprobiert, also eacc, aber leider blocken meine grsecurity-Einstellungen die Ausführung, da muss ich noch etwas Feintuning betreiben.

Allerdings auch nur auf dem Testsystem.
Auf einem Produktivsystem mit Kunden halte ich eacc für zu gewagt.
Das führt am Ende doch nur zu Problemen.
Lasse mich aber gerne vom Gegenteil überzeugen.

[Bestrafer]

Wir setzen eAccelerator eigentlich mit durchweg guten Ergebnissen auf fast allen Frontend-Servern ein.

Durch eAccelerator verursachte Probleme sind mir von unseren Installationen bisher keine untergekommen.

Dabei handelt es sich jedoch nicht um Systeme auf denen Kunden-Hosting stattfindet. Auf unseren Frontend-Servern werden nur eigene Projekte betrieben.

[Toady]

Slightly OT, but...

Zitat von eraser 

Bei 30 gleichzeitigen Usern die sich gerade in einem Forum wild durchklicken merkt man das sicherlich auf einer solchen Maschine, wenn noch soviele andere ebenfalls dort gehosted sind.

Was kostet so ein Webforum eigentlich an Ressourcen? Also, was daran ist der Flaschenhals?

Ist es die Datenbank, die die inhalte zurückliefert, oder ist es eher die Aufbereitung und das Zusammenbasteln in PHP im Indianer?

Ersteres kostet ja keine Rechenzeit, sondern die einzelnen Threads werden wohl die meiste Zeit als sleep/deep_sleep im Kernel vor sich hin warten, bis die Daten über die langsame hdd im Kernel ankommen, letzteres hingegen kostet doch eher Rechenzeit.

Wenn die Load auf 2.5 hochgeht (ich gehe mal von einem Einprzessorsystem aus, wo die Elastizitätsgrenze dann bei 1 liegt), aber mit keinem Wort eine hohe CPU-Belastungs erwähnt wird, deutet das doch eher auf vorsichhinwartende Prozesse hin, also wird wohl die DB der Flaschenhals sein (wenn ich mir das jetzt richtig zusammengereimt bekommen habe), würde es denn dann etwas bringen, wenn du die Rechenzeit der PHP-Scripte durch eAccelerator o.ä. verkürzt? Dadurch kommen die Daten ja auch nicht schneller am Kernel an.

[MasterofDisaster]

Soooo OT ist das gar nicht. Du liegst mit Deiner These aber nur teilweise richtig.

Ich konnte unsere Belastungsspitzen jetzt ganz gut eingrenzen - und in der Tat ist es so, dass MySQL zu Spitzenzeiten dann gerne auch mal 90% CPU konsumiert, aber nur über ein paar Sekunden hinweg, dann ist wieder gut. Und diese Anfragen kommen in der Tat so gut wie immer von PHPBB's in aktuellsten Versionen.

Aber der Apache verschlingt auch einiges an RAM, so dass von den 1GB in der Maschine oft 400-500 MB alleine vom Apache genutzt werden. Hierbei beobachte ich eine merkwürdige Sache (wobei merkwürdig im Auge des Betrachters liegt): Anfänglich liegt Apache bei ~30 MB pro Prozess/Server, es werden zu Beginn 2 gestartet, nachher kommt noch einer bei Belastung dazu (worker MPM). Das geht soweit, dass ein Apache samt Children gerne mal 160 MB RAM konsumiert. Es sei darauf hingewiesen, dass viel php-fastcgi genutzt wird, so dass rund um die Uhr bestimmt 20-25 php4.4.2-fastcgi Prozesse laufen.

Bei uns war das Nadelöhr aber mod_security - nachdem ich mit einigen Rulesets von gotroot.com scheinbar zu viel des Guten wollte habe ich in akribischer Kleinarbeit die Konfigurationsdateien auf ein Minimum reduziert - und siehe da, die Load geht runter auf derzeit 0.57, 0.72, 0.59, was mehr als OK ist.

Dazu kommt, dass die Maschine nebenher allerdings noch mit MaiaMailguard einiges an Spam vor den Mailservern abfängt. Der Spam wird on-the-fly in eine MySQL geschrieben, worauf das Interface von Mailguard zugreift. Hier sehe ich das absolute Hauptproblem dieser Maschine: Maia fordert zuviel von der Maschine. Darum werde ich die Maiadatenbanken für den Host jetzt auch auslagern.

Trotzdem ist bei der Kiste jetzt mit mehr Usern schluss, 59 Kunden auf einem Server ist schon ne Menge und unser Konzept ist eigentlich nicht mehr als 50 Kunden pro Maschine, damit genügend Ressourcen für alle da sind.

Hat hier eigentlich jemand schon performancetechnische Erfahrungen mit Apache2.2 vs unserem 2.0.55/54?

[eraser]

Ich wollte letztens einen meiner Server mal auf 2.2 updaten.. aber die ApacheDoku ist ja mal ums beim Namen zu nennen sowas von für den Arsch, dass alles aus ist. Ich habe wirklich anderes zu tun, als mich einen Tag damit zu beschäftigen, wie ich am besten meinen Apache kompiliere, so dass es auch hinterher wirklich passt und die Doku welche es auf der offiziellen Seite gibt, trägt genau dazu nicht bei. Evtl. bin ich aber auch einfach nur zu blöd dazu dass alles auf anhieb richtig zu verstehen.

Das Problem generell bei einer solchen Maschine ist immer, dass es

a.) immer wieder ausreißer gibt. sprich es fällt irgendjemandem ein, er muss jetzt dick werbung machen oder ein toll selbstgeschriebenes script läuft amok. für den fall sollte man immer genug ressourcen in petto haben. das problem hierbei ist allerdings, dass es eben dann auch weniger lohnend wird, wenn man weniger leute unterbringen kann. gerade für neue anbieter sicherlich hart. ich erfahre ja selbst etwas in ähnlichm bereich und kämpfe auch um das letzte bisschen was so rauszumkitzeln geht.

b.) sobald die cpu ausgelastet ist, bewegt sich 0 mehr. sprich anders als zB bei iowait bewirkt eine dichte CPU, dass keine Seite für mind. den Zeitraum bis sich das gute Stück wieder erholt hat - aufzurufen ist. Ich habe im moment ein ähnliches Problem, allerdings läuft bei mir nur noch ein Perlscript auf dem Pageserver und alles andere ist bereits ausgeclustert. Die Sicherheitsgrafik (captcha) sorgt bei mir im Moment dafür, dass der Server in der Primetime oder zB heute kaum mehr zu erreichen ist.

und ja.. es ist die mysql Datenbank, welche bei einem Forensystem, dass ein wenig grösser ist als Flaschenhals fungiert.

[MasterofDisaster]

Da frage ich doch mal sehr naiv:
Ist ein 70.000-Postings/600-User-PHPBB2 "groß"?
Ich vergleiche da gerne mit Gulli und denk mir dann immer: Hmm, muss irgendwie an Deiner Konfiguration liegen, weil 600 User ist ja nix.

[eraser]

Naja.. wenn 30 Leute gleichzeitig drauf unterwegs sind, ist es in jedem Fall nicht mehr klein in meinen Augen. Bei dir kommt ja noch erschwerend dazu dass noch eine Menge anderer Leute auf dem Server rummachen und du eigentlich vermutlich nie so genau weisst, was sie da gerade treiben. Bestes Beispiel wäre eben ein Chat mit Dauerrefresh - den merkst du relativ früh.

Ich hab auf einem Server auch so ein Forensystem gehostet auf einem Server der nur die Hälfte von deinem Ram hat. Nach einiger Arbeit und etwas selbstkompilieren ist die Seite jetzt fast garnicht mehr zu bemerken. Böse Sache sind eben Module welche zB geladen werden und aber nicht gebraucht.

Die CPU dicht zu bekommen ist recht schnell passiert - ein falsches Modul und Ende ists. Das eben bei mir gewesene Problem hat sich erledigt. Es lag an PerlMagick, welches ich durch "normales" GD ersetzt habe und nun flutscht es wieder. (erstmal)

Bei deinem geringen Load (ist der auch um diese Uhrzeit so?) musst du dir aber so oder so denke ich im Normalfall und wenn deine Kunden brav bleiben - keine Gedanken machen.

[MasterofDisaster]

Verdammt, jetzt habe ich grade auf die Board-Info-Mail geantwortet.

Ja, die load-Daten waren von jetzt gerade eben und sind völlig OK.

Ich arbeite allerdings jetzt auch aktiv an der Auslagerung der Maildienste auf einen unserer Mailserver, damit nachher nur noch der Apache auf der Kiste seine Dienste leistet. Das war sowieso schon lange überfällig und riskant.

Aber ja, jetzt bin ich auch mit der load recht zufrieden. Da wir nur Managed-Hosting betreiben, also kein Massenhosting und neben mir noch 2 andere Techniker täglich über die Kisten gucken und bei hohen Loads per SMS benachrichtigt werden hatten wir allerdings bisher auch bei Script-Amoks kaum Probleme.

Überlege jetzt nur noch in Zukunft keine Strato-Server mehr dazuzuholen, sondern nur noch bei Hetzner zu mieten. Mir machen da allerdings die Berichte über Stromausfälle sorgen.... wobei schlimmer als Servertausch bei Server mit RAID und defekter Festplatte bei Strato kann's nicht werden ^^

[eraser]

Ich hatte auch so ne Kiste wo die Platte kaputt und der ganze Server ausgetauscht werden sollte. Die wollen ja dann ein Fax mit Perso und allem blar. Das gute daran ist, dass man seine Daten noch sichern kann. Das schlechte daran ist, dass man einen Ausfall hat. Sie bieten wirklich sehr sehr billig Leistung an und auch - das muss man einfach sagen - eine Flat und kicken nicht ohne Grund. Der Support ist mies und hat eine hohe Latenz aber irgendwoher muss der Preis eben kommen. Ebenso, wie man sicherlich nie wirklich 100MBit dort haben wird. Auch intern haben die Maschinen leider nur 10Mbit. Es fehlt auch der GBit Uplink aber vermutlich wäre das bei der Hardware die da verbaut wird ohnehin nicht effizient. Echte Serverteile kann ich mir nicht vorstellen, dass dort verbaut werden für den Preis. Bisher habe ich noch nichts vergleichbares gefunden, wenn man sich mit diesen ganzen Tatsachen abfinden kann.

Hast du deine Domain noch bei Strato? Falls ja, viel Spass. Mein Umzug zu einem anderen Anbieter, damit ich vdns-Zugang habe, hat über 2 Monate nun gedauert und einige Anrufe. Zuerst bekam ich die Kündigung und zum Schluss haben sie es einfach nicht geschafft mir meinen Auth-Code zu schicken und die Domain war kurz davor freigegeben zu werden. Alles sehr unfein.

edit: eines noch.. die kisten von strato haben raid1. wirklich schneller ist das nicht, sondern dient eigentlich nur der sicherung der daten.

[MasterofDisaster]

Neee, Domains haben wir zum Glück schon ewig bei Providerdomain aka Schlund und sind damit, entgegen vieler Kritiker, sehr zufrieden.

Das war das was ich mit RAID bei Strato meinte - die verbauen zwar im höchsten Modell sogar Hardware-RAID1, aber wenn eine Platte abschmiert, dann wird dennoch der ganze Server getauscht. Im Grunde ist dieses Raid also fürn Arsch, weil dann kann ich mich auch auf das externe FTP-Backup verlassen.

Über den Strato-Support an sich kann ich nicht motzen. Wir haben für die 3 Kisten bei Strato die erweiterte 24h-Hotline und ich wurde sogar bereits mehrmals mitten in der Nacht (1 Uhr!) aus dem Rechenzentrum selber von einem Techniker zurückgerufen. Da war ich wirklich beeindruckt, erst recht als das beim zweiten Mal genauso ablief.

Trotzdem will ich die Stratokisten loswerden, mir bereiten Massenhoster Magenschmerzen.

Aber jetzt _sind_ wir OT *g*

[Toady]

Zitat von MasterofDisaster 

Soooo OT ist das gar nicht. Du liegst mit Deiner These aber nur teilweise richtig.

Ich konnte unsere Belastungsspitzen jetzt ganz gut eingrenzen - und in der Tat ist es so, dass MySQL zu Spitzenzeiten dann gerne auch mal 90% CPU konsumiert, aber nur über ein paar Sekunden hinweg, dann ist wieder gut. Und diese Anfragen kommen in der Tat so gut wie immer von PHPBB's in aktuellsten Versionen.

Moooment - woher kommen die 90% denn - sind das Prozesse, die mit sleep im Kernel hängen ("waiting", wenn du 'top' eingibst)?

Der Register /proc/loadaverage ist ein Pseudowert, der nichts über die Auslastung, sondern etwas über die Elastizität aussagt.
Der Wert besagt, wieviele Prozesse zeitgleich CPU-Zeit anfordern - liegt ein Prozess nun als Kernelthread vor und will zB Daten aus der Datenbank haben, dann wird dieser Prozess mitgezählt, obwohl er keine CPU-Zeit konsumiert. Er verstopft allerdings einen Thread, da der Kern ihn nicht "auslagern" kann o.ä. (jetzt kommts uach auf die Architektur der CPU an - manche CPUs, wie zB Opterons oder Xeons, können mehrere Kernelthreads gleichzeitig fahren, auch arbeiten sie intern anders - Opterons laden zB schon neue Daten in den Cache während der vorherige Thread noch gar nicht abgearbeitet ist; ein CPU-Thread besteht aus vier Teilen:
a) Laden vom RAM in den Cache
b) eigentliche Berechnung
c) schreiben des Ergebnisses in den CPU-Cache
d) Ergebnis in den RAM schicken

Ein Opteron kann nun 4 Threads gleichzeitig bearbeiten, ein Xeon oder Pentium zB nur zwei, ein Celeron kann gar nur einen Thread, weshalb der schnöde Vergleich von GHz-Zahlen auch nicht das alleinige Kriterium ist).

Ich habe das hier mal etwas ausführlicher erklärt und auch grafisch gezeigt:
http://board.gulli.com/thread/425600...eimachen/2/#40

Dazu kommt, dass die Maschine nebenher allerdings noch mit MaiaMailguard einiges an Spam vor den Mailservern abfängt. Der Spam wird on-the-fly in eine MySQL geschrieben, worauf das Interface von Mailguard zugreift. Hier sehe ich das absolute Hauptproblem dieser Maschine: Maia fordert zuviel von der Maschine. Darum werde ich die Maiadatenbanken für den Host jetzt auch auslagern.

Zum Thema Mail kann ich wieder mitreden, das ist meine Baustelle :-)

Wenn du etwas performates willst, schau dir mal DSpam an - gibt nicht wenige, die in solchen eher kleinen Umgebungen wie bei dir darauf schwören.

Ich persönlich schwöre auf EXIM mit SA-EXIM, wobei SA-EXIM via LMTP an (einen oder mehrere) spamds auf dahinterlaufenden Maschinen übergibt und die Bayes-DB auch auf Postgres läuft, allerdings schluckt SpamAssassin selbst unmengen, bietet aber die besten Ergebnisse.
So kann ich schon im SMTP-Dialog evtl. ablehnen (so der einzelne User das wollte).
Das dauert pro Mail zwischen 3-5 Sekunden inkl. Scannen durch Clamd.

PerUser schiebe ich dann alles nochmal durch Bogofilter (schnell, klein, pflegeleicht, bietet allerdings nur statistische Bewertungen, aber alles andere wie RBL, RHBL, URI-Checks usw. hat SA ja schon gemacht) und evtl. noch einen zweiten AV-Scanner (je nach Kundenwunsch) und bewerte das Gesamtergebnis inkl. des ersten Scanns durch SA-EXIM dann nochmals als MDA-Prozess und lege dann gemäß der Regeln in den jeweiligen Ordner ab.

Das bietet im Vergleich zu DSpam zwar wesentlich bessere Möglichkeiten und eine sehr gute Erkennungsrate (bei entsprechend gepflegten Filtern und trainierter Bayes-Basis), kostet aber wirklich viel Ressourcen, vorallem RAM.