Lange Wartezeiten vor der Antwort des Apache 2.2-Servers (Gentoo LAMP)

Ich habe kürzlich die Website eines Kunden (unter Verwendung des konkreten CMS) auf einen VPS mit Gentoo, Apache 2.2, PHP5 und MySQL 5 verschoben und festgestellt, dass die Antwortzeiten für Apache ziemlich schlecht sind (auf dem alten Server war es dasselbe). , manchmal bis zu 8-9 Sekunden, aber häufiger zwischen 300 ms und 3 Sekunden (in Richtung 300 ms macht es mir nichts aus). Ich weiß, dass es keine Netzwerklatenz ist, da der Server einen Ping (von meinem Standort aus) von ca. 30 ms hat.

Hier ist ein Beispiel für die Zeiten (Sie können sehen, dass es nach dem ersten Warten bissig ist):

Ich verwende APC (obwohl ich nicht sicher bin, ob das richtig funktioniert ...) und SuExec. Apache-Module sind:

 core_module (static)
 authn_file_module (static)
 authn_default_module (static)
 authz_host_module (static)
 authz_groupfile_module (static)
 authz_user_module (static)
 authz_default_module (static)
 auth_basic_module (static)
 include_module (static)
 filter_module (static)
 deflate_module (static)
 log_config_module (static)
 env_module (static)
 expires_module (static)
 headers_module (static)
 setenvif_module (static)
 version_module (static)
 ssl_module (static)
 mpm_prefork_module (static)
 http_module (static)
 mime_module (static)
 status_module (static)
 autoindex_module (static)
 asis_module (static)
 info_module (static)
 suexec_module (static)
 cgi_module (static)
 negotiation_module (static)
 dir_module (static)
 actions_module (static)
 userdir_module (static)
 alias_module (static)
 rewrite_module (static)
 so_module (static)
 suphp_module (shared)

und PHP-Module sind:

bcmath
calendar
ctype
curl
db
dbase
domxml
exif
ftp
gd
gettext
iconv
imap
mbstring
mcrypt
mime_magic
mysql
openssl
overload
pcre
posix
session
standard
sysvsem
sysvshm
tokenizer
xml
xslt
zlib

Ich habe gzip für alle relevanten Dateien aktiviert.

Apache wird mit Prefork ausgeführt und die Einstellungen in httpd.conf sind:

<IfModule prefork.c>
StartServers         10
MinSpareServers      10
MaxSpareServers      20
MaxClients           250
MaxRequestsPerChild  4000
</IfModule>

HostnameLookups Off

Ich habe festgestellt, dass Seiten, die (glaube ich) datenbankintensiv sind, wie das CMS-Dashboard, normalerweise langsamer sind. Ich dachte, dies könnte bedeuten, dass MySQL optimiert werden könnte. Ich habe mich auch über Apache-Module gewundert - ich bin verwirrt zwischen mod_php5, mod_cgi, mod_fastcgi usw. usw. - es gibt im ganzen Internet widersprüchliche Ratschläge, welche am besten zu verwenden sind.

