+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega International Area (/forum-22.html)
+--- Forum: German Corner (/forum-26.html)
+--- Thread: Server optimieren (/thread-3063.html)
Pages: 1 2
RE: Server optimieren - Slowman - 04-18-2008 09:25 PM
Stoppe mal den php5-cgi und starte Apache mal neu, der Serverload kann damit zusammenhängen, wenn du die aktuelle DebianVersion benutzt. Da es dort mit dem PHP5 Probleme gibt. Tips gibt es hier im Forum genug
RE: Server optimieren - tetex - 04-18-2008 10:08 PM
Hallo,
habe eAccelerator laufen ja. Wegen dem Tuning-Script für MySQL werde ich mich sofort umsehen.
MfG
RE: Server optimieren - Cube - 04-18-2008 10:15 PM
Das Skript ist auch in einem HowTo in der Docu erwähnt und downloadbar:
http://www.isp-control.net/documentation/howto/miscellaneous/run_ispcp_on_a_low_resources_system#mysql
RE: Server optimieren - tetex - 04-18-2008 11:04 PM
Cube Wrote:Das Skript ist auch in einem HowTo in der Docu erwähnt und downloadbar:
http://www.isp-control.net/documentation/howto/miscellaneous/run_ispcp_on_a_low_resources_system#mysql
>>Thanks..
###
Also habe Apache und MySQL nun etwas fine-tuning unterzogen. Einen kurzen Moment lief soweit auch alles gut. Inzwischen ist der httpd wieder nicht mehr zu erreichen...
netstat -anp |grep 'tcp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
1 134.169.9.*
1 193.175.106.*
1 195.189.247*
1 213.239.204.*
1 217.234.110.*
1 57.66.197.*
1 62.117.31.*
1 62.117.6.*
1 67.159.44.*
1 74.6.17.*
1 74.6.8.*
1 77.134.84.*
1 77.180.108.*
1 77.180.11.*
1 77.181.157.*
1 77.185.27.*
1 78.49.184.*
1 78.94.147.*
1 79.198.69.*
1 80.121.87.*
1 80.123.8.*
1 80.132.160.*
1 80.137.176.*
1 80.138.72.*
1 82.207.140.*
1 82.83.17.*
1 83.135.127.*
1 84.188.115.*
1 84.189.66.*
1 84.62.32.*
1 84.72.151.*
1 85.180.2.*
1 85.182.59.*
1 86.33.92.*
1 87.123.74.*
1 87.170.113.*
1 88.72.234.*
1 88.74.149.*
1 88.74.247.*
1 89.197.146.*
1 89.248.169.*
1 89.49.235.*
1 89.49.254.*
1 89.57.90.*
1 89.59.185.*
1 89.60.200.*
1 91.19.19.*
1 91.58.238.*
1 91.61.117.*
1 91.6.232.*
1 91.97.22.*
2 84.144.79.*
2 84.62.141.*
2 85.127.8.*
2 91.16.232.*
3 68.49.120.*
3 77.190.62.*
3 83.233.180.*
3 87.160.21.*
3 91.34.247.*
12 79.202.35.*
16 0.0.0.0
36 89.13.24.*
264
RE: Server optimieren - sowosammerneger - 04-27-2008 08:05 PM
Was hast Du denn genau optimiert und warum nimmst Du nicht eine handvoll Hardware und wirfst damit nach deinem Problem?
RE: Server optimieren - fulltilt - 04-27-2008 08:25 PM
tetex Wrote:36 89.13.24.*
also 36 Verbindungen von einer IP Adresse könnte schon sein das hier jemand Angriffe ausführt ...
Einfach mal in einem solchen Moment die IP Adresse blockieren, dann auch mal mit TOP schauen welcher User eventl. die Resoucen braucht ...
vieleicht ist ja auch eine User Anwendung dafür verantwortlich.
RE: Server optimieren - ephigenie - 04-27-2008 10:56 PM
Also meine Meinung : 36 Verbindungen von einer IP sind nichts ungewöhnliches und mitnichten gleich als Angriff zu werten.
http 1/1 erlaubt keepalive Verbindungen und wenn einer seinen Browser "getuned" hat kann das schon bei 2 offenen Browserfensterchen leicht dazu kommen.
Viel wichtiger ist zu schauen, was eigentlich darüber abgerufen wird.
Evt. hilfts dir ja mal dsniff zu installieren und dann einfach mal urlsnarf auszuführen ...
Damit siehst du ja welche urls und wie oft diese aufgerufen werden.
Dann gehts evt. eher daran, mal den Apache bzw. die MySQL config sorgfältig auseinanderzunehmen - bzw. wie auch schon vorgeschlagen wurde, die Anwendungen, die auf dem Server laufen genau unter die Lupe zu nehmen.
Wieviel queries/s muss deine mySQL verarbeiten - wieviele davon nutzen keinen Index (sind also fulltable-scans) welche joins sind suboptimal geschrieben usw...
Also nicht erreichbar sollte ein Server eigentlich da kaum sein - wobei nat. immer auch der Punkt erreicht sein kann, wo es wirklich für die Hardware zu viel ist - und ein größerer Server bzw. mehr Ram einfach Wunder bewirkt.
In Zeiten in denen Ram kaum was kostet - sollte es schon möglich sein, für wenig Geld einen Server mit anständig RAM zu bekommen (siehe z.B. Hetzner oder auch NGZ)
RE: Server optimieren - rbtux - 04-28-2008 05:14 AM
naja ich würde mal sql debugging machen, ich hatte mal ein ähnliches problem von 80% mysql auslastung. Dies kam damals von einer schlecht programmierten applikation mit sehr vielen joins etc, es waren jedoch keine indexes gesetzt.
mysql biete eine funktion um langsame queries zu loggen, jedoch braucht diese option ziemlich i/o. Ich befürchte wenn du das einschaltest geht dein server komplett in die knie...
Ansonsten ist natürlich schon anzumerken, dass die Hardware äusserst knapp bemessen ist...
RE: Server optimieren - Gos77 - 04-28-2008 05:54 PM
Also die Load Average halte ich doch für sehr bedenklich. Das erklärt auch, wieso Du selbst auf der Konsole bzw. per SSH Probleme hast zu arbeiten. Da viele Prozesse gleichzeitig laufen und die Queue für deren Abarbeitung entsprechend lang ist.
Da Du von vielen Zugriffen per Web auf die sicherlich Dynamischen Inhalte gesprochen hattest, halte ich nen PHP-Cache ala eAccelerator für sehr sinnvoll, da häufig verwendeter PHP-Code so nicht jedesmal von neuem abgearbeitet werden muss.
Falls das Board es hergibt würde ich eine Dual-Core CPU einsetzen, um die Verarbeitung der anlaufenden Prozesse zu erhöhen.
Wie groß sind die Datenbanken deiner Kunden?
Möglicherweise würde auch hier etwas mehr RAM recht nützlich sein. Falls das Board und der Geldbeutel es zulässt würde ich hier 2GB ansetzen. So Teuer ist aktueller Speicher ja heutzutage nicht mehr.
Was für Platten verwendest Du? SCSI / IDE / SATA und welche RAID Kombination?
Hier könnte auch noch ein Nadelöhr liegen, wenn die Platten recht langsam sind oder wenig Cache zur Verfügung haben. Gerade bei der Zugriffszahl sollten es dann schon minimum 7.200 mit 8MB Cache sein. Umso mehr umso besser. Und wenn möglich auf ein RAID 5 setzen, was jedoch meist einen aktiven SCSI Kontroller voraussetzt.
Vorschlag für Tuningreihenfolge:
1. PHP-Cache eAccelerator
2. MySQL-Tuning Script
3. RAM Nachrüsten (würde ich jedoch bei den heutigen Kosten fast Prio 1 setzen)
4. CPU mit 2 Cores einsetzen
5. Schnellere Platten verwenden oder auf seperaten aktiven Controller verfrachten