Seite Lahmt sehr stark, immer öfters Fehler 500!

Hallo,

seit einiger Zeit lahmt meine Seite enorm und es taucht immer öfters ein 500ter Fehler (Internal Server Error) auf.

Ich dachte erst das es an den vielen Crons (~100) liegt die gleichzeitig immer liefen.
Habe diese jetzt aber schön aufgeteilt, das somit nicht immer gleichzeitig so eine last läuft.
Aber das Problem besteht weiterhin.

Nur in sehr unregelmäßigen Abständen, ich weiß so langsam nicht mehr weiter, vielleicht könnt ihr mir helfen.

Folgend versuche ich euch so viele Details wie möglich mitzuteilen:

Es handelt sich um ein Webspace bei Alfahosting (Multipaket)

URL: www.money4click.info
Ist eine reine Klickseite (Banner/Links/HF/Mails) kein betteln oder Surfbar.

VMS Version: 1.2.4

Webserver: Apache

MySQL-Client-Version: 5.0.84

PHP Version: 5

slow_query_log: hab ich leider nicht

Aktuell: 15 MySQL Abfragen | PHP: 0,1639 s | SQL: 0,0015 s

Datenbank: 80 Tabellen | Gesamt | 249,195 | MyISAM | latin1_german1_ci | 21,7 MiB | 1,6 MiB

Top10:

[tableold="head"]Tabelle | Größe | Überhang
vms_reloads_mail | 11,1 MiB | -
laendercode | 4,8 MiB | -
vms_gebuchte_werbung | 2,9 MiB | 758,1 KiB
vms_vcheck_codes | 1,0 MiB | 690,3 KiB
vms_reloads | 796,8 KiB | 130,0 KiB
vms_buchungen | 51,2 KiB | -
stg_bilanz | 250,4 KiB | -
stg_support | 64,2 KiB | -
vms_paidmails_empfaenger | 57,2 KiB | 6,3 KiB
vms_kontodaten | 27,2 KiB | -
[/tableold]

So ich denke das wars erstmal mit Infos.

Würde mich jetzt über eure Hilfestellung sowie Tipps bzw. Ratschläge freuen, wie und was noch optimieren kann.

Schönen Abend noch!

Gruß

Falk

Hallo, allgemein würde ich sagen ist das VMS kein Performance wunder das ist klar ;)

Bei der datenbank würde ich mal versuchen ob die Mailreloads geleert werden könnten denn 11MB sind glaube ich schon ein bisschen viel.

Zum fehler 500.

Zitat:

---

500 Internal Server Error
Dieser Fehler erscheint, wenn die Zugriffsrechte falsch bzw. nicht gesetzt sind oder wenn sich eine "php.ini"-Datei im Hauptverzeichnis befindet.

Lösung:
a) Überprüfen Sie, ob sich Hauptverzeichnis eine http://www.strato-faq.de/faq_images/datei.gif php.ini Datei befindet und ändern Sie probeweise den Namen der Datei. Überprüfen Sie, ob die Fehlermeldung anschließend immer noch erscheint.

b) Die Zugriffsrechte auf Ordner und/oder Dateien sind nicht in Ordnung und müssen geändert werden. (CHMOD)

---

Wie Vorredner schon geschrieben hat, ist die Tabelle der Reloads Mail, schon elend groß.
Da dürften etliche alte Reloads vorhanden sein.

Ich würde mal die DB_optimize installieren und mal laufen lassen.
Dazu noch eine Zeile für Reloads der Mail einbauen.

Zu guter Letzt noch mal die Tabellen durchgehen und optimieren.

LG

Guten Morgen,

viel Dank für eure Antworten, habe da gleich mal ein paar Fragen dazu.

1. Mailreloads
Wie bekomme ich aber heraus welche gelöscht werden können?
Da ja sich davon auch noch welche Aktiv sind!?

2. Fehler 500
Wenn es an den Schreibrechten liegen sollte, würde der Fehler da nich immer auftreten? Und/oder wo fange ich mit der Suche an?
Nach der php.ini schaue ich heute Nachmittag mal, ist die beim VMS von Grund auf dabei? Sonst dürfte eigentlich keine da sein.

3. DB_Optimize
Wo bekomme ich das her?

So jetzt muss ich erstmal weiter arbeiten :biggrin1:

Vielen Dank im Vorraus :thumb:

Zu 1.
Wenn dir einen gefallen tun willst und ein etliches an Zeit sparen willst, dann wirst bei der Tabelle kurz und schmerzlos machen müssen..11 MB sind ein haufen Zeug^^

