Case Study: Hochfrequentiertes Forum auf FreeBSD

ww

Well-Known Member
Hallo zusammen, ein kleiner Erfahrungsbericht:

Über mehrere Ecken bin ich gebeten worden, als Co-Admin ein vBulletin-Forum, das bei Hetzner auf einer SuSE-Box lief, zu betreuen. Es handelt sich dabei um das zweitgrößtes Politikforum in Deutschland, zu erreichen unter www.politikforen.de

Die Performance war seinerzeit nicht optimal; bei etwas 200 Usern gleichzeitig und einem Load > 4 wurde der Server ziemlich langsam und fing an zu swappen. Der Load ging zu Stoßzeiten auch auf 15 hoch und dann war Schicht mit der Erreichbarkeit. Außerdem schien das Forum gelegentlichen Angriffen, die über den üblichen ssh-Schmutz hinausgehen, ausgesetzt zu sein.

Seinerzeitige Hardware: AMD XP 3000+, 1GB RAM; HD 40GB

Ich wurde dann irgendwann beauftragt, zukünftig das Forum zu hosten und habe ein entsprechendes System aufgesetzt.

Zur Hardware: Da es ein 1HE-System aus Standardkomponenten sein sollte und eine gute thermische Stabilität erforderlich war, wurde bei der CPU ein AMD XP 1800+ mit Thoroughbredkern gewählt. Bei guter Performance verbraucht der Chip unter Vollast nur 51 Watt.

Der Arbeitsspeicher wurde zunächst bei 1GB belassen und zwei Samsung-Platten mit je 80GB zu einem RAID1 (gmirror) zusammengefaßt.

Das Setup sollte vor allem schlank und sicher ausfallen.

Folgende Ports wurden also installiert:
cvsup-without-mirror
portupgrade
mysql41-server
apache2
php5
php5-extensions

Dazu noch ein paar kleine Tools wie portaudit, chkrootkit, bsdsar, freecolor usw.
Die Box hat zwei Intel NICs (fxp), eine für ein internes Netz (Backup und privater cvsup-Server), die andere für den Verkehr nach draußen.

Als Paketfilter wurde "pf" gewählt und relativ restriktiv konfiguriert. Außer Port 80 und 22 ist alles dicht. Ein Verlegen des ssh-Ports, um Scriptkiddies zu stoppen, wird für die Zukunft erwogen. Apache, PHP und MySQL wurden mit kurzem Timeout konfiguriert, um die Empfindlichkeit gegen DoS-Attacken etwas zu verringen. Das DB-Backup (ca. 1GB, bzipped ca. 250MB) wird nachts per cronjob erledigt.

Resultat:
Die MySQL-Laufzeit ist wegen der schwächeren CPU um etwa 20% langsamer, was aber keinen merklichen Unterschied ausmacht. Da für MySQL 512MB RAM reserviert sind, werden viele Queries direkt aus dem Arbeitsspeicher geholt. Unter Last ist die Performance deutlich besser als zuvor. Die besagten 200 User verursachen jetzt einen Load von etwa 1.5, einen CPU-Verbrauch von ca. 50% sowie etwa 300MB RAM-Nutzung. Kein Swappen weit und breit. Traffic wird etwa 100GB monatlich verursacht.

Die Performanceverbesserung liegt wohl hauptsächlich an der sehr schlanken Konfiguration des Servers (kein webmin, keine GUIs). Nicht auszuschließen, daß auch die OS-Wahl eine kleine Rolle gespielt hat.

Die Grenze für die o.g. Konfiguration dürfte wohl bei etwa 300 gleichzeitig zugreifenden Usern sein. Oberhalb dieses Wertes käme eine Trennung von Apache und der DB infrage. Bemerkenswert sind Empfehlungen, für ein Forum dieses Kalibers Dual-CPUs, schnelle SCSI-Platten und mindestens 2GB RAM einzuplanen. Das ist definitiv nicht erforderlich.

