Seite lahmt aber wo mit der Suche anfangen

[Sledgedog]

Hi,
leider lahmt meine Seite seit 3 Tagen total.
Kaum sind paar User am klicken, dann kann man während die Banner öffnen einen Kaffee trinken, den man vorher in Ruhe von Hand aufbrühen kann

Leider habe ich ich ehrlich gesagt nicht so den Plan von der Sache und weiss also nicht, wo ich mit der Suche beginnen soll.
Einen Bildungsurlaub für PHP habe ich erst gemacht, damit ich dort wenigstens mal weiss, was Sache ist und mich nun durch Probieren immer mehr in die Materie rein arbeiten kann.
Nur leider ist der SQL Kurs erst Anfang nächsten Jahres also muss ich warten und suchen.

Ich habe folgenden vServer:

Hardware
CPU: Core2Duo - Fair Use
RAM: 2,5GB
Flexi-RAM/SWAP: 8GB
HDD: 200GB
Traffic: 7168GB
Betriebssystem frei wählbar
-Debian: ja
-Debian inkl. SysCP: ja
-Debian inkl. Confixx(Aufpreis): ja
-Debian inkl. Plesk(Aufpreis): ja
-Debian inkl. ISCP: ja
-Debian inkl ISPConfig: ja
-Fedora: ja
-CentOS: ja
-Suse: ja
-Ubuntu: ja
-AsteriskNow: ja
-Gentoo: ja
-Slackware: ja
Technische Details
beliebig viele Domains: ja
Domains auch von anderem ISP: ja
IP-Adressen enthalten: 1 (weitere gemäß ripe.net möglich)
frei wählbarer Reverse-DNS: ja
Reverse-DNS pro IP: ja
Neustart / Web-Reset: kostenlos über Web-Interface
Rescue System: kostenlos über Web-Interface
Neuinstallation: kostenlos über Web-Interface
Betriebssystemwechsel: kostenlos über Web-Interface
SW-RAID: Master SW-Raid 1
Anbindung: Master über 100Mbit Port

Das kommt z.B. wenn ich derzeit meine Startseite aufrufe: 42 MySQL Abfragen | Seite wurde in 92.2560 Sekunden erstellt

und das wenn man die banner aufruft: 45 MySQL Abfragen | Seite wurde in 157.6240 Sekunden erstellt

vor kurzen waren da noch Werte von 0.0..... Sekunden

nur gelegentlich komme ich jetzt noch auf diese Werte: 44 MySQL Abfragen | Seite wurde in 0.0160 Sekunden erstellt
aber leideer nur noch selten

Wo setzt man mit der Optimierung am besten an oder wie kann ich sehen, was da derzeit so sehr das Tempo aus der Seite nimmt?

[Sebmaster]

Geh mal in PhpMyAdmin, und schau dir die Tabellenüberhänge an, sollten da große Werte stehen (über 1MB beim VMS) dann optimiere mal alle Tabellen.

Ansonsten: Gibt es Abfragen, die bei jedem Seitenaufruf durchgeführt werden (Ländercode o.ä.; meist: linkes_menue.php; header.php; rechtes_menue.php)?

[Sledgedog]

Ansonsten: Gibt es Abfragen, die bei jedem Seitenaufruf durchgeführt werden (Ländercode o.ä.; meist: linkes_menue.php; header.php; rechtes_menue.php)?

ja gibt es z.B. Anteile, Top10 Klicker....

aber wenn ich z.B. im Klickbereich bin (AJAX) und da nur auf neuladen gehe, dann lädt er ja die Seite nicht neu aber es dauert trotzdem ewig

nur komisch, das die Werte halt eben ständig schwanken und das bei gleichbleibender Useraktivität

Edit: hab mal geschaut aber Überhänge gehen sind gesamt 135 Bytes

233 Tabellen Gesamt 3,444,871 MyISAM latin1_swedish_ci 236,9 MiB 132,5 KiB

[Hardy]

hast du an die indexe rumgespielt?

[Sledgedog]

hast du an die indexe rumgespielt?

nein ist alles unverändert, daher wundert mich ja der plötzliche leistungsabfall so

[jpwfour]

Die 10 Tabellen mit den meisten Einträgen?
3,4 Mio ist ja nun auch nicht so wenig, wenn die zum Großteil alle in einer noch dazu schelcht indizierten oder gar nicht indizierten Tabelle sind, und da ein Select oder noch schlimemr ein Join drauf gemacht wird, wäre logisch, warum das so lang dauert.

Hast du die Möglichkeit die Option "slow_query_log" anzustellen beim MySQL Server?

Diese Option loggt alle Queries mit, die länger als eine einstellbare Zeit in Sekunden dauern, damit sollte sich der Übeltäter schnell finden lassen (alternativ den Hoster darum bitten, dass mal zu aktivieren).

