Serverneustart 27.10.2004 07:00 Uhr

[feltel]

Ich werde morgen früh gegen 07:00 Uhr unseren Rootserver mal neustarten müssen. Wie ihr sicherlich alle schon bemerkt habt geht es die letzten paar Tage machmal nur sehr sehr sehr schleppend voran auf debianforum.de. Während das passiert hat unser Rootie zeitweise einen Load von 60 und MySQL & Co. laufen Amok. Alles deutet auf eine Speicherkorruption hin, so das die Apache- und MySQL-Prozesse sterben und dauern neue Prozesse erzeugt werden, so daß der Rootie mächtig anfängt zu swappen.

Eventuell lassen sich die Probleme durch einen Reboot (nach 250 Tagen Uptime) beheben.

[C_A]

Kommt bei der Gelegenheit dann ein neuer Kernel(2.6er ?)drauf?
Wenn ich richtig nachgelesen habe läuft der Rootie zur Zeit auf 2.4.25.

[pierre]

Mal so als Frage: Gibt es einen Grund dafür, dass diese so oft sterben? Kann das mit dem Speicherverbrauch ja verstehen, aber warum kratzen die Prozesse uns so einfach ab? Das wir ab-und-zu schleppende Loads haten, haben wir (also jedenfalls ich) mitbekommen. Dachte schon mein ISDN wäre kaputt oder jemand hat sich an meinen Jabberserver rangewagt.

[feltel]

So, der Rootie ist neu gestartet. Schauen wir mal, wie er sich so die nächten Tage verhält.

Kommt bei der Gelegenheit dann ein neuer Kernel(2.6er ?)drauf?
Wenn ich richtig nachgelesen habe läuft der Rootie zur Zeit auf 2.4.25.

Nein, da kommt kein 2.6er drauf. Warum auch, da der 2.4er (abgesehen von den Load-Problemen, die nicht unbedingt was mit dem Kernel zu tun haben müssen) ohne Probleme läuft. Außerdem wäre mir ein Wechsel 2.4 > 2.6 ohne direkt an der Maschine zu sein zu heiß. Dafür änderte sich viel zu viel zwischen den zwei Kernelgenerationen als das ich ruhigen Gewissens so nen Wechsel nur mit ner SSH-Verbindung machen würde.

[floschi]

Ich kenne eure Konfig nicht, aber bei uns hat damals die Trennung von Web- und Datenbankserver einiges geholfen - der DB-Server ist bei höherer Last mit sowenig RAM eben etwas gefräsig, sofern noch Web, Mail, DNS usw. dazu kommen

[feltel]

Hmm, das wär ne Lösung um den Load auf zwei Maschinen zu verteilen, obwohl ich mir nicht gerade vorstellen kann das das der Gesamtperformance zuträglich wäre. Damit baut man sich ja nen neuen Flaschenhals, nämlich die maximal 100MBit schnelle Verbindung Webserver -> DB-Server. Wenn alles auf einer Maschine läuft dann geht das ja über nen Socket, und das ist sicherlich schneller als 100MBit.

[floschi]

Naja, die Datenbankanfragen sind ja nicht wirklich viel Traffik und bei einem 2.Server im gleichen RZ ist das wirklich im Rahmen, unserer Erfahrung nach zumindest.

[feltel]

Dank Dir für den Tipp. Wie werden das die nächsten Tage mal beobachten, wie der Server sich so verhält. Falls es nicht besser wird werden wir was unternehmen müssen. Ob das ein größerer Server wird, ein zweiter dedizierter DB-Server oder was auch immer können wir ja dann von Fall zu Fall entscheiden. Blöderweise rüstet 1&1 die Rooties nicht gegen ne Gebühr mit mehr RAM auf, denn das würde uns auf jeden Fall ein Stückchen helfen.

[Tomek]

Hmm. Klar, das Hauptproblem sind die 256 MB RAM. Ich weiss, dass 1&1 offiziell keine Änderungen an der Hardware vornimmt, aber vielleicht würde ein netter Anruf bei 1&1 etwas bringen. Versuchen kann man es mal denk ich.

Zum Kernel 2.6: Ich würde auf jeden Fall einen Kernel 2.6 versuchen. Der neue Scheduler, das neue Memory Management, verbesserte IO-Leistung etc. könnten ein paar Prozent oder mehr an Leistung bringen. Wenn man den Kernel 2.6 richtig kompiliert und im Bootloader installiert, dann startet die Kiste auch wieder. Wenn nicht, gibt es immernoch das Rettungssystem.

Welche MySQL-Version läuft denn hier? Wenns eine 3.23 ist, dann würde ich schnellstens auf MySQL 4 upgraden. Denn ab MySQL 4 gibt es viele interessante Dinge, wie z.B. Query-Cache, die die Datenbankperformance deutlich erhöhen. Des Weiteren würde ich die persistenten Verbindungen von PHP zum MySQL-Server deaktivieren, falls diese aktiviert sind (ist standardmässig der Fall).

Vielleicht kann man noch andere Apache- und MySQL-Parametern verbessern. Aber dazu müsste man natürlich einen Blick in die Konfigurationen der Dienste werfen können.

EDIT: Turck MMCache für PHP läuft ja immernoch oder? Das verringert die ja Last erheblich.

EDIT #2: Ist GZIP-Kompression im phpBB aktiviert? Wenn ja würde ich das abschalten. Kommt natürlich auch drauf an, in wie weit ihr noch Trafficreserven habt.

[Tomek]

Falscher Knopf. Ein Post zuviel..

[feltel]

Hmm. Klar, das Hauptproblem sind die 256 MB RAM. Ich weiss, dass 1&1 offiziell keine Änderungen an der Hardware vornimmt, aber vielleicht würde ein netter Anruf bei 1&1 etwas bringen. Versuchen kann man es mal denk ich.

Mal sehen, ob ich was erreiche.

Zum Kernel 2.6: Ich würde auf jeden Fall einen Kernel 2.6 versuchen. Der neue Scheduler, das neue Memory Management, verbesserte IO-Leistung etc. könnten ein paar Prozent oder mehr an Leistung bringen. Wenn man den Kernel 2.6 richtig kompiliert und im Bootloader installiert, dann startet die Kiste auch wieder. Wenn nicht, gibt es immernoch das Rettungssystem.

Nenn mich konservativ aber bei Servern setzt ich immernoch auf Kernel 2.4. Dafür ändert sich bei 2.6 immernoch zuviel zwischen den Releases.

Welche MySQL-Version läuft denn hier? Wenns eine 3.23 ist, dann würde ich schnellstens auf MySQL 4 upgraden. Denn ab MySQL 4 gibt es viele interessante Dinge, wie z.B. Query-Cache, die die Datenbankperformance deutlich erhöhen. Des Weiteren würde ich die persistenten Verbindungen von PHP zum MySQL-Server deaktivieren, falls diese aktiviert sind (ist standardmässig der Fall).

Auf dem Rechner läuft ne Woody-Installation, und daran würde ich ungern was verändern wollen. Ich hab immer so meine Bedenken Backports auf Produktivservern einzusetzen, vorallem wenn nicht klar ist, ob und wieoft dann Security-Fixes bereitgestellt werden.

EDIT: Turck MMCache für PHP läuft ja immernoch oder? Das verringert die ja Last erheblich.

Ja, der läuft

EDIT #2: Ist GZIP-Kompression im phpBB aktiviert? Wenn ja würde ich das abschalten. Kommt natürlich auch drauf an, in wie weit ihr noch Trafficreserven habt.

An GZip abschalten hab ich auch schon gedacht, ich werd das mal durchkalkulieren ob und wieweit wir da mit unserem Traffic hinkommen.

Eine andere Möglichkeit mehr Performance (und weniger Serverbelastung) zu erreichen ist sicherlich http://www.phpbb.com/phpBB/viewtopic.php?t=135383. Ich wers mir mal zu Gemüte führen.

[floschi]

Ich würde dir auch keinen 2.6er Kernel empfehlen - ist nunmal noch kein Serverkernel und die Optimierungen sind für diese Standardrechner sowas von egal.

Aber in Sachen MySQL ist es evtl. eine Überlegung wert, da hat bei uns ein Upgrade auf 4 einiges gebracht (wobei der DB-Server unter LFS läuft und damit sowieso kein Paketmanagement vorhanden ist).

[feltel]

Aber in Sachen MySQL ist es evtl. eine Überlegung wert, da hat bei uns ein Upgrade auf 4 einiges gebracht (wobei der DB-Server unter LFS läuft und damit sowieso kein Paketmanagement vorhanden ist).

Überredet
Ich werd zumindest mal meinen Testrechner mit Woody und nem MySQL4-Backport quälen.

[gucki]