Tabelle leeren und fertig. Wird sich mit ein paar Kampagnen überschneiden, aber besser so, als anders^^

Zu 2.
Die php.ini liegt im root Verzeichnis. Wenn du der Betreiber von dem Server bist, und root rechte hast, kannst drauf zu greifen.

Zu. 3
Hier: http://www.designerscripte.net/downl...?do=file&id=69

Die muss leicht angepasst werden, gibts aber auch schon Threads dazu, einfach mal sufu benutzen ;)

LG

Zitat:

---

Zitat von Siggi84

...

1. Mailreloads
Wie bekomme ich aber heraus welche gelöscht werden können?
Da ja sich davon auch noch welche Aktiv sind!?

...

---

Das kommt natürlich darauf an, wie das Addon, das diese Tabelle angelegt hat, die Werte interpretiert. Vermutlich wird es aber ähnlich wie bei den Forcedbanner Reloads sein, also so in etwa:

PHP-Code:

---

db_query('DELETE FROM `vms_reloads_mail` WHERE bis < '.time()); 


---

Einen 500'er Fehler näher einzugrenzen ohne vollen Zugriff auf Logs und Konfiguration ist quasi kaum möglich, aufgrund des Webspace Pakets würde ich einfach mal von einer Überlastung ausgehen.

Im phpmyadmin sieht man normalerweise iwo eine Statistik, wie viele Anfragen pro Sekunde gemacht werden etc., evtl. schaust du das mal rein.

Zitat:

---

Zitat von WaechterMedia

Hallo, allgemein würde ich sagen ist das VMS kein Performance wunder das ist klar ;)

Bei der datenbank würde ich mal versuchen ob die Mailreloads geleert werden könnten denn 11MB sind glaube ich schon ein bisschen viel.

Zum fehler 500.

---

Zitat:

---

Zitat von Sam2004

Zu 1.
Wenn dir einen gefallen tun willst und ein etliches an Zeit sparen willst, dann wirst bei der Tabelle kurz und schmerzlos machen müssen..11 MB sind ein haufen Zeug^^

Tabelle leeren und fertig. Wird sich mit ein paar Kampagnen überschneiden, aber besser so, als anders^^

Zu 2.
Die php.ini liegt im root Verzeichnis. Wenn du der Betreiber von dem Server bist, und root rechte hast, kannst drauf zu greifen.

Zu. 3
Hier: http://www.designerscripte.net/downl...?do=file&id=69

Die muss leicht angepasst werden, gibts aber auch schon Threads dazu, einfach mal sufu benutzen ;)

LG

---

Zitat:

---

Zitat von jpwfour

Das kommt natürlich darauf an, wie das Addon, das diese Tabelle angelegt hat, die Werte interpretiert. Vermutlich wird es aber ähnlich wie bei den Forcedbanner Reloads sein, also so in etwa:

PHP-Code:

---

db_query('DELETE FROM `vms_reloads_mail` WHERE bis <  '.time()); 


---

Einen 500'er Fehler näher einzugrenzen ohne vollen Zugriff auf Logs und Konfiguration ist quasi kaum möglich, aufgrund des Webspace Pakets würde ich einfach mal von einer Überlastung ausgehen.

Im phpmyadmin sieht man normalerweise iwo eine Statistik, wie viele Anfragen pro Sekunde gemacht werden etc., evtl. schaust du das mal rein.

---

Vielen lieben Dank an euch drein !!!

Habe jetzt DB_Optimize Installiert und an das VMS 1.2 angepasst.

Und einmal laufen laufen lassen, laut den Forenbeiträgen, hätte ich mir es länger vorgestellt, ca. 2sek. :thumb:

Siehe das, das hat es gebracht:

Vorher:
Datenbank: 80 Tabellen | Gesamt | 249,195 | MyISAM | latin1_german1_ci | 21,7 MiB | 1,6 MiB

Top10:

[tableold="head"]Tabelle | Größe | Überhang
vms_reloads_mail | 11,1 MiB | -
laendercode | 4,8 MiB | -
vms_gebuchte_werbung | 2,9 MiB | 758,1 KiB
vms_vcheck_codes | 1,0 MiB | 690,3 KiB
vms_reloads | 796,8 KiB | 130,0 KiB
vms_buchungen | 51,2 KiB | -
stg_bilanz | 250,4 KiB | -
stg_support | 64,2 KiB | -
vms_paidmails_empfaenger | 57,2 KiB | 6,3 KiB
vms_kontodaten | 27,2 KiB | -
[/tableold]

Nachher:
Datenbank: 80 Tabellen | Gesamt | 134,574 | MyISAM | latin1_german1_ci | 8,8 MiB | 80,1 KiB