Zusätzlich kann es nicht schaden, einmal am Tag alle Tabellen optimieren zu lassen, (Game)Buchungslisten Einträge älter als XX Tage zu löschen, und besonders Gamelogs regelmäßig zu leeren.


Ansonsten kannst du es auch mal mit getrennter Zeitmessung versuchen:
http://www.designerscripte.net/showthread.php?t=6152&highlight=db_query
evtl hat ein Scherzkeks von Addonersteller in seiner Funktion ein sleep(40) eingebaut :biggrin1:

[Sledgedog]

Hast du die Möglichkeit die Option "slow_query_log" anzustellen beim MySQL Server?



Muß ich mal schaun, weiss ja nicht wo man das macht, aber notfalls nerve ich gleich den hoster mal



Zusätzlich kann es nicht schaden, einmal am Tag alle Tabellen optimieren zu lassen, (Game)Buchungslisten Einträge älter als XX Tage zu löschen, und besonders Gamelogs regelmäßig zu leeren.


Ich denke mal das der ganze Müll drinnen bleibt in der Datenbank
da werd ich wohl mal schauen müssen, das ich das hinbekomme das er da bei den games alles äter als xx tage raus schmeisst

[sunnydreamer]

So ein Problem haben wir aktuell auch, egal ob Serverwechsel oder ob man die DB auslagert irgendwo hängt es trotzdem noch.

Naja, mal schauen was die Serverlogs ergeben, weil die verschiedenen Teile der Seite sind eigentlich schon weitesgehend optimiert.

Grüße, Sunny

[Lokutos]

CPU: Core2Duo - Fair Use


Mit nem VMS soll da 40 sec beisammenkommen von ein paar klicks? nie und nimmer.

Ich würde einfach mal deinen hoster anschreiben.
Fair Use bedeutet ja im 99.99% das noch wer anders da drauf ist

eventuell checkst du mal welche noch darauf sind wenn du nicht weist wie schick mir deine Domain dan sag ich dir welche Domains noch auf dem Server sind.

MFG Lokutos

[didith1207]

hast du db optimierungs cron jeden tag laufen? (reload löschen usw)

[Sledgedog]

hast du db optimierungs cron jeden tag laufen? (reload löschen usw)


ja ist im tagcron mit drinnen

[Sledgedog]

Zusätzlich kann es nicht schaden, einmal am Tag alle Tabellen optimieren zu lassen, (Game)Buchungslisten Einträge älter als XX Tage zu löschen, und besonders Gamelogs regelmäßig zu leeren.


also hier kann ich sicher was verbessern, bei den games sind meist alle logs seit bestehen der seite drinnen

bin da für tipps dankbar wie ich einfach machen kann das er alles älter als xx tage löscht

[didith1207]

einfach einen zusätzlichen cron erstellen zb mit namen buchlimit.php


<?php

$buchlimit = '10'; // Buchungen welche älter als XX Tage sind, aus Datenbank loeschen.

// Buchungen loeschen aus DB, wenn diese älter als xx Tage sind
db_query ("DELETE FROM ".$db_prefix."_gamebuchungen WHERE buchungszeit < ".(time()-($buchlimit*86400)));
db_query ("DELETE FROM ".$db_prefix."_buchungen WHERE buchungszeit < ".(time()-($buchlimit*86400)));
usw...
?>INSERT INTO `vms_crons` VALUES ('', 'buchlimit', 0, 'crons/buchlimit.php', 'Buchungslimit');

[Sledgedog]

super die Datenbank wird schon wesentlich kleiner nach der Bereinigung :thumb:

wenn ich nun z.b. die universal_cache_log
auch regelmässig reinigen will, wie füge ich die da ein
genauso nur ohne $db_prefix?
hat nämlich nicht geklappt

[didith1207]

hmm.. gibts bei universal_cache_log keine timestamp spalte?

wenn es sie gibt sollte es mit dem hier klappen:


db_query ("DELETE FROM universal_cache_log WHERE buchungszeit < ".(time()-($buchlimit*86400)));

[Sledgedog]

doch gibt es, läuft nun auch, ich hatte nur mal wieder einen . vergessen

warum kann man auch bei php nicht einfach in die erste Zeile massig ;;;;;; ........ usw eingeben, damit der sich dann bedient, wenn man was verpeilt einzugeben :biggrin1:

Danke Dir :thumb:

[sunnydreamer]

Die Datenbankgröße spielt aber nicht "umbedingt" eine Rolle, also ich kenn Seiten die lagern auf Ihrer DB gut 500MB-3GB und das Dinge flitzt.

Ggf. liegt es auch an bestimmten Unterseiten die x mal von den Usern aufgerufen werden und dort eben einfach zu viel Abgefragt wird. Meist ist das z.B. die Refübersicht da bei ner Downline von ca. 100 Usern schon einiges an Abfragen zusammen kommen kann.

