![[HaBo]](/styles/default/logoklein.png){kind=small}
mysql / apache konfigurieren
- Themenstarter skymuss
- Beginndatum
bitmuncher
Senior-Nerd
Bevor man nichts genaueres zu deiner Webapplikation weiss, wären Optimierungstipps lediglich reine Spekulationen und insofern mit hoher Wahrscheinlichkeit sinnlos. Ein Admin stellt sich daher folgende Fragen, bevor er anfängt die Server für eine Webapplikation zu optimieren:
Apache:
- Welche Sprachen werden in der Webapplikation verwendet?
- Wieviele Requests pro Minute hast du im Durchschnitt?
- Wie gross sind die Requestschwankungen in Zeiträumen von 5 Minuten, einer Stunde und einem Tag?
- Wie sehen die VHost-Einstellungen aus?
- Welcher Apache-Worker ist im Einsatz?
- Welche Last hat der Server im Durchschnitt und maximal?
- Welche Hardware wird am meisten belastet (CPU, RAM oder Festplatte)?
- Benutzt die Webapplikation Memcaching? Wenn ja wofür und in welchem Umfang? Wenn nein, warum nicht?
Bei Verwendung von PHP:
- Welche Erweiterungen sind in PHP?
- Wird eaccelerator verwendet?
- Wie lange braucht das rechenintensivste Skript vom Request bis zur Auslieferung?
- Wieviel RAM verbraucht das speicherintensivste Skript?
MySQL:
- Wie gross ist der grösste Tabellen-Index?
- Wie gross sind alle Tabellen-Indizes zusammen?
- Welchen Datenzuwachs hast du am Tag?
- Welcher Tabellentyp wird verwendet und warum?
- Wie sieht der Output von 'SHOW VARIABLES' aus?
- Sind Techniken wie Replikation oder Clustering im Einsatz? (Deiner Konfiguration nach würde ich auf nein tippen)
- Wieviele Queries gibt es im Durchschnitt pro Sekunde sowie maximal und minimal am Tag?
- Welche Slow-Queries gibt es? (slow-query-logging aktivieren)
- In welchem Umfang wird Logging benötigt (bei einem VServer oder Rootserver sollte man jedes Query loggen um bei einem erfolgreichen Angriff nachvollziehen zu können was der Angreifer getan hat, kann aber zumeist auf Debug-Logging verzichten)?
Das wäre erstmal nur die wichtigsten Fragen, die beantwortet werden müssen um irgendwas zur Optimierung sagen zu können. Wenn du keine Ahnung von der Materie hast, solltest du dir daher einen Profi dazuholen, der sich diese Daten mit Statistik-Tools wie Webalizer, apachetop u.a. selbst sammeln kann. Momentan handelt es sich jedenfalls bei deinen Server-Einstellungen um die Ubuntu-Standards, die in grossen Umgebungen alles andere als brauchbar sind. Ausserdem eignet sich ein VServer nicht unbedingt für grosse Webapplikationen, da die CPU-Leistung mit anderen VServern geteilt werden muss. Die Analyse von Performance-Daten ist damit sehr schwierig bis unmöglich, sofern man nicht gerade einen eigenen CPU-Kern oder eine eigene CPU für seinen VServer verfügbar hat. Auch die Schwankungen des verfügbaren RAMs können (und werden) bei wachsender Request-Zahl zu Problemen führen, gerade wenn der Prefork-Worker im Einsatz ist, den ich in grossen Umgebungen empfehlen würde.
Apache:
- Welche Sprachen werden in der Webapplikation verwendet?
- Wieviele Requests pro Minute hast du im Durchschnitt?
- Wie gross sind die Requestschwankungen in Zeiträumen von 5 Minuten, einer Stunde und einem Tag?
- Wie sehen die VHost-Einstellungen aus?
- Welcher Apache-Worker ist im Einsatz?
- Welche Last hat der Server im Durchschnitt und maximal?
- Welche Hardware wird am meisten belastet (CPU, RAM oder Festplatte)?
- Benutzt die Webapplikation Memcaching? Wenn ja wofür und in welchem Umfang? Wenn nein, warum nicht?
Bei Verwendung von PHP:
- Welche Erweiterungen sind in PHP?
- Wird eaccelerator verwendet?
- Wie lange braucht das rechenintensivste Skript vom Request bis zur Auslieferung?
- Wieviel RAM verbraucht das speicherintensivste Skript?
MySQL:
- Wie gross ist der grösste Tabellen-Index?
- Wie gross sind alle Tabellen-Indizes zusammen?
- Welchen Datenzuwachs hast du am Tag?
- Welcher Tabellentyp wird verwendet und warum?
- Wie sieht der Output von 'SHOW VARIABLES' aus?
- Sind Techniken wie Replikation oder Clustering im Einsatz? (Deiner Konfiguration nach würde ich auf nein tippen)
- Wieviele Queries gibt es im Durchschnitt pro Sekunde sowie maximal und minimal am Tag?
- Welche Slow-Queries gibt es? (slow-query-logging aktivieren)
- In welchem Umfang wird Logging benötigt (bei einem VServer oder Rootserver sollte man jedes Query loggen um bei einem erfolgreichen Angriff nachvollziehen zu können was der Angreifer getan hat, kann aber zumeist auf Debug-Logging verzichten)?
Das wäre erstmal nur die wichtigsten Fragen, die beantwortet werden müssen um irgendwas zur Optimierung sagen zu können. Wenn du keine Ahnung von der Materie hast, solltest du dir daher einen Profi dazuholen, der sich diese Daten mit Statistik-Tools wie Webalizer, apachetop u.a. selbst sammeln kann. Momentan handelt es sich jedenfalls bei deinen Server-Einstellungen um die Ubuntu-Standards, die in grossen Umgebungen alles andere als brauchbar sind. Ausserdem eignet sich ein VServer nicht unbedingt für grosse Webapplikationen, da die CPU-Leistung mit anderen VServern geteilt werden muss. Die Analyse von Performance-Daten ist damit sehr schwierig bis unmöglich, sofern man nicht gerade einen eigenen CPU-Kern oder eine eigene CPU für seinen VServer verfügbar hat. Auch die Schwankungen des verfügbaren RAMs können (und werden) bei wachsender Request-Zahl zu Problemen führen, gerade wenn der Prefork-Worker im Einsatz ist, den ich in grossen Umgebungen empfehlen würde.
Elderan
0
Hallo,
wo bitmuncher es gerade erwähnte:
Bist du dir überhaupt sicher, dass MySQL bzw. Apache das Nadelöhr sind?
Oftmals sind die Applikationen sehr schlecht programmiert, inbesondere die SQL Anweisungen. Da werden dann Abfragen an die Db gesendet, bei denen gesamte Tabellen durchlaufen werden müssen um nur einen Datensatz zu finden. Hier beispielsweise ein einfachen Index anzulegen kann die Performance deiner Anwendung extrem steigern, da nicht bei jedem Script Aufruf zehntausende von Zeilen durchgegangen werden müssen sondern nur ein Lookup in einer Hashtable durchgeführt werden muss.
slow-query-logging kann extrem hilfreich sein, solche Übeltäter an Abfragen ausfindig zu machen und durch eine leichte Anpassung der Abfrage kann die Performance enorm gesteigert werden.
Auch sollte man evt. mal die Script überprüfen, die am häufigsten aufgerufen werden und sicher gehen, dass dort keine Performance Killer enthalten sind. Natürlich muss man sich das entsprechende Know How vorher anlesen oder entsprechend einkaufen.
Denn mit schelchten Scripts (d.h. schlechte SQL Abfragen, die auf eine große Datenmenge losgelassen werden und häufig ausgeführt werden) kann man selbst den besten konfigurierten Root Server in die Knie zwingen.
wo bitmuncher es gerade erwähnte:
Bist du dir überhaupt sicher, dass MySQL bzw. Apache das Nadelöhr sind?
Oftmals sind die Applikationen sehr schlecht programmiert, inbesondere die SQL Anweisungen. Da werden dann Abfragen an die Db gesendet, bei denen gesamte Tabellen durchlaufen werden müssen um nur einen Datensatz zu finden. Hier beispielsweise ein einfachen Index anzulegen kann die Performance deiner Anwendung extrem steigern, da nicht bei jedem Script Aufruf zehntausende von Zeilen durchgegangen werden müssen sondern nur ein Lookup in einer Hashtable durchgeführt werden muss.
slow-query-logging kann extrem hilfreich sein, solche Übeltäter an Abfragen ausfindig zu machen und durch eine leichte Anpassung der Abfrage kann die Performance enorm gesteigert werden.
Auch sollte man evt. mal die Script überprüfen, die am häufigsten aufgerufen werden und sicher gehen, dass dort keine Performance Killer enthalten sind. Natürlich muss man sich das entsprechende Know How vorher anlesen oder entsprechend einkaufen.
Denn mit schelchten Scripts (d.h. schlechte SQL Abfragen, die auf eine große Datenmenge losgelassen werden und häufig ausgeführt werden) kann man selbst den besten konfigurierten Root Server in die Knie zwingen.
bitmuncher
Senior-Nerd
Erfahrungsgemäss kann man damit sogar ganze Webserver-Cluster in die Knie zwingen.
Es ist sogar noch schlimmer - unsachgemäße Indexverwendung kann auch ein Bremsfaktor sein 
. Wenn Hashing verwendet wird - darauf können keine <> % Operatoren angewendet werden bzw. Hashindex bringt in diesem Fall nichts.
Ein B/RTREE Index ist wiederum nur bis zu einem gewissen Faktor schneller - wenn in der Ergebnismenge (auf die eventuell noch weitere Operationen angewendet werden) mehr als ~30% aller Einträge enthalten sind (kommt auf die Anzahl der Daten und letzendliche Implementierung der BTREES an), ist es für die interne Suchfunktion effizienter, direkt die Spalte "nach und nach" abzuarbeiten, als über eine Indexierung zuzugreifen (da hier auch 3-4 Lesezugriffe gebraucht werden, um sich durch den BTREE zu dem Inhalt zu hangeln).
Weiterhin (nur persönliche Erfahrung) - weder bei DB2 noch MySQL sind die internen Queryoptimierer wirklich intelligent - sicherheitshalber sollte man also die kritischen Stellen nochmal ins Auge nehmen:
Also zuerst diese Stellen suchen mit z.B
MySQL Query profiler
dann die Anfrage anzeigen lassen (so wie sie intern durchgeführt wird, bei db2 war das db2expln, bei MySQL sollte es irgendwas mit "EXPLAIN SELECT bla" sein) und schauen, wofür die meiste Zeit gebraucht wird.
Bei relativ wenigen Daten könnte ich mir nur irgendeine depended subquery als Übeltäter vorstellen (z.B ein weiteres SELECT/JOIN im WHERE Teil, muss noch nichtmal "absichtlich" sein) oder auch irgendwelche unnötigen crossjoins mittels "SELECT bla FROM X,Y,Z" (was auch bei relativ wenigen Einträgen in den einzelnen Tabellen riesige Zwischentabellen erzeugen kann) - hier würde z.B intelligentes JOIN ON _indizierte_spalte helfen oder eine anderere Formulierung.
Die beste Query/DB Optimierung bringt wiedrum nichts, wenn irgendein PHP Teil mit "unnötigen" Queries um sich schleudert.
. Wenn Hashing verwendet wird - darauf können keine <> % Operatoren angewendet werden bzw. Hashindex bringt in diesem Fall nichts. Ein B/RTREE Index ist wiederum nur bis zu einem gewissen Faktor schneller - wenn in der Ergebnismenge (auf die eventuell noch weitere Operationen angewendet werden) mehr als ~30% aller Einträge enthalten sind (kommt auf die Anzahl der Daten und letzendliche Implementierung der BTREES an), ist es für die interne Suchfunktion effizienter, direkt die Spalte "nach und nach" abzuarbeiten, als über eine Indexierung zuzugreifen (da hier auch 3-4 Lesezugriffe gebraucht werden, um sich durch den BTREE zu dem Inhalt zu hangeln).
Weiterhin (nur persönliche Erfahrung) - weder bei DB2 noch MySQL sind die internen Queryoptimierer wirklich intelligent - sicherheitshalber sollte man also die kritischen Stellen nochmal ins Auge nehmen:
Also zuerst diese Stellen suchen mit z.B
MySQL Query profiler
dann die Anfrage anzeigen lassen (so wie sie intern durchgeführt wird, bei db2 war das db2expln, bei MySQL sollte es irgendwas mit "EXPLAIN SELECT bla" sein) und schauen, wofür die meiste Zeit gebraucht wird.
Bei relativ wenigen Daten könnte ich mir nur irgendeine depended subquery als Übeltäter vorstellen (z.B ein weiteres SELECT/JOIN im WHERE Teil, muss noch nichtmal "absichtlich" sein) oder auch irgendwelche unnötigen crossjoins mittels "SELECT bla FROM X,Y,Z" (was auch bei relativ wenigen Einträgen in den einzelnen Tabellen riesige Zwischentabellen erzeugen kann) - hier würde z.B intelligentes JOIN ON _indizierte_spalte helfen oder eine anderere Formulierung.
Die beste Query/DB Optimierung bringt wiedrum nichts, wenn irgendein PHP Teil mit "unnötigen" Queries um sich schleudert.
Elderan
0
Hallo,
Aber besonders der Misch aus zwei Sprachen ist schwierig, da dann die Caching-Funktionalitäten von Apache nicht mehr so gut funktionieren bzw. ein doppelt so großer Wortschatz vorgehalten werden muss => Enormer Performance Killer.
Ne Bitmuncher meinte, in welcher Programmiersprache deine Applikationen geschrieben sind. PHP, Perl, Ruby?
Soetwas sollte unbedingt vermieden werden und stattdessen auf JOINS gesetzt werden. Aber auch die müssen richtig gemacht werden.
Ebenso können kleinste Sachen fatale Auswirkungen haben, obwohl man es gar nicht erwartet hätte (und man dennoch indizes nutzt).
Wie gesagt, die wichtigsten Scripts nochmal überprüfen und schauen ob MySQL slow queries meldet.
Noch ein gut gemeinter Tipp:
Du hast scheinbar noch nicht wirklich viel Ahnung von Linux. Dann ist ein (Linux) Root Server eindeutig die falsche Wahl.
Bitte bitte, unbedingt so schnell wie möglich Grundlegende Linux Kenntnisse aneignen, und die gehen über Plesk und eine GUI (z.B. KDE) hinaus. Ebenso wie man Server härtet (d.h. sichert) etc.
Denn es könnte ebenso gut sein, dass jemand in deinen Server eingebrochen ist und im besten Fall nur zig tausend Spam Mails pro Tag versendet oder im 'worst-case' z.B. Kinderpronographie über deinen Server verteilt (die Staatsanwaltschaft wird dann an deine Tür klopfen, und dass die dich nicht mit Samthandschuhen anpacken werden sollte dir bewusst sein).
Ein Root Sever ist keine Spielwiese, andem man bischen rumexperimentieren kann. Man braucht gute Kenntnisse, in zig Bereichen.
Linux, Firewalls, IDS, TCP/IP bzw. Netzwerke allgemein, Betriebssystem- & Hardwaregrundlagen, Logging, Rootkits/Würmer/Exploits sowie für alle Komponenten die eingesetzt werden, d.h., Apache, MySQL (Server als auch SQL Abfragen), Phyton evt. Mail Server, FTP Server, Update-Managment. Nur um ein paar Bereichen zu nennen für die man zumindest die Grundlagen beherschen sollte.
Nur der Punkt 'MySQL' ist schon sehr umfangreich, man sollte wissen wie ein DBMS aufgebaut ist und wie relationale Datenbanken (grob) arbeiten, d.h., wie werden Indizes realisiert. Da setzt wieder die Kenntniss von grundlegenden Algorithmen & Datenstrukturen voraus.
Wie du siehst, ist das ein extrem weites Feld und für die meisten die soetwas nicht hauptberuflich machen ist ein eigener Server die falsche Wahl. Es gibt so schöne Hostingpackete, bei denen man sich um kaum noch etwas kümmern muss.
Ebenso mal auf MySQL.com die Performance Tipps durchlesen, wie man Anfragen performanter gestalten kann.
Oh das ist natürlich schlecht, insbesondere wenn noch das deutsche zusätzlich ist. Deutsch ist eben nicht so eine einfache Sprache wie englisch, d.h., für die selbe Aussage muss man oft deutlich mehr schreiben => Performance Killer.
Aber besonders der Misch aus zwei Sprachen ist schwierig, da dann die Caching-Funktionalitäten von Apache nicht mehr so gut funktionieren bzw. ein doppelt so großer Wortschatz vorgehalten werden muss => Enormer Performance Killer.
Ne Bitmuncher meinte, in welcher Programmiersprache deine Applikationen geschrieben sind. PHP, Perl, Ruby?
Das ist längst nicht ausreichend. Oft werden SQL Anweisungen auch in Schleifen an die DB gesendet (z.B. SELECT userid, text FROM posts, dann in der Schleife zur Ausgabe der Posts: SELECT username FROM users WHERE userid = $meineUserId)
Soetwas sollte unbedingt vermieden werden und stattdessen auf JOINS gesetzt werden. Aber auch die müssen richtig gemacht werden.
Ebenso können kleinste Sachen fatale Auswirkungen haben, obwohl man es gar nicht erwartet hätte (und man dennoch indizes nutzt).
Wie gesagt, die wichtigsten Scripts nochmal überprüfen und schauen ob MySQL slow queries meldet.
Noch ein gut gemeinter Tipp:
Du hast scheinbar noch nicht wirklich viel Ahnung von Linux. Dann ist ein (Linux) Root Server eindeutig die falsche Wahl.
Bitte bitte, unbedingt so schnell wie möglich Grundlegende Linux Kenntnisse aneignen, und die gehen über Plesk und eine GUI (z.B. KDE) hinaus. Ebenso wie man Server härtet (d.h. sichert) etc.
Denn es könnte ebenso gut sein, dass jemand in deinen Server eingebrochen ist und im besten Fall nur zig tausend Spam Mails pro Tag versendet oder im 'worst-case' z.B. Kinderpronographie über deinen Server verteilt (die Staatsanwaltschaft wird dann an deine Tür klopfen, und dass die dich nicht mit Samthandschuhen anpacken werden sollte dir bewusst sein).
Ein Root Sever ist keine Spielwiese, andem man bischen rumexperimentieren kann. Man braucht gute Kenntnisse, in zig Bereichen.
Linux, Firewalls, IDS, TCP/IP bzw. Netzwerke allgemein, Betriebssystem- & Hardwaregrundlagen, Logging, Rootkits/Würmer/Exploits sowie für alle Komponenten die eingesetzt werden, d.h., Apache, MySQL (Server als auch SQL Abfragen), Phyton evt. Mail Server, FTP Server, Update-Managment. Nur um ein paar Bereichen zu nennen für die man zumindest die Grundlagen beherschen sollte.
Nur der Punkt 'MySQL' ist schon sehr umfangreich, man sollte wissen wie ein DBMS aufgebaut ist und wie relationale Datenbanken (grob) arbeiten, d.h., wie werden Indizes realisiert. Da setzt wieder die Kenntniss von grundlegenden Algorithmen & Datenstrukturen voraus.
Wie du siehst, ist das ein extrem weites Feld und für die meisten die soetwas nicht hauptberuflich machen ist ein eigener Server die falsche Wahl. Es gibt so schöne Hostingpackete, bei denen man sich um kaum noch etwas kümmern muss.
Ebenso mal auf MySQL.com die Performance Tipps durchlesen, wie man Anfragen performanter gestalten kann.
bitmuncher
Senior-Nerd
Die Plesk-Screenshots helfen da wenig. Da solltest du besser ein Statistik-Tool wie Munin oder Cacti verwenden um solche Daten zu ermitteln. Plesk ist dafür total ungeeignet. Das Ganze könnte dann z.B. so aussehen: http://munin.habolinux.de/localdomain/localhost.localdomain.html Wie willst du Performance-Killer finden, wenn du keine statistischen Daten der Performance hast?
Memcaching ist eine Technik, bei der oft verwendete statische Inhalte im RAM abgelegt werden um die Festplattenzugriffe zu ersparen. Dadurch wird die HD enorm entlastet und die Auslieferung von Seiten findet wesentlich schneller und mit weniger Rechenleistung statt.
Sowas sollte man als DB-Admin aber im Blick haben. Schau in's Daten-Verzeichnis deiner Datenbank. Dort liegen MYI-Dateien für die Tabellen rum. Dies sind die Index-Dateien, an deren Grösse man sich orientieren kann. Als Faustregel gilt: die Grösse aller MYI-Dateien zusammen sollte in den RAM passen + natürlich weiterer RAM für die Applikationen, die laufen.
Also 3GB.
Wäre in bestimmten Umgebungen kein allzu grosser Datenzuwachs. Etwas genauer bitte.Beim Clustering arbeiten mehrere Datenbank-Server parallel. Anfragen werden also von mehreren Maschnen paralllel abgearbeitet.
Auch da sollten etwas genauere Angaben her. Oben genannte Tools können das Anhand der Logs und Socket-Zugriffe ermitteln.
Unter Slow-Queries versteht man DB-Abfragen, die besonders lange dauern. Diese kann man in den Slow-Query-Logs sehen, allerdings müssen die erstmal aktiviert sein. Die MySQL-Doku wird dir dabei helfen.
Woran machst du das Fest? Ein Server mit 2GB RAM und 2 GHz kann selbst mit Default-Konfiguration problemlos bis zu 100 Zugriffe pro Sekunde abarbeiten, wenn die Applikation keine Bottlenecks bildet und die DB-Indizes in den RAM passen. Nach deinen bisherigen Aussagen (keinen grossen Datenzuwachs, 20% CPU-Last usw.) glaube ich aber nicht, dass du eine solche Anzahl erreichst. Ich glaube daher nicht, dass das Problem in der Konfiguraton liegt, auch wenn man da sicherlich noch einiges optimieren könnte (Buffer-Grössen der MySQL optimieren, Prefork-Worker optimieren usw.). Allerdings sind dazu schon ein wenig mehr Kenntnisse als ein bisschen Plesk-Klickibunti notwendig. Schnapp dir also die Doku von Apache und MySQL, setze dir ein Statistik-Tool auf mit dem du Performance-Daten sammeln kannst und lerne lerne lerne. Bis du damit fertig bist, hole dir jemanden, der sich damit auskennt. Ansonsten gilt: http://root-und-kein-plan.ath.cx/ Das solltest du mal lesen um dir allein schon der Gefahren eines Rootservers mal bewusst zu werden. 100MBitler sind keine Spielzeug für Noobs. Wie Elderan schon sagte, kann es nämlich bei deinem Kenntnisstand durchaus sein, dass dein Server bereits Teil eines Botnetzwerks ist und deswegen unter so hoher Last steht. 20% Dauer-CPU-Last sind nämlich recht ungewöhnlich bei einem Webserver, der fast nie auf den ganzen Tag verteilt gleichmässig belastet ist.