Top10:

[tableold="head"]Tabelle | Größe | Überhang
laendercode | 4,8 MiB | -
vms_gebuchte_werbung | 1,9 MiB | -
vms_vcheck_codes | 555,0 KiB | -
vms_reloads_mail | 554,3 KiB | -
vms_buchungen | 175,5 KiB | 80,1 KiB
stg_bilanz | 254,8 KiB | -
vms_reloads | 197,2 KiB | -
stg_support | 59,9 KiB | -
vms_kontodaten | 22,3 KiB | -
vms_shoutbox | 23,3 | -
[/tableold]

Ich denke das sollte doch etwas ausmachen, werde es jetzt mal genau beobachten!

Wie es jpwfour schon vermutet hat, denke ich auch das der 500ter Fehler durch die größere Last zu Stande kommt, sonst müsste er ja theoretisch immer sein.

Hätte aber trotzdem noch einmal eine allgemeine Fragen dazu.

1. Welcher intervall wäre empfehlenswert um den Cron laufen zu lassen, täglich oder wöchentlich ?

Nochmals DANKE :thumb:

Falk alias Siggi84

den kannste doch täglich laufen lassen, nachts wenn nix los ist, frisst ja kein Brot :wink:

Wenn das mit dem 500 Fehler bleibt würde ich darüber nachdenken den host zu wechseln wenn es geht.

Ansonsten alle crons die nichts mit werbung zu tun haben in die morgen stunden schieben also so 1-5 Uhr da ist eigentlich nicht so viel los ;)

Ich muss mich leider nochmal melden.

Habe jetzt einige User, bei denen die V-Check Statistik bei ganzen 0% liegt.

Kann es sein DB_optimizer da zuviel gelöscht hat?

Das die Banner etc. noch im Reloed sind und somit vom V-Check nicht vergütet werden.

Oder ist das gerade ein dummer Zufall?

Zitat:

---

db_query('DELETE*FROM*`vms_reloads_mail`*WHERE*bis *<*'.time());*

---

Wenn ich das richtig verstehe wird alles gelöscht, älter ist als "jetzt" !?

Dumme gesagt

Mal im Serverlasst mal geschaut?
Vielleicht ist der Server zu schwach

dann kommt 2 Leute Schnell drauf aber die anderen sind in der warteschleife und brauchen was länger beim laden oder es geht gar nicht

Zitat:

---

Zitat von Siggi84

Ich muss mich leider nochmal melden.

Habe jetzt einige User, bei denen die V-Check Statistik bei ganzen 0% liegt.

Kann es sein DB_optimizer da zuviel gelöscht hat?

Das die Banner etc. noch im Reloed sind und somit vom V-Check nicht vergütet werden.

Oder ist das gerade ein dummer Zufall?



Wenn ich das richtig verstehe wird alles gelöscht, älter ist als "jetzt" !?

---

du hast auch die vchecks bereinigt soweit ich es sehe da kann sowas passieren

Zitat:

---

Zitat von Siggi84

...
Wenn ich das richtig verstehe wird alles gelöscht, älter ist als "jetzt" !?

---

Das ist richtig, dazu gehört aber auch, das der Wert der gespeichert wird "bis" heist, sprich alles was älter als "jetzt" ist, ist auch schon veraltet :wink:.

Wie sieht der Cron denn genau bei dir aus? Evtl. wurden Einträge aus den V-Check Tabellen gelöscht.

Zitat:

---

Zitat von Basell

Dumme gesagt

Mal im Serverlasst mal geschaut?
Vielleicht ist der Server zu schwach

dann kommt 2 Leute Schnell drauf aber die anderen sind in der warteschleife und brauchen was länger beim laden oder es geht gar nicht

---

Hi, das ist ja das Problem, es ist kein eigener Server sondern "nur" ein Webspacepaket.

Da es eine reine "Klickseite" ist, macht das rein "Kostentechnisch" keinen Sinn, sonst hätte ich mir schon längst einen Server geholt.

Zitat:

---

Zitat von WaechterMedia

du hast auch die vchecks bereinigt soweit ich es sehe da kann sowas passieren

---

An den V-Check Codes habe ich garnichts gemacht, ist im Cron nicht mit drin, kann jedoch sein das

PHP-Code:

---

db_query ("OPTIMIZE TABLE `".$table_name."`"); 


---

hier was verändert hat !? Da das ja im Cron mit inbegriffen ist !?

Zitat:

---

Zitat von jpwfour

Das ist richtig, dazu gehört aber auch, das der Wert der gespeichert wird "bis" heist, sprich alles was älter als "jetzt" ist, ist auch schon veraltet :wink:.

