Performance VM <-> Live-Server

Hallo zusammen,

ich arbeite gerade an einem größeren Projekt (>1.500.000 DS in einer Tabelle).
Es geht hier nicht um die richtige Erstellung von Indizes und Konfiguration des MySQL-Servers. Es geht eher darum, dass der Seitenaufruf auf meiner VM (Ubuntu 12.04-Server) eine Seite mit knapp 700 gefilterten Datensätzen in knapp 4 Sekunden aufruft und der LIVE-Server 8-9 Sekunden für die gleiche Abfrage benötigt.

Meine VM:
RAM: 1024MB
OS: Ubuntu-Server 12.04
HDD: 300GB (frei: 273GB)
CPU: Intel Core 2 Quad Q9400 2.66Ghz

LIVE-Server:
Wurde vom Kunden bereitgestellt und wir haben nur beschränkten Zugriff (nix root). Hier die Daten, die ich per SSH rausbekommen habe:
RAM: 4096MB
OS: Linux version 2.6.18-194.32.1.el5 (mockbuild [at] builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Wed Jan 5 17:52:25 EST 2011
HDD: 200GB (frei: 45GB)
CPU: Intel Xeon CPU 3.40GHz
uname -a: Linux web02 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

Da die MySQL-Server nahezu gleich konfiguriert sind, vermute ich, dass der Geschwindigkeitsverlust durch die grafische Oberfläche des LIVE-Servers entsteht. Ich hab mir zu Hause mal Ubuntu 12.04 mit GUI installiert und muss auch hier sagen, dass der LAMP-Server gefühlte 40% langsamer ist.

Kann das jemand bestätigen und vielleicht erklären oder mir Hinweise geben für die weitere Eingrenzung geben?

Stefan

froemken schrieb:

Hallo zusammen,
ich arbeite gerade an einem größeren Projekt (>1.500.000 DS in einer Tabelle).
Es geht hier nicht um die richtige Erstellung von Indizes und Konfiguration des MySQL-Servers. Es geht eher darum, dass der Seitenaufruf auf meiner VM (Ubuntu 12.04-Server) eine Seite mit knapp 700 gefilterten Datensätzen in knapp 4 Sekunden aufruft und der LIVE-Server 8-9 Sekunden für die gleiche Abfrage benötigt.

Zum Vergrößern anklicken....

Ohne Indizes und vernünftige Konfiguration des Bufferpools, des Query Cache, des Table Cache, der max. größe temporärer Tabellen und der max. Anzahl an gleichzeitig geöffneten Dateien brauchst mit Performance gar nicht erst anfangen, weil der DB- Server in kürzester Zeit anfängt zu swappen und noch stärker ausgebremmst wird.

Bedenke auch, dass es ein sehr großer Unterschied ist, ob der Server nur einen Query alleine abarbeitet oder wie der Live Server mehrer gleichzeitig verarbeiten muss.

froemken schrieb:

Meine VM:
RAM: 1024MB
OS: Ubuntu-Server 12.04
HDD: 300GB (frei: 273GB)
CPU: Intel Core 2 Quad Q9400 2.66Ghz

LIVE-Server:
Wurde vom Kunden bereitgestellt und wir haben nur beschränkten Zugriff (nix root). Hier die Daten, die ich per SSH rausbekommen habe:
RAM: 4096MB
OS: Linux version 2.6.18-194.32.1.el5 (mockbuild [at] builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Wed Jan 5 17:52:25 EST 2011
HDD: 200GB (frei: 45GB)
CPU: Intel Xeon CPU 3.40GHz
uname -a: Linux web02 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

Zum Vergrößern anklicken....

Bei 4 GB RAM einer gerammelt vollen Festplatte und fast keiner Konfiguration des DB-Servers kannst du keine Performance erwarten.
Du solltest froh sein, dass er die Daten schon nach 8-9 Sekunden da sind.

froemken schrieb:

Da die MySQL-Server nahezu gleich konfiguriert sind, vermute ich, dass der Geschwindigkeitsverlust durch die grafische Oberfläche des LIVE-Servers entsteht. Ich hab mir zu Hause mal Ubuntu 12.04 mit GUI installiert und muss auch hier sagen, dass der LAMP-Server gefühlte 40% langsamer ist.

Kann das jemand bestätigen und vielleicht erklären oder mir Hinweise geben für die weitere Eingrenzung geben?

Zum Vergrößern anklicken....

Also MySQL ist auf beiden Servern nahezu überhaupt nicht konfiguriert. Mal abgesehen davon, hat ein Desktop nichts auf einem Server verloren, Ausnahmen sind Terminalserver, weil sie für den eigentlichen Betrieb nicht zwingend erforderlich ist und so nur für unnötige zusätzliche Angriffspunkte sorgt. Weiterhin benötigt sie Resourcen (RAM,CPU etc.), die dem DB-Server und dem Webserver fehlen. Webserver und MySQL prügeln sich bei dir regelrecht um das bisschen RAM was sie bekommen können. Zur Info: Datenbankserver werden nicht ohne Grund RAM und I/O Säue genannt.

Das die Datenbank dir unter diesen Umständen in 8-9 Sekunden das Ergebniss liefert ist sehr sehr unwahrscheinlich.

Autsch...so war das nicht zu verstehen. Ich stimm Dir voll und ganz zu, dass ein unkonfigurierter Server bei dieser Datensammlung völlig blödsinnig ist. Was hat der MySQL-Server für key_buffer? 8MB? Allein die Indexdatei für diese Tabelle liegt bei 380MB. Da auch noch andere Tabellen vorhanden sind habe ich den Wert auf 512MB gesetzt. Hinzu kommen gefühlte weitere 20 Einstellungen bzgl. Querycache und Co. Ich hab für das TYPO3-System angefangen eine MySQL-Check-Extension zu programmieren, um den Server auf Performanceprobleme hin zu überprüfen. Sämtliche Queries habe ich mit SET profiling=1 durchgeackert. Dank indezes filesorts größtmöglichst vermieden.
Ich habe extra geschrieben, dass es hier nicht um die MySQL-Konfiguration geht, da diese bereits vorliegt und immer wieder nachkonfiguriert wurde über Wochen hinweg.

Was ich nicht verstehe ist der Hinweis auf die Festplatte. Wo ist denn da bitte 45GB freier Speicher "gerammelt voll"? Wenn 90% erreicht sind, wirds problematisch. So kenn ich das und bis dahin sind noch 25GB drin.

Man merkt, dass Du einen gesunden Serververstand hast. Desktop gehört nicht auf Server. Stimme ich Dir voll und ganz zu! Ich brauche irgendwas handfestes, um dem Kunden sagen zu können: "Hey...Desktop hat hier nix zu suchen". Wobei ich noch nicht mal 100%ig sagen kann, dass ein x-Server installiert ist. Hab nur so Verzeichnisse wie gdm und X11 im etc-Verzeichnis gefunden. Reicht das als Differenzierung zwischen Server und Desktop? Irgendwo hört auch mein Wissen auf.

"top" sagt mir, dass der "Server mit evtl. vorhandenem x-Server" mit 0.01 - 0.16 ausgelastet ist. Da fehlt es mir ein bisschen an Argumentationsgrundlage.

Stefan

froemken schrieb:

Autsch...so war das nicht zu verstehen. Ich stimm Dir voll und ganz zu, dass ein unkonfigurierter Server bei dieser Datensammlung völlig blödsinnig ist. Was hat der MySQL-Server für key_buffer? 8MB? Allein die Indexdatei für diese Tabelle liegt bei 380MB. Da auch noch andere Tabellen vorhanden sind habe ich den Wert auf 512MB gesetzt. Hinzu kommen gefühlte weitere 20 Einstellungen bzgl. Querycache und Co. Ich hab für das TYPO3-System angefangen eine MySQL-Check-Extension zu programmieren, um den Server auf Performanceprobleme hin zu überprüfen. Sämtliche Queries habe ich mit SET profiling=1 durchgeackert. Dank indezes filesorts größtmöglichst vermieden.

Zum Vergrößern anklicken....

Tipp:

Wichtige und sehr gute Auskunft der zu optimierenden Parameter gibt dir das Tool MySQL Tuner[/code]

Der Keybuffer sollte min. 75%-80% des verfügbaren physikalischen RAM´s sein, besser ist aber 80-85% und der Rest reicht dem OS. Aktiviere mal das Slow Querry Logfile. Dann hast du einen Überblick, welche Queries langsam sind. Die Verwendung von

Code:

SELECT DISTINCT

ist auch hilfreich. Vor allem nur so viele Daten selektieren, wie sie auch gebraucht werden.
Komplexe Abfragen kannst du als Stored Procedure in der Datenbank speichern. Vorteil: MySQL kennt die Abfrage bereits und kann sie weiter optimieren.
Verwende Views (Ansichten) für spezielle Abfragen.

Wenn du die falschen Spalten als Index verwendest bringt dir der Index rein gar nichts. Also überlegen, Knoten in die Hirnwindungen machen und dann die richtigen Spalten verwenden.

Nach einer Änderung der Konfiguration, z.B. vergrößern des Querycache, sollte der DB- Server min. 24 Std. laufen, dann kontrollieren und ggf. an anderen Schrauben drehen. Die Anzahl der MySQL Threads hat auch Einfluss auf die Performance. Wieviele Dateien max. gleichzeitig geöffnet sein können und die Shared Memory Konfiguration des Kernel wirken sich auch auf die Performance aus,

Die verwendete Engine spielt bei der Performance eine nicht zu unterschätzende Rolle. MyISAM kann z.B. keine Foreign Keys. Für richtige Primary/Foreign Key Relationen ist InnoDB die bessere Wahl. Die Anzahl der Verbindungen sind auf ein minimum zu reduzieren, weil sie nicht gearde wenig Resourcen benötigen.

Wenn die nur Lesenden Abfragen höhere Priorität als Inserts, dann empfiehlt es sich verzögerte Inserts zu verwenden. Dann bremsen die damit verbundenen Locks auf den Tabellen nicht ganz so stark.

froemken schrieb:

Ich habe extra geschrieben, dass es hier nicht um die MySQL-Konfiguration geht, da diese bereits vorliegt und immer wieder nachkonfiguriert wurde über Wochen hinweg.
[/code]

Performance fängt bei der Installation an und hört erst dann auf, wenn der Server in Rente geht. Also ein paar Jährchen.

froemken schrieb:

Was ich nicht verstehe ist der Hinweis auf die Festplatte. Wo ist denn da bitte 45GB freier Speicher "gerammelt voll"? Wenn 90% erreicht sind, wirds problematisch. So kenn ich das und bis dahin sind noch 25GB drin.

Zum Vergrößern anklicken....

Je mehr Daten auf einer Festplatte sind, desto höher ist auch die Datendichte und der Aufwand für die Schreib- Leseköpfe der. Die Wahl des richtigen Dateisystems und der Mountoptionen spielt ebenfalls eine wichtige Rolle. Die Mountoptionen sollten min.

Code:

noatime, nobarriers

enthalten.

Prüfe mal mit dem Tool iops, wie hoch oder niedrig die Lesegeschwindigkeit ist. iops verwendet dabei unterschiedliche Blockgrößen .

Viel wichtiger ist aber vorher die richtigen Platten zu wählen. Wichtige Faktoren sind die SEEK TIME (Zeit die die Schreib-Leseköpfe benötigen bis sie positioniert sind), IOPS (I/O Operations pro Sekunde), die mittlere Zugriffsgeschwindigkeit und die Größe des Plattencaches.
So viele Platten wie möglich in einem RAID 10 zusammenfassen. Beispiel:

/dev/sda - /dev/sdf bilden ein RAID 10. /dev/sdh- /dev/sdm bilden ein weiteres RAID 10. Das Dateisystem ist dann in Punkto Blöckgröße und Stripe size an die des RAID ausgerichtet.

Die DB- Spaces müssen vernünftig über so viele Platten wie mögl. verteilt sein und idealerweise mehrere Spindeln des Controllers nutzen.

froemken schrieb:

Man merkt, dass Du einen gesunden Serververstand hast. Desktop gehört nicht auf Server. Stimme ich Dir voll und ganz zu! Ich brauche irgendwas handfestes, um dem Kunden sagen zu können: "Hey...Desktop hat hier nix zu suchen". Wobei ich noch nicht mal 100%ig sagen kann, dass ein x-Server installiert ist. Hab nur so Verzeichnisse wie gdm und X11 im etc-Verzeichnis gefunden. Reicht das als Differenzierung zwischen Server und Desktop? Irgendwo hört auch mein Wissen auf.

"top" sagt mir, dass der "Server mit evtl. vorhandenem x-Server" mit 0.01 - 0.16 ausgelastet ist. Da fehlt es mir ein bisschen an Argumentationsgrundlage.

Zum Vergrößern anklicken....

Zum Vergrößern anklicken....

Zum einen bietet der Desktop zusätzliches Angriffsflächen, was mit der wichtigste Grund ist und zum anderen fehlt die CPU- Zeit und der belegte RAM an den wichtigen Stellen, nämlich bei MySQL. Bei Ausreden, z.B. MySQL Workbench o.ä. braucht eine GUI, kein Problem, wird auf einem separatem Desktoprechner installiert und die Verbindung zur Datenbank erfolgt durch einen SSH- Tunnel.


Tipp: Gute Tools zum Monitoring

sysstat, latencytop, dstat, vmstat,blktrace

Sehr hohe Anzahl d. Contextswitche: Die CPU ist ständig am switchen und mögl. überlastet.
Sehr hohe Pageouts deuten darauf hin: Mehr RAM muss her.
Beides u. einiges mehr kannst du unter /proc/vmstat nachlesen.