Des Weiteren würde ich die persistenten Verbindungen von PHP zum MySQL-Server deaktivieren, falls diese aktiviert sind (ist standardmässig der Fall).

Dachte immer persistente Verbindungen wären schneller.... Kann mich da jemand aufklären?

[feltel]

Des Weiteren würde ich die persistenten Verbindungen von PHP zum MySQL-Server deaktivieren, falls diese aktiviert sind (ist standardmässig der Fall).

Dachte immer persistente Verbindungen wären schneller.... Kann mich da jemand aufklären?

Da wäre ich auch der Meinung, obwohl ich es nicht mit Zahlen belegen kann. Wenn ich mysql_connect (statt mysql_pconnect) für ne dynamsiche Seite benutze, würde das ja bedeuten das quasi für jeden einzelnen Seitenaufruf die Verbindung zum SQL-Server hergestellt werden muss, was natürlcih Zeit kostet.

[Tomek]

Ich persönlich habe mittlerweile überall Kernel 2.6 drauf und ich habe noch keine schlechten Erfahrungen gemacht. Im Gegenteil, nur gute. Da das Forum nun an die Grenzen des Servers gestoßen ist und auch mal drüber, kannt man nicht konservativ bleiben. Du musst meiner Meinung nach versuchen mit vorhandenen Mitteln die Hardware besser auszunutzen.

Ein Upgrade auf MySQL 4 ist imho Pflicht. Das wird die Performance am spürbarsten erhöhen und die Last senken. Sicherheitsprobleme tauchen bei MySQL 4 eher selten auf. Und backports.org stellen auch Sicherheitsupdates bereit.

Wie gesagt, ich weiss nicht wie es mit Traffic bei Euch aussieht, aber die GZIP-Kompression erhöht deutlich die CPU-Last, was Ihr im Moment überhaupt nicht gebrauchen könnt.

Das Thema persistente Verbindungen bei MySQL und PHP ist häufig diskutiert worden, mit dem Resultat dass sie speziell für Foren nur Nachteile bringen. Zudem blockieren persistente Verbindungen die Datenbank. SIehe dazu z.B. das hier:
http://www.mysql.com/news-and-events/ne ... 00086.html und http://www.vbulletin.com/forum/showthre ... tent+mysql

[feltel]

Ich persönlich habe mittlerweile überall Kernel 2.6 drauf und ich habe noch keine schlechten Erfahrungen gemacht. Im Gegenteil, nur gute. Da das Forum nun an die Grenzen des Servers gestoßen ist und auch mal drüber, kannt man nicht konservativ bleiben. Du musst meiner Meinung nach versuchen mit vorhandenen Mitteln die Hardware besser auszunutzen.

Das machen wir ja auch, nur wollen und sollten wir nicht in Aktionismus ausarten. Solche Geschichten wollen wohl überlegt sein, da es ggf. keinen Weg zurück gibt. Ich denke nicht, das ein Wechsel von 2.4 auf 2.6 einen so gravierenden Vorteil bringt. Hab vor ner Weile mal ne Testmaschine sowohl unter 2.4.25 als auch unter 2.6.7 am laufen gehabt und es gab da keine Unterschiede in der Performance.

Ein Upgrade auf MySQL 4 ist imho Pflicht. Das wird die Performance am spürbarsten erhöhen und die Last senken. Sicherheitsprobleme tauchen bei MySQL 4 eher selten auf. Und backports.org stellen auch Sicherheitsupdates bereit.

Ich hab mir mal die Depencies von mysql auf backports.org angeschaut und damit könnte ich leben. Es will nur ne aktuellere debconf-Version haben, die aber zum Glück nicht von weiteren Backports abhängt. Manchmal ist man ja bei solchen Backports gewungen nen Sack voll anderer Pakete (und vorallendingen libs) mit upzudaten, wenn man den Backport nutzen will.

Wie gesagt, ich weiss nicht wie es mit Traffic bei Euch aussieht, aber die GZIP-Kompression erhöht deutlich die CPU-Last, was Ihr im Moment überhaupt nicht gebrauchen könnt.

Momentan brauchen wir so um die 35 GB pro Monat. Uns stehen 50 GB Frei-Traffic zur Verfügung. Ich glaube nicht, das GZip so schlecht arbeiten würde, so das wir bei Abschaltung von GZip unter den 50 GB Traffic bleiben würden. Ich werd aber mal testweise für einen Tag GZip ausschalten und das dann mal Trafficmäßig vergleichen.

Das Thema persistente Verbindungen bei MySQL und PHP ist häufig diskutiert worden, mit dem Resultat dass sie speziell für Foren nur Nachteile bringen. Zudem blockieren persistente Verbindungen die Datenbank. SIehe dazu z.B. das hier:
http://www.mysql.com/news-and-events/ne ... 00086.html und http://www.vbulletin.com/forum/showthre ... tent+mysql

Hmm, was ist nun die beste Lösung? Der eine sagt Persistente Connections an, der andere sagt Off.

[Tomek]

Das machen wir ja auch, nur wollen und sollten wir nicht in Aktionismus ausarten. Solche Geschichten wollen wohl überlegt sein, da es ggf. keinen Weg zurück gibt. Ich denke nicht, das ein Wechsel von 2.4 auf 2.6 einen so gravierenden Vorteil bringt. Hab vor ner Weile mal ne Testmaschine sowohl unter 2.4.25 als auch unter 2.6.7 am laufen gehabt und es gab da keine Unterschiede in der Performance.

Klar müssen solche Dinge gut überlegt sein. Jedoch sehe ich bei einem Upgrade auf Kernel 2.6 keine Gefahr, sondern potenziell mehr Leistung.

Ich hab mir mal die Depencies von mysql auf backports.org angeschaut und damit könnte ich leben. Es will nur ne aktuellere debconf-Version haben, die aber zum Glück nicht von weiteren Backports abhängt. Manchmal ist man ja bei solchen Backports gewungen nen Sack voll anderer Pakete (und vorallendingen libs) mit upzudaten, wenn man den Backport nutzen will.

Stimmt, das ist bei MySQL nicht der Fall. Allerdings wirst du nach dem MySQL-Upgrade, wenn du das PHP von Woody behalten willst, das Paket "libmysqlclient10" von Debian Woody installiert lassen bzw. installieren, da das PHP bei Woody gegen die MySQL 3.23 Libaries gelinkt ist.

Hmm, was ist nun die beste Lösung? Der eine sagt Persistente Connections an, der andere sagt Off.

Schalte sie ab.

[feltel]

Ich importier gerade mal spaßeshalber die dfde-Datenbank auf einen gerade zur Installation anstehenden Firmenrechner (P4/2800) und dabei bekomm ich

message from syslogd@skywalker at Thu Oct 28 13:02:48 2004 ...
skywalker kernel: CPU0: Temperature above threshold

Das DB-Dump-File ist kanpp ein halbes Gigabyte groß und der importiert schon knapp 15 Minuten.

Da da steht mir ja was bevor, wenn wir den DB-Server umstricken

[Tomek]

Hehe

Wenn du allerdings nur ein MySQL-Upgrade auf dem gleichen Server machst, brauchst du die Datenbank nicht neu zu importieren, sondern nur einmal das Tool mysql_fix_privilege_tables laufen lassen.

[gucki]

Momentan brauchen wir so um die 35 GB pro Monat. Uns stehen 50 GB Frei-Traffic zur Verfügung. Ich glaube nicht, das GZip so schlecht arbeiten würde, so das wir bei Abschaltung von GZip unter den 50 GB Traffic bleiben würden. Ich werd aber mal testweise für einen Tag GZip ausschalten und das dann mal Trafficmäßig vergleichen.

also ich hab das mal bei typo3 verglichen (das Ding schmeisst beide Größen zu Testzwecken raus. waren 8k (ohne GZIP) und 2.3k. Also auf eure Verhältnisse kannst du plötzlich VIEL MEHR Traffic haben, mehr als die 50GB denk ich mal. dfde ist ja auch zeimlich textlastig (was ich gut finde).

[Joghurt]

GZIP mindert doch nur den Traffic beim Backup der Datenbank, oder nicht?

Könntet ihr in diesem Falle nicht einfach die Datenbank per SSH-Tunnel sichern und dabei die GZip-Kompression von SSH nutzen?

[feltel]

Wir nutzen hier Gzip in Form des Pakets libapache-mod-gzip auch zur Komprimierung des Transfers zwischen Webserver und Browser. Die meisten Browser können das mitlerweile und somit bringen wir den Traffic und die Ladezeiten der Webseite drastisch nach unten.

[Joghurt]

Ah! OK.

[se8i]

Muß denn so dringend was gemacht werden?
Also speziell mit den Backports, jetzt wo sarge "so knapp vor dem release" steht.