Operation: Server-Upgrade

Ja, es war nötig sonst hätte ich es mir äußerst gerne gespart.

4 GB waren für das Base-System, die Webapplikation und die DB mit Abstand zu wenig für 8 Kerne. Das wussten wir damals nicht, aber jetzt sind wir umso schlauer. Die Anzahl der Verbindungen über den Apache und die DB sind zeitweise sehr hoch bei uns, bis zu 200 können es problemlos sein. Natürlich sind Bots wie zB von Google, die oc.at 24/7 durchkämmen, ebenfalls an diesen Verbindungen beteiligt, aber das macht unterm Strich keinen Unterschied, weil das muss funktionieren. Für zuviele Verbindungen gibt es zwei Strategien: Entweder man sperrt den Server ab einer gewissen Anzahl an Verbindungen ab - first come, first serve - oder man erhöht die Verbindungen solange, dass der Server swapped (Arbeitsspeicher auf die Disks auslagert); unabhängig von Caching-Methoden wie Varnish und lokalen Cache-Layern. Nummer 2 ist ganz allgemein der Weg, den man gehen sollte, weil besser langsam als gleich eine Fehlermeldung. Und wenn es dann zu oft langsam wird, was bei uns der Fall war, dann muss entweder die Software optimiert werden (zB Verlagerung von [mehr] Requests auf einen Varnish, am besten über eine F5 innerhalb der lokalen Infrastruktur) oder ein Hardware-Upgrade wird nötig.

Einer der Hauptgründe, die momentan noch gegen einen Varnish sprechen (außer den Kosten), beruht auf der Tatsache, dass doch anders als bei irgendwelchen Tageszeitungen sehr viel Load von eingeloggten Usern kommt. Dieser individuelle Traffic ist deutlich schwieriger zu Cachen. Obendrein hatten wir schon eine ganze Weile das Problem, dass MySQL nicht ausreichend optimiert werden konnte, weil wir nicht genügend Speicher für den Query-Cache bereitstellen konnten. Dadurch habe ich schon länger mit einem RAM-Upgrade geliebäugelt.

Natürlich gibt es durch den größeren RAM auch einige Vorteile für die Webapplikation: Wer zB viele Private Messages hat (so wie ich), der muss nicht mehr bis zu 5 Sekunden warten, um sie aufzulisten. Dank größerem Sort-Buffer fluscht das jetzt ohne Probleme. Außerdem haben wir jetzt viel Potenzial für memcached-Implementierungen, die ich gerne machen würde, um die DB zusätzlich zu entlasten (wir haben sehr viele Single-Queries ... ok, prepared Statements wäre auch ganz nett ).

Last but not least war ausschlaggebend, dass ich zwei relativ günstige Opteron 6276 auf egay gefunden habe, denen ich einfach nicht widerstehen konnte. Dadurch mussten der RAM ohnehin neu dimensioniert werden, weil für 32 Cores jeder Core entsprechend mit RAM bedacht werden muss inklusive Base-System und Datenbank mit Query-Caching.

Also hätten wir ganz prinzipiell nur 8 oder vielleicht 16 GB mit 8 Kernen benötigt. Bei 32 Kernen hätte ich schon zu 32 GB tendiert. Wie ist es dann zu den 64 GB gekommen? Tja, wir haben das intern diskutiert und dann hat sich ein Engel gemeldet, dem wir jetzt das RAM-Wonderland zu verdanken haben.

Unterm Strich war als zuviel Motivation und noch mehr Glück an diesem Upgrade beteiligt. Und das OS hätten wir natürlich sowieso updaten müssen, wir waren noch auf Ubuntu Server 10.04 LTS.

Zitat von xtrm

Du meinst wohl, er DARF in den Genuss kommen, mit einem CRT zu arbeiten.

darf? achso, macht man sowas heutzutage schon über's smartphone? :scnr:

@mat:
Ich will euch ja nicht zu nahe treten aber heutzutage noch Sort_buffer? Ist es nicht auch in eurem Fall besser ordentliche Indices zu verwenden? Benutzt Ihr noch MyISAM oder ist alles InnoDB.

Wenn ihr bei den Indices/Querys hilfe benötigt, schicke mir doch einfach mal die Langsamen Querys und die Struktur der beteiligten Tabellen. dann können wir sehen ob man da etwas optimieren kann.

Die Mysql/MariaDB Datenbanken die ich betreue müssen auch mal über 10000 Connections vertragen. Ram steht da nicht mehr als bei euch zur Verfügung und ich habe momentan 12 Cores dafür.

Alles MyISAM, wieso auch nicht. oc.at verwendet keine Features, die für InnoDB sprechen. Bezüglich Sort-Buffer: Ich habe in den letzten Jahren versucht, überall entsprechend zu indizieren, um Sorting und Grouping ohne Index zu vermeiden. Ich hab sicher nicht alles erwischt, aber die wichtigen und langsamen Queries sind gefixt. Ja, Sort-Buffer macht mit Index wenig Sinn und es ist ungefähr das Letzte, was ich an der Config mache. Ist wahrscheinlich eher Gewohnheit, dass ich es mache. Allgemein befasse ich mich aber nur mehr wenig mit Per-Session-Values.

Selbstverständlich kann man noch das ein oder andere Query optimieren, man müsste halt weit mehr Zeit investieren als bei zB einem zusätzlichen memcached-Layer, der deutlich mehr bringen würde. Aktuell ist das Slow-Query-Log aus. Ich glaub auch nicht, dass da noch etwas Gröberes angezeigt wird, aber ich kanns ja versuchen.

Von dir kam oben die Frage bezüglich MySQL 5.7, richtig? Wir verwenden ausschließlich Versionen, die das OS offiziell unterstützt. Alles andere halte ich für unnötig, weil die Wartung erschwert wird.

So Aussagen wie deine 10000 Connections kenne ich gut, darauf stößt man immer wieder in meiner Position als Devop. Nichts für ungut, aber ohne dem Kontext der Infrastruktur, der Codebase und der verwendeten Queries ist die Aussage irrelevant.

Danke jedenfalls für deine Hilfe, ich komme bei Bedarf gerne darauf zurück.

Zitat von murcielago

muss jedes mal wenn ich mich einloggen will vorher die delete_cookies.php aufrufen und werde dann automatisch eingeloggt. wenn ich den browser (chrome, neueste version, win7) schließe und wieder auf oc.at surfe, muss ich mich wieder einloggen. das funktioniert aber nicht, ich muss dann wieder delete_cookies.php aufrufen und werde DANN wieder automatisch eingeloggt

help?

Nach dem löschen der cookies besteht nun dieses Problem bei mir.

Hm... hat eventuell was mit dem private browsing vom Firefox zu tun?


/edit
Tatsächlich. Das Problem besteht ausschließlich unter "private browsing".

/edit2
Na do ned.
Das Problem besteht nach wie vor. Egal ob oc.at irgendwelche Cookies gesetzt hat oder nicht?

Zitat von mat

Einer der Hauptgründe, die momentan noch gegen einen Varnish sprechen (außer den Kosten), [...]

Welche Kosten meinst du damit?

Klick auf die Anzahl der Posts neben einem Thread spuckt nicht mehr aus, wer wie oft gepostet hat