Gruß, ww
 
Moin,

so ähnlich ist es hier ja auch - BSDForen.de läuft ja auch auf recht betagter Hardware.

- Celeron 1300 Mhz
- 1 GB RAM
- 2x80GB HDDs im RAID1

Die einzelnen Dienste wie Apache, MySQL und Postfix laufen in Jails.

Und für die alte Hardware ist das Forum imho immer noch ziemlich flott - die Load liegt in diesem Moment (318 Active Users laut vBulletin) bei 1,07, 0,80, 0,65 ;)

Gruß
 
das zweitgrößtes Politikforum in Deutschland, zu erreichen unter www.politikforen.de
hab ich mir mal angeguckt.... ist ja sehr anstrengend... wer macht da mit? da kommt doch nix inhaltvolles rum, die einen brüllen revolution und die anderen würden gerne hartz4ler in arbeitslager schicken...
aber ich glaube darauf wolltest du garncht hinaus ;)
 
Nein, nein, das sollte keine Werbung sein. Ich fand es einfach erwähnenswert, wie schmerzlos die Migration eines humpelnden SuSE-based Forums auf FBSD mit relativ schwachbrüstiger Hardware darunter lief.

Gruß,
ww
 
Ich finds klasse! :D
Das ganze beweist wie langsam und resourcenverschwendend (u.a.) aktuelle SuSE Versionen sind.
 
Zuletzt bearbeitet:
Hast du denn auch den Apache22 genommen? 20 is ja nicht stable... :-)
 
Interessante Sache. Ich bin grad dabei, meinen extrem schwachbrüstigen Heimserver von Linux auf *BSD umzustellen und erwarte nun ebenfalls eine deutliche Leistungssteigerung.

Nein, aber ehrlich, ich denke auch, dass Suse da seinen Teil dazu beiträgt.

I.MC schrieb:
Hast du denn auch den Apache22 genommen? 20 is ja nicht stable... :-)

Selbe Frage.
 
Hallo,

es ist mir neu, daß 2.0.54 nicht stable wäre. Wie auch immer: Ich nutze diese Version (wie auch den 1.3-Zweig) auf verschiedenen Servern, habe keinerlei Stabilitätsprobleme feststellen können und hatte keine Lust, die neue Version zu testen.

Deshalb habe ich auf Bekanntes zurückgegriffen.
 
Von apache.org

"The Apache HTTP Server Project is proud to announce the release of version 2.2.2 of the Apache HTTP Server ("Apache"). This version of Apache is a major release and the start of a new stable branch, and represents the best available version of Apache HTTP Server."

"The Apache HTTP Server Project is proud to announce the legacy release of version 2.0.58 of the Apache HTTP Server ("Apache")."

Na ok, es heisst nicht, dass 2.0 nicht mehr unterstützt wird.

Gruß, I.MC
 
Na, ich bin etwas konservativ. Was der Bauer nicht kennt...

Irgendwann werde ich bestimmt zu 2.2 wechseln; im Moment sehe ich keinen Sinn.
 
Mehr ordung in mit den Modulen und den zugehörigen Configs ;)

Ich weis das sollte kein Grund sein, ist aber doch so schon übersichtlich :D
 
Ich meine erst letzte Woche gelesen zu haben (sorry, keine Quellen, ich meine ja nur), dass im Produktiveinsatz nach wie vor 1.3.x empfohlen wird. Aber sei's drum. Wenns denn läuft ist doch gut :)
 
Hallo rolle,

die angezeigte Zeitzone kann im Usermenü eingestellt werden, weil es etliche außereuropäische User gibt (USA, Neuseeland). Der Server selbst holt sich jede Nacht die akurate Zeit von einem der vielen Timeserver.

Aktuell sagt date: Wed May 3 10:32:08 CEST 2006

Folglich ist die falsche Zeit ein Problem der Forumssoftware.

Gruß, ww
 
Hallo ww,