Wie sieht der Cron denn genau bei dir aus? Evtl. wurden Einträge aus den V-Check Tabellen gelöscht.

---

Hier der komplette Cron!

PHP-Code:

---

$buchlimit = '10'; // Buchungen welche aelter als XX Tage sind, aus Datenbank loeschen.
 $inaktivlimit = '100'; // Wenn User laenger als XX Tage inaktiv ist, wird er mit Hinweis gesperrt (Wengier als 10 Tage nicht möglich!).
 $sperrhinweis = 'Account wegen inaktivität gesperrt! Bitte an den Support wenden!'; // Sperrhinweis bei Inaktivitaets-Sperrung!

 // Ungueltige Reload-Sperren loeschen
 db_query('DELETE FROM `vms_reloads` WHERE bis < '.time());
 db_query('DELETE FROM `vms_reloads_mail` WHERE bis < '.time());

   // Tabellenanzahl und IDs auslesen
   $result = mysql_list_tables($db_base);
   $menge = mysql_num_rows($result);
   for($x=0;$x<$menge;$x++){

     // Tabellennamen holen
     $table_name = mysql_tablename($result,$x);

     // Tabelle optimieren
     db_query ("OPTIMIZE TABLE `".$table_name."`");
   }

 // Zeit setzen
   db_query ("UPDATE ".$db_prefix."_crons SET laufzeit = '".time()."' WHERE bezeichnung = 'Datenbank optimieren'");

 // User, welche ueber 100 Tage inaktiv, sperren mit Hinweis
   if($inaktivlimit < 10) { $inaktivlimit = 10; }
   db_query ("UPDATE ".$db_prefix."_kontodaten SET status = 2, hinweis = '".$sperrhinweis."' WHERE last_active < ".(time()-($inaktivlimit*86400))." AND last_active > 0");

 // Buchungen loeschen aud DB, wenn diese aelter als xx Tage sind
   db_query ("DELETE FROM ".$db_prefix."_buchungen WHERE buchungszeit < ".(time()-($buchlimit*86400)));

    die('<font color="green">Cron erfolgreich gelaufen!</font>');
  ?> 


---

Hatte gestern den Usern auch mal einen NL geschickt, das es eine "Optimierung" gab und das sie doch bitte mal vorbei schauen sollten zum kurzen Speed Test, nur über die hälfte ist der Meinung das sich nichts verbessert hat.

Mir selbst ist zwar nichts aufgefallen das es lahm war, hatte aber gestern auch Weihnachtsfeier und konnte nicht ganz so viel beobachten.

Gibt es vielleicht noch eine Möglichkeit, die Seite zu beanspruchen um das mal "hier und jetzt" zu testen ?

Mit dem V-Check hat sich heute auch wieder gelegt, ist zwar heute auch noch nicht viel geklickt worden, aber ich stehe momentan bei ~86% gesamt.

Im Umgehrschluss ist es vielleicht auch logisch, wenn die Seite "hängt" das es mit dem Check nicht so positiv aussieht, da die "Rückmeldung" ja dann sicher auch hängt, oder ?

Möchte nochmal betonen, ihr seit Spitze, hier wird einen bei Problemen noch geholfen! :thumb:

Der Cron ist so in Ordnung und sollte den V-Check nicht weiter beeinflussen, evtl wirklich nur Zufall, oder du hast (sofern du den VCheck Version 4 hast) ausversehen den vcheck_reset.php Cron ausgeführt?

Zitat:

---

Zitat von Siggi84

...Speed Test, nur über die hälfte ist der Meinung das sich nichts verbessert hat.
...

---

Viel dürfte sich dadurch auch nicht verbessern, bei "grossen" Tabellen die viel Überhang haben, kann es natürlich sein, dass einzelne Anfragen etwas länger brauchen, aber normalerweise sollte das noch nicht so stark ins Gewicht fallen, sofern Indizes gut gesetzt sind.

Der nächste Schritt könnte sein, dass man versucht, die Anzahl der Anfragen generell zu minimieren, und schaut, ob es irgendwo "kritische" Anfragen gibt, Beispiele wären:
Anzeige der verbleibenden Klicks im Menü für jeden User
mehrfaches Auslesen der Userdaten für Anzeigen in den Menüs
eine schlecht programmierte Chatbox und/oder zu gerine Reload Zeit in der Chatbox
uvm.

Hast du die Bettelfunktion aktiviert und/oder deine Seite in Traffic/Besuchertausch etc eingetragen?
Dadurch entsteht auch sehr viel Last (und das unnötig, da man durch Traffic/Besuchertausch zu 99,9% nur Hits bekommt, aber nur 1 Anmeldung im Jahr :wink:).

