phpBB.de

Schlechte SQL-Querys? Die Frage ist auch nach wie vor ob es wirklich an MySQL liegt.

Per Frage und Antwort Spiel ist es auch recht ermüdend das Problem einzukreisen, das ganze kann viele Ursachen haben: Schlecht Programmierte Seiten oder SQL-Querys, schlecht konfigurierte Dienste (Apache, PHP, MySQL, etc...).

Hast du einen Managed-Server oder normalen Webspace?

Hallo,

da muss wohl irgendwo der Wurm drin sein

Ich habe einen ManagedServer L bei all-...

Viele Grüße Dennis

Hab ich mir irgendwie schon fast gedacht. Irgendwie scheinen viele Managed-Server eher schlecht konfiguriert zu sein.

Ich kann dir mal ein paar Stichwörter nennen die du mit deinem Hoster besprechen kannst:

MySQL-Threadcache, PHP-Cache wie Eaccelerator.

also ich habe ähnliche kurven bei all-in+++

nach installation des eaccelerators wurde es besser ist aber noch immer nicht weg.

über entsprechende tipps bin ich auch dankbar.

Hallo zusammen,

ich habe die gleichen Probleme gehabt und habe sie zum Teil noch. Die Anzahl der Queries sind im Moment Dein Hauptproblem.

Das mit dem mysql_close ist Schwachsinn und das weiß all-inkl. auch. Diese Ausrede haben sie bei mir ständig gebracht. Viel mehr fehlt es dem Server einfach an Power. Der Server schafft die MySQL-Queries einfach nicht. Wobei die Hauptbelastung bei mir durch smartors Photo Album produziert wurden. Studier mal Deine Statistik (usage Verzeichnis) und schau welche Dateien am meisten aufgerufen werden. Genau die sollten dann überarbeitet werden. Ich nutze Categories Hierarchy. Wenn Dein Board nicht allzu stark gemoddet ist (was es aber bestimmt ist ) könntest Du easy auf CH 2.1.6 wechseln. Diese Version ist ultra schnell und spart eine enorme Anzahl an Queries. Derzeit habe ich davon die Version 2.1.4 und die hat einiges gebracht. (z.B. werden die Wortfilter nur einmalig geladen und dann zwischengespeichert, gleiches gilt für Userränge, Foren, Benutzerrechte etc.)

Du musst in jedem Fall dafür sorgen, dass Dein MySQL-Prozess entlastet wird. Das bringt Dir dann wieder den nötigen Speed. Das mit der Rewritegeschichte habe ich übrigens schonmal für 2 Wochen getestet. Es war vollkommen egal, ob das Rewrite an oder aus war. Die Ausfälle blieben immer die gleichen.

Hier mal meine aktuelle Auslastungskurve:
[ externes Bild ]

Wie man sieht ist da einiges gebacken und ich habe einen XXL-Server dort.

Meine Top 10 an genutzten Urls:

Top 10 von 171069 URLs

# Anfragen kb URL

1 3986754 20.40% 440266 0.10% /shoutbox.php
2 189616 0.97% 6086943 1.42% /
3 178288 0.91% 5935134 1.39% /album_pic.php
4 124211 0.64% 2061650 0.48% /forum.htm
5 101862 0.52% 351040 0.08% /album_showpage.php
6 46571 0.24% 661322 0.15% /viewtopic.php
7 42256 0.22% 32486 0.01% /images/favicon.ico
8 37538 0.19% 22172 0.01% /robots.txt
9 35565 0.18% 212387 0.05% /privmsg.php
10 33475 0.17% 163059 0.04% /posting.php

Der Chat produziert bisher am meisten Last. Was mir aber egal ist, da der sich zu einem richtigen Zugpferd entwickelt hat. Vielleicht werde ich den irgendwann mal auf einen externen Server auslagern. Aber das weiß ich jetzt noch nicht. Auch wurde mir bereits nahe gelegt einen reinen MySQL-Server zu buchen.

Die Links zu "album_pic.php" sind alte Links aus Beiträgen, die ich nach und nach noch rausmachen muss. Auch werde ich in Zukunft das ganze Album komplett ersetzen mit einem eigenen erstellten. Aber das dauert noch.

Im Moment kann ich nur bestätigen, dass All-Inkl die Fehler auf die Scripte geschoben hat und damit teilweise sogar recht hatte. Aber mittlerweile fehlen mir die Stellen wo ich noch verbessern sollte. Ich erhoffe mir dass das Album noch etwas bringt, aber wirklich glaube tue ich nicht daran.

Aber mittlerweile fehlen mir die Stellen wo ich noch verbessern sollte.

die ablösung des eaccellerator mit dem aktuellen pecl::apc hat bei mir zumindestens die sporadischen peaks deutlich abgeschwächt - und trotz einsatz von modsecurity (inklusive umfangreichen ruleset) und suhosin zur optimierten sicherheit damit geholfen, die performance weiter zu steigern

Jo, neueste Config bei mir seit dem 27.10.06:
- PHP 4.4.4
- Apache 2.2.3
- PHP Cache Modul -> APC PECL PHP Accelerator
- Reduzierung des memory_limit von 50 MB auf 20 MB

Die Auslastungskurve ist eindeutig gesunken:
[ externes Bild ]

Ich hatte auch anfangs ähnliche Ausfälle, welche auf den minimalen RAm des L-Servers bei AI zurückzuführen ist.
Die Ausfälle waren fast jeden Tag.

Habe mir dann selbst Skripte gebastelt, die alle SQL-Anfragen mitloggen, welche über eine bestimmte Dauer benötigten oder mehr als x Reihen oder y Spalten oder x*y Datensätze abfragten.

Diese Anfragen habe ich mir dann angesehen (waren alle durch zusätzlihe Mods verursacht) und korrigiert bzw. einfach in der SQL-Abfrage Limits gesetzt - da waren teilw. Anfragen dabei...

Nun isses deutlich besser (einmal pro Woche mal über 500%, ansonsten fast immer unter 100% max. 200% mal kurz), allerdings konnte ich die Abfrage vom CH-Mod (alte Version 2.0.5 oder so) nicht ändern und ein Update von dieser Version auf die 2.1er Serie gibt es nicht bzw. ist ja bald Olympus da.

War eine Heidenarbeit, die sich aber lohnte. Nur ist mom der Seitenaufbau teilw. sehr langsam (SQL-Bereich 95%), obwohl in der Auslastungskurve nix davon zu sehen ist. Was kann das noch Schuld sein? (Tipp?)

Nebenbei habe ich von AI gehört, dass ein Update der Servertarife geplant ist, also neue (bessere?) Ausstattung. Mal sehen...

Jo, neueste Config bei mir seit dem 27.10.06:
- PHP 4.4.4
- Apache 2.2.3
- PHP Cache Modul -> APC PECL PHP Accelerator
- Reduzierung des memory_limit von 50 MB auf 20 MB

ich habe mit php 5.1.6 inklusive suhosin patch&extension sowie modsecurity gute erfahrung. gerade modsecurity sorgt gemeinsam mit der spidertrap für eine deutliche reduzierung unerwünschte zugriffe (und wenn ich mir das mod_s log so anschaue nimmt das inzwischen wirklich überhand).

vielleicht auch ganz interessant für eine möglichst optimale serverkonfiguration: http://www.cms-sicherheit.de/module-blo ... pid-8.html

was meinst Du mit "modsecurity"? *dummfrag*