Serverneustart 27.10.2004 07:00 Uhr

[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.

[Tomek]

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

Ja schon, da das Forum akute Probleme mit der Performance hat. Zu dem will feltet sicherlich nicht ein komplettes Distributionsupdate fahren, das nichts in der Hinsicht verbessert.

[floschi]

Hehe, und noch einen Tick verrückter wäre als ein Kernelupdate von einem gut laufendem 2.4er auf einen 2.6er Entwicklungskernel (zumindest laut Torvalds)

[KBDCALLS]

Der Server Neustart scheint wohl nichts an den Performanceproblem geändert zu haben, Ca. 20 Min hat der Server ebend garnicht reagiert.
Selbst eine Neueinwahl des DSL hat nichts geholfen. Ne Lösung schon in Sicht.

[Maikel]

Bin mir nicht sicher obs das Posting hier Richtig ist, oder ob schon was dazu bekannt ist.
Aber ich habe seit einigen Tagen Probleme auf df.de zu kommen.
Ich kann, bzw der Rechner kann den Host nicht erreichen.
Selbiges Problem ist mir auch von anderen Usern bekannt.


Zeitlich passen diese Probleme in die Zeit der Serverumstellung. Daher poste ich hier...

[fluid]

Ich bin gerade eben auch für ca. 20 Minuten nicht auf die Seite gekommen, weder per https noch http. Auch

Code: Alles auswählen

telnet debianforum.de 80

ging in dieser Zeit nicht.

[C_A]

Ich bin zwar kurz auf die Seite gekommen, dies aber nur mit der Antwort: "critical error. Couldn't connect to database" o. ä.

[blackm]

Ja, wir hatten da ein kleines Problem (das einen Load von etwa 50 und knapp 700 Prozesse verursacht hat). Wir konnten es aber mit iptables loesen

by, Martin

[Athlux]

Ja, wir hatten da ein kleines Problem (das einen Load von etwa 50 und knapp 700 Prozesse verursacht hat). Wir konnten es aber mit iptables loesen

by, Martin

Ah es sind ja Ferien und die kleinen Kiddies haben nichts anders zu tun

[HorstV]

Ich bin zwar kurz auf die Seite gekommen, dies aber nur mit der Antwort: "critical error. Couldn't connect to database" o. ä.

Gleiches Phänomen bei mir heute zwischen 18:00 Uhr und 18:15 Uhr MEZ. Entweder ging garnichts oder obige Fehlermeldung.

Gruß Horst

[feltel]

Musste den Server leider vor rund 20 Minuten resetten, da der Load wieder mal auf über 30 angestiegen war und MySQL sich partout nicht beenden ließ.

[HorstV]

Ursachen?

[feltel]

Wir sind gerade dabei die verschiedenen Logs durchzuarbeiten, um mehr Informationen zu bekommen woran es lag. Es scheint aber so zu sein, das verschiedene Ereignisse zusammentreffen und dann den Load verursachen. Wie es scheint ist es kein einzelnes Ereigniss was zu dem Problem führt.

[KBDCALLS]

Schon ein Ergebnis?

[The Torso]

laut [1] gilt:

mysql_pconnect ist besser da die Verbindung nur einmal geöffnet wird und offen bleibt und somit wir das scriptt schneller

Auch wenn ich nicht genau verstehe wie das Funktioniert, aber ich beschäftig mich nur so privat seit ein paar monaten mit php und mysql.

[1] http://www.webmasterpro.de/content_tip-1379.php

[feltel]

Schon ein Ergebnis?

Noch nicht so richtig.

Eine Ursache ist (bzw. war) der stündliche mysqldump-Prozess (zur Vorbereitung des DB-Backups). Wir haben dies vorerst auf die Nachtstunden eingeschränkt. Eine weitere Ursache oder besser gesagt die Folge des mysqldunp waren MySQL-Queries, die bis zu 66 Sekunden liefen. Es waren hauptsächlich Suchabfragen wo der/die Suchenden dann während der Minute sicherlich mehrfach den Refresh-Button geklickt hat und damit eine neue Instanz der Suche gestartet hat.