diese "Auffälligkeiten" können wir bei Kunden durchaus nachvollziehen. Gerade Mittelständler sind dankbar, wenn die Hardware- und Stromkosten bedingt durch SMP-Maschinen nicht explodieren und sie bei Uni-CPU-Rechnern bleiben können.
Oft haben die Benutzer dieser Serversysteme erfreut festgestellt, dass das gesamte Netz nach einer Umstellung auf FreeBSD bei gleicher Hardware merklich schneller geworden ist.
Aber wir haben auch festgestellt, dass die PostgreSQL-Performance unter FBSD 5.4 nicht so hoch ist wie unter Redhat. Dafür ist unter FBSD 6.1 aber dann die Performance doch erheblich besser (vielleicht liegt es auch am selbst entwickelten LSI-Treiber).

Viele Grüße

Jürgen
 
Ich habe mich im Vorfeld ja mit dem Stromverbrauch von CPUs beschäftigt und bin entsetzt, was manche Modelle raushauen. 100 Watt sind ja für manche Modelle nichts.

In der Folge braucht man dann ein dickeres Netzteil und eine bessere Kühlung. Cleverer ist es, sich möglichst etwas zu bescheiden und da ist der XP 1800+ mit Thoroughbredkern im Verhältnis zu seiner Leistung sehr gut (51W).
 
Wirklich gut sind die Winchester Athlon64. Selbst unter voller Last ziehen die selten über 40W, idle dank Cool n' Quiet (soweit man das auf Servern nutzen will) deutlich weniger.
 
Die Angaben zum Takten sind mit Vorsicht zu genießen. Nicht alles was dort steht ist korrekt.
 
Kleine Frage: Wie sieht es mit der Performance von MySQL aus?

Es heißt, MySQL liefe auf BSD-artigen Unixen im Vergleich zu Li-
nux sehr langsam, weil es intensiven Gebrauch von Linux-Ker-
nel-Threads macht......
 
Aber unter BSD werden die Linux-Kernel-Threads doch nicht langsamer verarbeitet als unter Linux native.
 
MySQL läuft teilweise deutlich langsamer unter !Linux als unter Linux. Das hat haufenweise Gründe und keiner weiss ganz genau warum. Sicher ist nur, das MySQL AB heftigst auf Linux optimiert. Es ist auch nicht unbedingt sinnvoll jeden Linux-Performance-Hack zu übernehmen, nur damit wir gleich schnell sind. *BSD hat ja auch andere Vorteile. Außerdem, wer wirklich den letzten Rest an Performance braucht kauft sich einfach schnellere Hardware :)
 
Ich bin mit der Performance auf diesem Server eigentlich ganz zufrieden und denke nicht, daß MySQL ein Bottleneck darstellt. Allerdings ist vbulletin alles andere als schlank.

Sollten die Anforderungen steigen, würde ich wohl DB und Apache auf getrennten Maschinen laufen lassen.
 
Sorry Kamikaze, aber der Beitrag hättest Du dir auch schenken können.

a: kann MySQL, was die vielen typischen connect/disconnects bei WebApp angeht, deutlich schneller sein.
b: kann man es sich nicht immer aussuchen.
c: ging es hier nicht um den Vergleich MySQL vs. PgSQL

PgSQL kann einiges was MySQL nicht kann (zb. Trigger functions). Aber MySQL hat auch seine stärken (min. ab 4.1).

Allerdings glaube ich auch, wenn es hart auf hart kommt, das MySQL der Flaschenhals sein wird (PgSQL übrigens ebenfalls), aber dafür muss meiner Erfahrung nach schon ganz schön was abgehen.
Ausserdem ist die Frage ob bei wirklich extremen zugriffsspitzen ein DB-Server reicht.

Pauschal ohne zu wissen was das für eine App. ist, mit was für Hardware und welchen Zugriffszeiten, ist das alles sehr theoretisch und kaum zu beantworten ;)
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben