Root Server Performance / Tuning
am 06.07.2010 - 19:38 Uhr in
Ich bin mir nicht ganz sicher, aber drupalcenter bietet zu Server-Einstellungen und Konfigurationen recht wenig Auswahl an. Daher hier eine Anfrage, in der Hoffnung, man kann hierbei mir und anderen helfen. Ich weiß ich weiß, das leidige Thema "was man nicht kann, sollte man lassen" aber jeder fängt mal klein an, deshalb hier mal der Root Server den ich betreibe und mit ach und Krach hin bekommen habe.
Ist ein Server mit
festem Arbeitsspeicher 2000 MB
dynamischem Arbeitsspeicher 4500 MB
CPU 1000 MHz
Debian 5.0 / Confixx 3.3.5 Bundle
MySQL-Datenbank 5.0.51a
PHP 5.2.6-1+lenny8
Drupal 6.17
PHP-Speicherlimit 180M
Zend Optimizer / Accelerator / Boost-Modul aktiviert
top Ausgabe
top - 20:13:18 up 17:25, 1 user, load average: 2.65, 7.92, 11.90
Tasks: 59 total, 8 running, 51 sleeping, 0 stopped, 0 zombie
Cpu(s): 57.9%us, 42.1%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4608000k total, 942960k used, 3665040k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5740 www-data 15 0 110m 70m 9m S 33.9 1.6 0:07.28 apache2
18168 www-data 16 0 98700 55m 9844 R 30.3 1.2 0:01.49 apache2
25788 mysql 15 0 390m 197m 4836 S 10.2 4.4 34:54.78 mysqld
5724 www-data 16 0 101m 64m 10m S 6.6 1.4 0:06.71 apache2
15452 www-data 16 0 81212 42m 10m S 6.3 1.0 0:04.75 apache2
10190 www-data 18 0 94256 55m 10m R 4.6 1.2 0:06.64 apache2
15437 www-data 16 0 55344 14m 7872 R 2.6 0.3 0:02.01 apache2
Tunin-Primer.sh
Uptime = 0 days 4 hrs 16 min 50 sec
Avg. qps = 513
Total Questions = 7919442
Threads Connected = 1
Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations
To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 2 sec.
You have 4121 out of 7920180 that take longer than 2 sec. to complete
Your long_query_time seems to be fine
BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html
WORKER THREADS
Current thread_cache_size = 10
Current threads_cached = 9
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine
MAX CONNECTIONS
Current max_connections = 50
Current threads_connected = 1
Historic max_used_connections = 38
The number of used connections is 76% of the configured maximum.
Your max_connections variable seems to be fine.
No InnoDB Support Enabled!
MEMORY USAGE
Max Memory Ever Allocated : 2.04 G
Configured Max Per-thread Buffers : 2.22 G
Configured Max Global Buffers : 362 M
Configured Max Memory Limit : 2.58 G
Physical Memory : 4.39 G
Max memory limit seem to be within acceptable norms
KEY BUFFER
Current MyISAM index space = 131 M
Current key_buffer_size = 320 M
Key cache miss rate is 1 : 73
Key buffer free ratio = 82 %
Your key_buffer_size seems to be fine
QUERY CACHE
Query cache is enabled
Current query_cache_size = 32 M
Current query_cache_used = 19 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 60.09 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size
SORT OPERATIONS
Current sort_buffer_size = 32 M
Current read_rnd_buffer_size = 1 M
Sort buffer seems to be fine
JOINS
Current join_buffer_size = 10.00 M
You have had 98 queries where a join could not use an index properly
join_buffer_size >= 4 M
This is not advised
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
my.cnf
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer = 320M
thread_cache_size = 128
thread_stack = 128K
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP
myisam_sort_buffer_size= 64M
max_allowed_packet= 32M
table_cache= 12000
open_files_limit = 32000
sort_buffer_size= 2M
read_buffer_size= 2M
read_rnd_buffer_size= 1536K
max_connections = 50
max_user_connections= 600
table_cache = 500
thread_cache_size = 10
connect_timeout = 10
max_allowed_packet = 16M
sort_buffer_size = 32M
thread_concurrency= 4
max_heap_table_size = 64M
#
# * Query Cache Configuration
#
query_cache_limit = 1M
query_cache_size = 16M
query_cache_type = 1
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
log = /var/log/mysql/mysql.log
Apache
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 30
#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On
#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 150
#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 2
##
## Server-Pool Size Regulation (MPM specific)
##
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 40
MaxRequestsPerChild 8000
MysqlTuner
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.51a-24+lenny4-log
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 308M (Tables: 360)
[!!] Total fragmented tables: 6
-------- Performance Metrics -------------------------------------------------
[--] Up for: 4h 21m 50s (8M q [514.489 qps], 38K conn, TX: 2B, RX: 1B)
[--] Reads / Writes: 85% / 15%
[--] Total buffers: 394.0M global + 45.6M per thread (50 max threads)
[!!] Allocating > 2GB RAM on 32-bit systems can cause system instability
[!!] Maximum possible memory usage: 2.6G (59% of installed RAM)
[OK] Slow queries: 0% (4K/8M)
[OK] Highest usage of available connections: 76% (38/50)
[OK] Key buffer size / total MyISAM indexes: 320.0M/131.4M
[OK] Key buffer hit rate: 98.7% (11M cached / 154K reads)
[OK] Query cache efficiency: 94.6% (5M cached / 5M selects)
[!!] Query cache prunes per day: 993457
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 19K sorts)
[!!] Joins performed without indexes: 98
[!!] Temporary tables created on disk: 49% (2M on disk / 5M total)
[OK] Thread cache hit rate: 98% (727 created / 38K connections)
[OK] Table cache hit rate: 49% (498 open / 1K opened)
[OK] Open file limit used: 82% (877/1K)
[OK] Table locks acquired immediately: 99% (396K immediate / 396K locks)
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
query_cache_size (> 32M)
join_buffer_size (> 10.0M, or always use indexes with joins)
tmp_table_size (> 120M)
max_heap_table_size (> 32M)
Das sind die Daten die ich zur Hand habe und jetzt auf dem Schlauch stehe, da der Server ziemlich lahm geworden ist, z.T. bis zu mehreren Minuten.
Kann mir jemand dabei helfen, den Fehler zu orten?
Danke
- Anmelden oder Registrieren um Kommentare zu schreiben
Root Server Performance / Tuning
am 06.07.2010 - 21:29 Uhr
So kann ich nichts erkennen. Was für Anwendungen sind denn auf dem Server, die Last erzeugen könnten? Das müßtest Du mal klären. Dann kommt es auf die Menge der Module an. Es gibt auch ein Modul Devel, das Dir langsame Abfragen anzeigt. Wenn Du die Drupalseite zusätzlich mal local testest und auf Fehler prüfst.
Was dauert Minuten? Das Problem kann sonst auch an den Leitungen oder an der Name-Server Auflösung liegen. Fang mal mit einem Ping-Test an und such Dir ein paar Tools.
Wenn Du Dein Problem genauer beschreiben kannst, ist es einfacher Dir zu helfen.
abend katasun, auf dem Server
am 06.07.2010 - 22:16 Uhr
abend katasun,
auf dem Server ist ausser Drupal, 6 nichts abgelegt, bis auf das Betriebssystem (s.o.). Zuvor hatte ich noch Piwik, die ich aber raus geworfen habe, auch weil dieser merklich am Server gerüttelt hat.
An Drupal- Contrib-Modulen sind ca. 90 aktiv (ausser Core-Module)
Boost (Cache Default auf 1 Std.)
#Cache Generated: 188.62 seconds (Startseite aufgerufen vor kurzem)
Ping-Test Resultat:
PING 56(84) bytes of data.
64 bytes from : icmp_seq=1 ttl=59 time=8.52 ms
64 bytes from : icmp_seq=2 ttl=59 time=8.55 ms
64 bytes from : icmp_seq=3 ttl=59 time=8.51 ms
--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2026ms
rtt min/avg/max/mdev = 8.511/8.530/8.554/0.077 ms
Das Problem ist die lange Antwortzeit. Im Moment stehe ich auf dem Schlauch, weil ich nicht weiß, an welcher so genannten Baustelle ich anfangen soll.
gargamel schrieb abend
am 06.07.2010 - 22:38 Uhr
abend katasun,
auf dem Server ist ausser Drupal, 6 nichts abgelegt, bis auf das Betriebssystem (s.o.). Zuvor hatte ich noch Piwik, die ich aber raus geworfen habe, auch weil dieser merklich am Server gerüttelt hat.
An Drupal- Contrib-Modulen sind ca. 90 aktiv (ausser Core-Module)
Boost (Cache Default auf 1 Std.)
#Cache Generated: 188.62 seconds (Startseite aufgerufen vor kurzem)
Ping-Test Resultat:
PING 56(84) bytes of data.
64 bytes from : icmp_seq=1 ttl=59 time=8.52 ms
64 bytes from : icmp_seq=2 ttl=59 time=8.55 ms
64 bytes from : icmp_seq=3 ttl=59 time=8.51 ms
--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2026ms
rtt min/avg/max/mdev = 8.511/8.530/8.554/0.077 ms
Das Problem ist die lange Antwortzeit. Im Moment stehe ich auf dem Schlauch, weil ich nicht weiß, an welcher so genannten Baustelle ich anfangen soll.
Da die Ansprechzeiten gut aussehen, liegt das Problem wahrscheinlich an der Menge der Module oder speziell an einem oder
mehreren Modulen.
Was ich jetzt machen würde.
1. Kopie local erstellen, auf einem Localhost, vielleicht in einer VmWare mit gleichem Betriebssystem. Dann das Modul
Devel installieren und die Module suchen, die die langsamen Abfragen produzieren.
Dann die problematischen Module mal auf dem Server abschalten und schauen was kommt. Dann die Log-Einträge in Drupal
abschalten.
Dann mußt Du auch nachsehen, ob Deine Probleme mit dem Templating zusammenhängen, Javascript-Probleme, falsche
Tags, etc.
Das könntest Du auch testen, indem Du eine Kopie Deiner Hauptdrupalseite in ein Unterverzeichnis kopierst und ein neues
Datenbankschema anlegst für Deine Testseite. Dann würde ich alles abschalten , bis auf den Core von Drupal und ein
Standardtheme aktivieren und die Reaktionszeiten vergleichen.
Eleganter sind ist es Tools, wie das Modul Devel zu benutzen, aber so oder so Du mußt ja das Problem lösen. Schau Dir auch
mal die Datenbank an, ob da unnötig protokolliert wird, ...
Wenn das Problem die Menge der Module ist, könnte es Sinn machen die Funktionalitäten der Webseite in einzelne Unterseiten
aufzugliedern. Das ist aber eher spekulativ, zuerst mußt Du die Ursache erforschen. Dein Thema heißt dann Skalierung und
ist auch sehr spannend.
Katasun
einen noch
am 06.07.2010 - 22:42 Uhr
Natürlich mußt Du auch schauen, ob Dein Server gerade angegriffen wird oder Du Dir ein
Rootkit, etc weggeholt hast. Oder ob Dein Server gerade für andere Aktionen von irgendwem
benutzt wird.
Das sind dann die Server-Basics, die nichts mit Drupal zu tun haben.
Katasun
ich dank dir
am 07.07.2010 - 07:42 Uhr
zuerst einmal habe ich Boost deaktiviert, weil erst nach der Aktivierung die Performance-Nachteile entstanden. Ich habe das über die Nacht beobachtet und siehe da: die Werte sind wieder im gewohntem Bereich. Auch die Werte (load avarege) mit top bzw. htop im shell hat mich darin bestärkt, mal so zu verbleiben und weiter zu beobachten.
Stand jetzt mit mysqltuner.pl: Slow queries: 0% (6K/11M)
Ich melde mich wieder, interessante Sache...
Boost deaktiviert
am 07.07.2010 - 09:00 Uhr
Das macht es ja dann einfacher, eine Lokale Kopie ziehen und dann Devel installieren und dann wirst Du
das Modul oder besser die Ursache finden.
Boost hat sich bei mir positiv bemerkbar gemacht, aber dann gibt es wohl ein Modul das Boost nicht mag
oder wo die rewrite Regeln nicht genau passen.
Katasun