Oder lädt man als Admin zu oft die Userliste, dann der Ländercode und was weiß ich dann ist nix mehr mit schnell klicken für die User :P...

Grüße, Sunny

[Sledgedog]

ja aber ich habe nun trotzdem mal die Einträge von fast 3,5 mio auf 1,8 mio reduziert

aber ich denke ein hauptproblem ist der doppler
denn dort sind alle auszahlungen drinnen gespeichert

wenn ausgezahlt wurde dann setzt er den status von 0 auf 1

die auszahlungen bleiben nur gespeichert, um "bisher gesamt ausgezahlt" anzeigen zu können

will das gern ändern so das er die ausgezahlte summe in eine extra tabelle speichert und anstelle dann den status auf 1 zu setzen soll er die position löschen

da er ja immer sucht wo die erste position mit status "0" ist dauert das immer länger
denn derzeit muss der da ca. 190k positionen durchgehen bis er auf eine mit Status "0" kommt
man merkt direkt wenn ein user in den doppler zahlt, da dann die performance stark in die knie geht

[jpwfour]

Nun dazu müsste man das ganze Doppler Addon kennen, manchmal greifen die doch auf die anderen Zeilen zu bzw. kommen nicht mehr klar, wenn man die einfach so rauslöscht usw.

Macht aber auf jeden Fall Sinn, solche Zeilen rauszuhau'n, da die kaum als einzelne nachher noch genutzt werden, und für die Gesamtheit reicht auch 1 Zeile.

Solltest auch mal in die AccessLogs schaun bzw. dir dise auswerten lassen (Webalizer etc.).

Evtl buchen da welche deine Bettelseite in massig Surfbars ein, die dann wiederum von massig Bots/Chinesen/Tools aufgerufen werden, da kommen dann schnell massig Requests auf den Server zu.

Folge je nach Konfiguration, dass einfach alles langsamer wird, weil der Apache auf Reisverschluss Modus schaltet :biggrin1:

ALso mal checkn, wie wird die Bettelseite genutzt, und wo überall ist deine Seite in Traffic/Surfbar eingebucht.

[Sledgedog]

ja Bettellogs prüfe ich derzeit ständig und das Ergebnis ist grauenhaft
werde wohl daher die Bettelfunktion demnächst deaktivieren
bin es langsam leit da immer mehr User und Seiten sperren zu müssen

das mit dem doppler schaut sich Skandal mal an, von dem ist der ja, er kennt sich dann ja sicher am besten damit aus

habe mir die datenbank mal auf eine Testumgebung gespielt und in den doppler eingezahlt
hing total und dauerte ewig
dann habe ich dort alle erledigten zahlungen gelöscht und nochmal was eingezahlt
dann ging der ab wie verrückt, da scheint also noch einiges Möglich zu sein

[snowcat]

Wegen der Auszahlungen mach ich das einmal am Tag so:


<?php
@require_once('../lib/functions.lib.php');
db_connect();

$alle=mysql_fetch_array(db_query("SELECT `uid` FROM `vms_userdaten` ORDER BY `uid` DESC LIMIT 1")); //höchste uid auslesen

$c=1; // erste uid

# 30 Tage
$dauer = 60*60*24*30;
$frist = time()-$dauer;

while($c<=$alle[uid]){
$summe=mysql_fetch_array(db_query("SELECT SUM(buchungsmenge) AS xxx FROM vms_buchungen WHERE buchungszeit<".$frist." AND (verwendungszweck='Auszahlung') AND uid=".$c.""));
//gesamtauszahlungssumme des users bis zur frist auslesen
if ($summe[xxx]){ //wenn summe vorhanden - bei bis dahin nicht ausgezahlt, hat summe keinen wert
echo "User ".$c." wird bereinigt - ".$summe[xxx]."<br>";
db_query("DELETE FROM vms_buchungen WHERE buchungszeit<".$frist." AND (verwendungszweck='Auszahlung' OR verwendungszweck='Auszahlung') AND uid=".$c.""); //alte auszahlungen löschen
db_query("INSERT INTO vms_buchungen (uid,buchungszeit,buchungs_id,buchungsmenge,verwen dungszweck) VALUES ('".$c."', '".$frist."', '', '".$summe[xxx]."', 'Auszahlung')"); //neue auszahlungssumme eintragen
}
$c++; //nächster user
}


db_close();
?> Somit bleibt die gesamte Auszahlung erhalten und in der Tabelle steht einmal ein großer Auszahlungswert.

Also statt:
-3000
-3423
-7945
steht da nun
-14368.

Wenn man jeden Tag hunderte Auszahlungen machen muss, dann geht da schon einiges in die Datenbank und so bleiben dann auch die Mediadaten und Statpicker so wie sie waren. ;)