Hier ist die Ausgabe von MySQLTuner :

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.44-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 35M (Tables: 161)
[!!] Total fragmented tables: 15

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3d 21h 44m 16s (293K q [0.868 qps], 1K conn, TX: 135M, RX: 90M)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 58.0M global + 1.6M per thread (100 max threads)
[!!] Maximum possible memory usage: 219.7M (93% of installed RAM)
[OK] Slow queries: 0% (0/293K)
[OK] Highest usage of available connections: 2% (2/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/20.9M
[OK] Key buffer hit rate: 99.6% (5M cached / 21K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 3K sorts)
[!!] Temporary tables created on disk: 47% (2K on disk / 5K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 6% (64 open / 1K opened)
[OK] Open file limit used: 12% (128/1K)
[OK] Table locks acquired immediately: 100% (356K immediate / 356K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (>= 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)

Ich habe festgestellt, dass beim Laden einer DB-lastigen Seite die CPU-Auslastung um 57% gestiegen ist (mit top). Für mich bedeutet dies, dass entweder schlecht optimiertes MySQL-Material vorhanden ist oder dass Caching unbedingt erforderlich ist, um dieses Setup zu beschleunigen.

Jede Hilfe wäre sehr dankbar!

Wissen Sie genau, woran die Apache-Worker-Prozesse hängen bleiben? Versuchen Sie dies, um zu sehen:

mkdir /strace; ps auxw | grep httpd | awk '{print"-p " $2}' | xargs strace -o /strace/strace.log -ff -s4096 -r

Laden Sie ein paar neue (dh nicht lokal zwischengespeicherte) Seiten in Ihren Browser, STRG + C, um strace zu stoppen, und sortieren Sie die strace.logs nach der für jeden Anruf aufgewendeten Zeit:

for i in `ls /strace/*`; do echo $i; cat $i | cut -c11-17 | sort -rn | head; done

Zeigen Sie alle strace.logs mit Aufrufen von mehr als 1,0 Sekunden an und suchen Sie nach der Zeit aus der Ausgabe des vorherigen Befehls. Dies zeigt Ihnen den genauen Schritt, an dem sie hängen bleiben.

Haben Sie per Änderung eine Firewall wie CSF installiert? Ich habe das gleiche Problem bei einem VPS gesehen. Beim Debuggen von httpd-Prozessen mit strace dauerte es bei gettimeofday-Anrufen bis zu 5 Sekunden oder länger. Seltsamerweise habe ich dies auf CSF eingegrenzt, das versucht hat, die venet0-Schnittstelle zu filtern, eine Loopback-Schnittstelle in OpenVZ- oder Virtuozzo-Containern. Das Setzen dieses Parameters in /etc/csf/csf.conf hat es meistens für mich behoben:

"ETH_DEVICE_SKIP = "venet0,lo"

Ich sage meistens, weil manchmal noch 500-1000 ms auf den Verbindungsaufbau warten, aber es ist eine große Verbesserung von 5000+.

Hier finden Sie eine hervorragende Einführung / Anleitung zur Fehlerbehebung bei solchen Problemen mithilfe von strace.

Maximum possible memory usage: 219.7M (93% of installed RAM)

Dies muss eine Low-End-VPS-Box sein?

• Möglicherweise möchten Sie Ihre MySQL-Einstellungen herunterwählen
• Optimieren Sie Apache, um die Anzahl der httpd-Gabeln zu verringern
• Überprüfen Sie, ob Sie das Austauschen aktivieren können
• Ist APC so eingestellt, dass Opcodes automatisch zwischengespeichert werden? Überprüfen Sie dies mit dem mit apc verteilten Skript 'apc.php'.

Sie müssen Netzwerk, Apache, MySQL und PHP als Quellen für die Latenz auseinander ziehen.

Wenn Sie ein Bild schnell aus dem Apache ziehen können (sehr kurze Zeit bis zum ersten Byte), sind das Netzwerk und der Apache normalerweise in Ordnung.

Wenn Sie eine Seite nur mit einer phpinfo () -Anweisung abrufen können, ist normalerweise PHP in Ordnung (möglicherweise sind einige Anpassungen erforderlich).

Wenn Sie einen einfachen DB-Verbindungstest schreiben und dieser schnell ist, ist diese Schicht normalerweise auch in Ordnung.

Zuletzt ziehen Sie die Anwendungsseite. Wenn es langsam ist, liegt das Problem in der Anwendungsverarbeitung. Während die Optimierung hilfreich sein kann, ist dies weitaus schwieriger zu lösen.

Ohne Profilierung der Anwendung kann es schwierig sein, das Problem zu finden. Tools wie NewRelic können bei diesem Problem helfen, sind jedoch keine Heilung.

Verfügt Ihre App über ein internes Debugging, um anzuzeigen, wo Zeit verbracht wird?

Ich schlage vor, eine Messung der Renderzeit hinzuzufügen und zu überprüfen, wie lange der Server benötigt, um die reine HTML-Seite zu rendern. Dann wissen Sie, ob es im CMS oder anderswo ist. Ich wette mein 2cent ist nicht deine Serverkonfiguration. / Maddin