Yahoo bringt Server zum Crashen?

Beitrag von **Sneff** » 09.07.2006, 13:35

Hallo Community,

ich bin Betreiber eines großen deutschen Diskussionsforums mit täglich ca 8000 Besuchern / 100.000 Hits

Vor einigen Tagen wurde ein Newsletter versandt an alle 25.000 Mitglieder. Zudem ist nun situationsbedingt ein größerer Besucheranstieg von ca 20% zu verzeichnen.

Seitdem habe ich das Problem dass mein Server, der sonst immer maximal 3% ausgelastet ist, alle 2 Stunden in etwa auf 30-50% Auslastung ansteigt und sich dadurch dann die Datenbank mit der Meldung max_user_connections überschritten (40 sind es) kurzfristig aufhängt.
Die Crashs sind fast genau um 12, 14, 16 und 18 Uhr... die restlichen durch 2 Teilbaren Stunden fallen nicht ins Gewicht weil die Besucherzahlen da nicht so hoch sind.

Tja warum nun das im Yahoo-Forum
Ich vermute der Slurp-Bot ist schuld. Beim letzten Crash eben um 14 Uhr war der Slurp-UserAgent ca 30 Mal in meinen Sessions zu sehen.
Google dürfte es nicht sein, hatte da zwar schon von maximaler Crawling-Geschwindigkeit auf normal gestellt...
Bin mit meinem Latein am Ende, was das sein könnte.

Bis gestern wars sehr schlimm, ein browsen im Forum beinahe nicht zumutbar. Hatte dann alle Bilder auf einen anderen Server ausgelagert, seitdem ist die Performance normalerweise sehr gut, nur eben nicht alle 2 Stunden, da gehts erst total runter und dann steht alles für 2-4 Minuten.

Mein Hoster ist All-inkl ich bin auf einem ManagedServerL.

Wäre echt dankbar wenn mir jemand einen Tipp geben könnte was das sein könnte bzw ob da wirklich Slurp dran schuld und was ich dann machen könnte.

mfg
Sneff

von **Anzeige von ABAKUS** »

Beitrag von **oldInternetUser** » 09.07.2006, 13:45

Für den Slurp gibt es m.W. nach irgendeine Crawl-Delay - Anweisung. Such mal bei Yahoo nach den Webmaster-Hinweisen, dort nach der robots.txt

Beitrag von **DJTonic** » 09.07.2006, 13:45

eine auslastung von 50% (=load 0.5) ist praktisch gar nichts.
über-beanspruchung (=prozesse müssen warten) beginnt erst ab 1 (=100%).

du solltest die anzahl der maximalen verbindungen erhöhen und gucken, welche cronjobs (=backup?) laufen...

Beitrag von **Sneff** » 09.07.2006, 13:48

Crons laufen um diese Uhrzeit keine
Eben war die Auslastung nur auf 10% gestiegen und die Datenbank hat sich verabschiedet.

Die Anzahl der max_user_connections hat mir all-inkl schon erhöht, habe da keinen Einfluss drauf... wurde aber schon von 25 auf 40 gesetzt

Kann es sein dass durch die vermehrten Anfragen und eine höhere Auslastung die Datenbank nicht mehr nachkommt.
Ist 40 als Wert wohl niedrig

Eben hängts wieder, werde dann gleich schauen welche Sessions zuletzt vor dem Crash aktiv waren

Beitrag von **Sneff** » 09.07.2006, 13:52

@DJTronic, ok deine Aussage hat mich jetzt verwirrt...
Wert 1,0 = 100%?

Beitrag von **DJTonic** » 09.07.2006, 17:55

naja die load geht ja normalerweise bei 0 los und der wert "1" heisst: kein prozess muss warten, alle werden sofort abgearbeitet. bei 0,5 könnte der server doppelt so viele ohne wartezeit abarbeiten.
da du von 30% bis 50% gesprochen hast, hab ich das als 0,3 bis 0,5 interprätiert.
sollte diese grafik die load sein geht die aber nicht auf 30 % sondern auf 15 bis 20 hoch...

back to topic: wenn die db sehr gross ist und der server wenig ram hat, kann der server sich durchaus verabschieden wenn der swap-speicher auch nicht mehr reicht

Beitrag von **Sneff** » 09.07.2006, 17:59

Die Datenbank hat ca 190MB Größe, der Server 256MB RAM
Habe jetzt mal dem Yahoo-Bot den Wert 10 angewiesen (kA was das genau heißt) und beobachte mal weiter
Im Moment schwankts zwischen 1 und 4

Beitrag von **Christophe** » 10.07.2006, 00:05

Hallo Sneff,

hast du dir mal die Speicherauslastung angeguckt? 256MB sind doch ziemlich wenig.

Ich vermute, bei vielen Zugriffen fängt der Server an zu swappen und die Datenbank wird lahm, was zu noch mehr gleichzeitigen Zugriffen führt. 40 Datenbankverbindungen deuten darauf hin.