[Sledgedog]

sieht nicht schlecht aus
habe zwar in den mediadaten nicht angegeben, was bisher ausgezahlt wurde
aber was nicht ist kann ja noch werden

[Speedy]

Darf ich mich in diesem Thread mal anschliessen?

Bin grad dabei, für meine frau eine SEITE Aufzubauen. VMS 1.2.3 hab ich mal genommen.

Beim Probeklicken mit einer Anzahl von 30 Bannern geht es bei den letzten schon los, dass es ewig dauert, bis der Frame aufbaut, geschweige denn, abläuft.

Indexe müssten auch alle stimmen.

Und dass die DB zu voll ist kann ja nicht sein, da die Seite noch nagelneu ist.

Hab natürlich auch meine Zockseite auf dem Server, aber da sind vielleicht 20 Leute gleichzeitig on. Da kanns eigentlich auch nicht dran liegen.

Hab im Klickbereich nur die Bannersortierung von Adi eingebaut und oben die Statistik aus dem Highforced Addon drüber.

Beim Aufbau sind es 26 MySQL Abfragen

Keine Ahnung, wo es dran liegen könnte

EDIT: Habe noch folgende Indexe gesetzt:



ALTER TABLE `vms_paidmails_empfaenger` ADD INDEX ( `uid` );
ALTER TABLE `vms_paidmails_empfaenger` ADD INDEX ( `tan` );
ALTER TABLE `vms_paidmails_empfaenger` ADD INDEX ( `status` );
ALTER TABLE `vms_paidmails_empfaenger` ADD INDEX ( `gueltig` );

ALTER TABLE `vms_paidmails_versendet` ADD INDEX ( `tan` );
ALTER TABLE `vms_paidmails_versendet` ADD INDEX ( `gueltig` );

ALTER TABLE `vms_werberdaten` ADD PRIMARY KEY ( `uid` );
ALTER TABLE `vms_werberdaten` ADD INDEX ( `werber` );

ALTER TABLE `vms_buchungen` ADD INDEX ( `uid` );
ALTER TABLE `vms_buchungen` ADD INDEX ( `buchungszeit` );
ALTER TABLE `vms_buchungen` ADD INDEX ( `buchungs_id` );

ALTER TABLE `vms_gebuchte_werbung` ADD INDEX ( `tan` );
ALTER TABLE `vms_gebuchte_werbung` ADD INDEX ( `sponsor` );
ALTER TABLE `vms_gebuchte_werbung` ADD INDEX ( `werbeart` );

ALTER TABLE `vms_reloads` ADD INDEX ( `uid` );
ALTER TABLE `vms_reloads` ADD INDEX ( `tan` );
ALTER TABLE `vms_reloads` ADD INDEX ( `ip` )


Bei vms_werberdaten kam eine Fehlermeldung.
Aber die Seite ist MIT, sowohl als auch OHNE Indexe gleich langsam :-(

[jpwfour]

Die groben Eckdaten wären trotzdem praktisch:
Anzahl Tabellen
Größe Gesamt
Einträge gesamt
"Top 10" Tabellen (Einträge/Größe)
Anzahl DB Anfragen / Sekunde/Minute (sieht man im PHPMyAdmin/Status, Laufzeit sollte mind. 7 Tage sein für sinnvolle Werte)

Ebenfalls in PHPMyAdmin/Satus kann man evtl Problemfelder sehen:
Handler_read_rnd, Handler_read_rnd_next usw (Erklärungen stehen dazu meist auch mit bei)

[Speedy]

Also Tabellen und so weiter ist alles noch Standard, weil ja noch keine User da sind.

Fehlermeldungen im php sind auch keine

Top10 ist glaub ich gar nicht drin

also quasi noch 0 los. Meine frau hat nur Probeklicks gemacht. War vom ersten Banner an so langsam


Die groben Eckdaten wären trotzdem praktisch:
Anzahl Tabellen
Größe Gesamt
Einträge gesamt
"Top 10" Tabellen (Einträge/Größe)
Anzahl DB Anfragen / Sekunde/Minute (sieht man im PHPMyAdmin/Status, Laufzeit sollte mind. 7 Tage sein für sinnvolle Werte)

Ebenfalls in PHPMyAdmin/Satus kann man evtl Problemfelder sehen:
Handler_read_rnd, Handler_read_rnd_next usw (Erklärungen stehen dazu meist auch mit bei)

[Holstenjungs]

Mit TOP10 meinte er dass du mal schaun sollst welche Tabellen am größten sind.

[Speedy]

Die grössten Tabellen, Interface und crons, haben so 20 - 30 KB, alle zusammen mal gerade 3,6 MB

Wie gesagt, sind ja auch noch keine User da

[snowcat]

Was nutzt du als System? WebSpace, VServer, Root-Server? Mit welchen Eckdaten?