bezüglich last würde ich übers cachen nachdenken wenn es wirklich nicht am hoster liegt bin dir da auch gern behilflich ist eigentlich recht einfach wenn man nur bestimmte Segmente cachen will hat aber hallt den Nachteil das nicht immer alles hallt sofort sichtbar ist.

Ich würde auch sagen bestimmte Sachen sind am besten zu "cachen" und die allgemeine Serverlast zu verringern. Schau mal auf Autolose.de dort stehen oben die Top Verdienste, ein sehr gutes Beispiel, denn diese Werte sind nicht life aus der Datenbank sondern aus einer CacheDatei welche nur alle x Minuten die Werte aktualisiert.

Auch wenn man den User viele Werte präsentieren will sollte man immer Bedenken das diese Auszulesen auch ServerLast verursacht.

MfG

Zitat:

---

Zitat von jpwfour

Der Cron ist so in Ordnung und sollte den V-Check nicht weiter beeinflussen, evtl wirklich nur Zufall, oder du hast (sofern du den VCheck Version 4 hast) ausversehen den vcheck_reset.php Cron ausgeführt?



Viel dürfte sich dadurch auch nicht verbessern, bei "grossen" Tabellen die viel Überhang haben, kann es natürlich sein, dass einzelne Anfragen etwas länger brauchen, aber normalerweise sollte das noch nicht so stark ins Gewicht fallen, sofern Indizes gut gesetzt sind.

Der nächste Schritt könnte sein, dass man versucht, die Anzahl der Anfragen generell zu minimieren, und schaut, ob es irgendwo "kritische" Anfragen gibt, Beispiele wären:
Anzeige der verbleibenden Klicks im Menü für jeden User
mehrfaches Auslesen der Userdaten für Anzeigen in den Menüs
eine schlecht programmierte Chatbox und/oder zu gerine Reload Zeit in der Chatbox
uvm.

Hast du die Bettelfunktion aktiviert und/oder deine Seite in Traffic/Besuchertausch etc eingetragen?
Dadurch entsteht auch sehr viel Last (und das unnötig, da man durch Traffic/Besuchertausch zu 99,9% nur Hits bekommt, aber nur 1 Anmeldung im Jahr :wink:).

---

Zu den Anfragen:

Die verbleibenden Klicks werden "nur" auf den entsprechenden Seiten Sichtbar, klick4/textlink/etc...

Im Menü werden "nur", Kontostand/APs Heute/ APs Gesamt angezeigt.

Chatbox, da habe ich Maddin´s SB, da schreibt aber so gut wie keiner rein.

Bettelfunktion habe ich keine, war zwar geplant, aber momentan nicht.

Besuchertausch und Werbung habe ich aktuell keine, wollte ja das "Problemchen" nicht noch verschlimmern.

Zitat:

---

Zitat von WaechterMedia

bezüglich last würde ich übers cachen nachdenken wenn es wirklich nicht am hoster liegt bin dir da auch gern behilflich ist eigentlich recht einfach wenn man nur bestimmte Segmente cachen will hat aber hallt den Nachteil das nicht immer alles hallt sofort sichtbar ist.

---

Was meinst du genau unter "cachen" ?

Edit:
Was mir aber gerade aufgefallen ist, die SB hat sich alle 5sek aktualisiert, denke hier könnten wir das Problemchen schon haben, oder ???
In der Einstellung stand Reload, ich bin davon ausgegangen das ist die Zeit wann ein User wieder schreiben kann und nicht wenn die SB sich aktualisiert. Wären alle 5sek - 200 Einträge, von der Datenmenge zwar nicht viel, aber viele Zeichen.

Zitat:

---

Zitat von Masterphil

Ich würde auch sagen bestimmte Sachen sind am besten zu "cachen" und die allgemeine Serverlast zu verringern. Schau mal auf Autolose.de dort stehen oben die Top Verdienste, ein sehr gutes Beispiel, denn diese Werte sind nicht life aus der Datenbank sondern aus einer CacheDatei welche nur alle x Minuten die Werte aktualisiert.

Auch wenn man den User viele Werte präsentieren will sollte man immer Bedenken das diese Auszulesen auch ServerLast verursacht.

MfG

---

Damit hat sich meine Frage von eben geklärt, jetzt weiß ich was gemeint war.

Wie bereits geschrieben, wären das nur Kontostand/APs Heute/APs Gesamt was immer angezeigt wird, mehr nicht, keine Top Klicker etc...