Viele Grüße,
Christophe

Beitrag von **chris21** » 10.07.2006, 01:39

Hast Du schon den Slurp (China) rausgeworfen?

Denke mal, dass der für Dich keinen Nutzen hätte, also gleich per htaccess sperren.

Ansonsten hilft wohl nur eine Logfileanalyse, diese Ausreißer nach oben sind schon extrem.

Mit crawltrack ( https://www.crawltrack.info/ Download/GNU GPL) kannst Du ganz gut nachverfolgen. was die Spieder/Bots so auf Deiner Seite treiben, ohne auf die Loganalyse angewiesen zu sein.

Beitrag von **marle** » 10.07.2006, 07:58

Hallo,

besorg dir nen Server mit mehr Arbeitsspeicher. Wenn das alles nicht Hilft lager die DB auf einen 2ten Server aus. Grund: such nicht den Fehler bei dem Bot oder dem Nutzer sondern bei dir (Scripten) und deiner Hardware. Langfristzig gesehen kommst du nicht drum herrum auf einen neuen Server auszuweichen mit mehr RAM. Empfehlen würde ich dir min 1GB und einen anderen Hoster. Ich persönlich habe mit all-inkl nur schlechte Erfahrungen gemacht.

Grüße

Beitrag von **DJTonic** » 10.07.2006, 10:38

256 mb ram bei einem forum sind einfach zu wenig. steck noch 256 mb rein und gut ist.
alternativ: wenn du zuviele hacks eingebaut hast: wirf die raus, viele davon sind richtig grauenhaft programmiert.

Beitrag von **Sneff** » 10.07.2006, 17:38

Die meisten Features (und das sind viele) habe ich selbst gemacht. Denke die Qualität derer ist schon als gut zu bezeichnen.
All-Inkl hat jetzt den Server optimiert, sagen sie... Aber es gab wieder eine Auslastung auf 15 gegen 16 Uhr...

Werde dann später mal die Logs auswerten bzw chris21's Tool probieren

Danke schonmal

Beitrag von **Clever** » 11.07.2006, 12:32

Hallo Sneff,

an der MySQL Datenbank kann man einiges optimieren. Hast du eigentlich die Nutzung des Query Cache bedacht? Diese Option Ist bei All-Inkl im Normalfall nicht aktiviert.

Es müssen dabei folgende Werte geändert werden:
query_cache_type - auf ON setzen
query_cache_size - zum Probieren mal auf 8MB setzen

Hier findest du auch ne kurze Erklärung:
https://blog.koehntopp.de/archives/1173 ... ies-3.html

Die Query_Cache Funtkion bringt zum Teil erhebliche Geschwindigkeitsvorteile, da das Ergebnis vieler Querys eben gespeichert wird. Wenn erneut gleiche Querys folgen, dann wird die Datenbank damit fast nicht mehr belastet. Wenn eine Query genau gleich wie eine vorhergehende ist, dann wird das Ergebnis der Abfrage direkt aus dem Cache gelesen.

Desweiteren ist es oft schlecht wenn Inserts oder Updates auf eine Tabelle ausgeführt werden wenn dabei oft Lesevorgänge auf die gleiche Tabelle erfolgen. Dann kann es leicht vorkommen, daß viele Vorgänge warten müssen, wobei wiederum dieses max user_connections leicht überschritten wird. In einigen Fällen ist es hilfreich 2 gleiche Tabellen anzulegen, wobei eine aktualisiert wird und aus der anderen gelesen. Ok, bei einem Forum kann man damit wohl nichts anfangen. Aber wenn du zum Beispiel Statistiken über mySQL erzeugst, dann genügt es diese Tabellen z.B. nachts abzugleichen.

PS: Du kannst dir mit dem Befehl "SHOW VARIABLES" im mysqladmin die Werte anzeigen lassen

Nur als Anhaltspunkt, ich hab im moment eine Domain mit ca. 15000 Besuchern pro Tag, wobei die Tabellen teilweise 1600 MB groß sind und ebenfalls alles dynamisch erzeugt wird. Ebenfalls bei All-Inkl, aber ein großer Server mit 2048 MB Speicher. Keine Probleme im moment. Aber ok, ich gebs zu...

Ich hatte das gleiche Problem auch schon mal, habs aber in den Griff bekommen.

.

Beitrag von **Sneff** » 11.07.2006, 13:50

Hallo,

danke für diesen Tipp!
Leider ist die Cache Size schon bei 35MB

mfg
Sneff

Beitrag von **Sneff** » 11.07.2006, 20:38

Eben wieder gecrasht und der Yahoo-Bot ist 70 mal in den Sessions drin!! Das ist doch nicht normal? Habe doch den Crawl-Delay eingestellt...

Kann jemand was aus den IPs erkennen ob das vllt einer ist, der sich nicht an die Regeln hält oÄ?