Server Optimieren

S

Spinx

Member
Hallo,

ich habe bei meinem Privaten Projekt ca. 600.000 - 800.000 Seitenaufrufe täglich. Zu Stoßzeiten öfters 200.000 - 300.000 Aufrufe gleichzeitig.

Trotz ausreichender Hardware und Anbindung macht der Server in letzter Zeit Schlapp.
Anfangs mit einer "mod_fcgid: can't apply process slot for" Meldung. Nach der Umstellung auf PHP-FPM ist dies aber nicht besser geworden.

Nun würde ich gerne einiges am Server Optimieren, wüsste aber nicht wo ich Anfangen soll.

Ich poste euch erstmal alle benötigten? Infos. An den conf Files vom Indianer, MySQL und PHP wurde bisher nix verändert. Diese sind Standard

System:
Core i7 3930K 12x 3,2 GHz
64 GB DDR3 RAM
2x 3TB im RAID 1
1 GB Anbindung
Debian Squezze

MySQL
5.1.66-0+squeeze1

PHP
PHP 5.3.25-1~dotdeb.0 with Suhosin-Patch (cli) (built: May 12 2013 06:21:00)

Apache
Server version: Apache/2.2.16 (Debian)
Server built: Mar 3 2013 12:12:28
Server's Module Magic Number: 20051115:24
Server loaded: APR 1.4.2, APR-Util 1.3.9
Compiled using: APR 1.4.2, APR-Util 1.3.9
Architecture: 64-bit
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
 
Da du schon ordentlich Druck auf der Bude hast, halte ich Optimierungen an der PHP-Anbindung zwar für möglich, aber auf Dauer nicht für die entscheidende Stelle.

Wenn deine Seiten nicht hochdynamisch sind, würde ich überlegen, an welchen Stellen du mit Caching weiter kommst. Da wären zum einen PHP-Seiten, die nicht bei jedem Request neu gerechnet werden müssen, weil sich der Inhalt eh nicht ändert. Das kannst du z.B. mit varnish erledigen, bevor das PHP überhaupt anfassen muss.

Zum zweiten kannst du in der Web-Anwendung selbst sehen, ob Teile vom Template selten geändert werden und innerhalb der Anwendung gecached werden können.

Zum dritten kannst du versuchen den interpretierten PHP-Code zu cachen, so dass der PHP-Interpreter nicht jedes Mal von vorn anfängt zu rechnen. Stichworte dazu müssen andere geben, da ich in der PHP-Welt nicht unterwegs bin.
 
Spinx said:
An den conf Files vom Indianer, MySQL und PHP wurde bisher nix verändert. Diese sind Standard
Click to expand...
Zumindest bei MySQL wäre das tödlich :-)

Du meinst damit "ernsthaft", daß Du noch mit der default-Konfig aus den Standard-Paketen arbeitest?
 
Moin,

weisst Du schon woran es bei dir hapert? iotop etc... ist dir geläufig?

Vor diesem Problem stand ich ebenfalls. Bei mir bsp. war die DB Performance unterirdisch, Abhilfe schaffte hier nur das Upgrade auf MySQL 5.6 und eine SSD. Ist allerdings eine grösse Aktion.
Schon mal Tuning Primer laufen lassen? Link: http://www.day32.com/MySQL/

Schnelle Abhilfe mit relativ kurzer downtime bei vielen statischen Inhalten findest Du nur mit einem proxy wie Apache Traffic Server, Squid, Varnish. Gerade mit ATS habe ich sehr gute Erfahrungen gemacht.
 
marce said:
Du meinst damit "ernsthaft", daß Du noch mit der default-Konfig aus den Standard-Paketen arbeitest?
Click to expand...

Genau :p

Phalynx said:
Moin,

weisst Du schon woran es bei dir hapert? iotop etc... ist dir geläufig?

Vor diesem Problem stand ich ebenfalls. Bei mir bsp. war die DB Performance unterirdisch, Abhilfe schaffte hier nur das Upgrade auf MySQL 5.6 und eine SSD. Ist allerdings eine grösse Aktion.
Schon mal Tuning Primer laufen lassen? Link: http://www.day32.com/MySQL/

Schnelle Abhilfe mit relativ kurzer downtime bei vielen statischen Inhalten findest Du nur mit einem proxy wie Apache Traffic Server, Squid, Varnish. Gerade mit ATS habe ich sehr gute Erfahrungen gemacht.
Click to expand...

iotop wäre mal eine Mögllichkeit, Tuning Primer kenne ich nur vom hören, müsste über einen längeren Zeitraum laufen oder? Ich habe lediglich die Möglichkeit auf ein Upgrade auf MySQL 5.5
 
Spinx said:
iotop wäre mal eine Mögllichkeit, Tuning Primer kenne ich nur vom hören, müsste über einen längeren Zeitraum laufen oder? Ich habe lediglich die Möglichkeit auf ein Upgrade auf MySQL 5.5
Click to expand...

Debian... Hab bei mir Wheezy im Einsatz, hab das Upgrade von 5.5 auf 5.6 aber manuell durchführen müssen, da Debian 5.6 noch nicht im Angebot hat.
MySQL 5.5 ist performanter als 5.1, bei manchen Konstellationen sogar performanter als 5.6 - allerdings nicht in meinem Fall.

Tuning Primer lässt Du nur einmal durchlaufen, er überprüft deine Konfiguration und schlägt Änderungen an der Konfiguration vor.

Welche storage engine nutzt du hauptsächlich? MyISAM oder InnoDB? Wie gross ist deine DB?
 
Ich glaube die DB ist gerade mal 2GB Groß und knappt 700 Tabellen (9 Foren von Freunden, 2 Shops etc.)

Habe mal den mysqltunter laufen lassen

perl mysqltuner.pl

>> MySQLTuner 1.2.0 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[OK] Logged in using credentials from debian maintenance account.

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.66-0+squeeze1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 2G (Tables: 930)
[--] Data in InnoDB tables: 13M (Tables: 593)
[--] Data in MEMORY tables: 0B (Tables: 2)
[!!] Total fragmented tables: 695

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 4h 10m 45s (3M q [34.469 qps], 213K conn, TX: 14B, RX: 1B)
[--] Reads / Writes: 46% / 54%
[--] Total buffers: 58.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 463.8M (3% of installed RAM)
[OK] Slow queries: 0% (4/3M)
[OK] Highest usage of available connections: 16% (25/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/113.1M
[OK] Key buffer hit rate: 99.1% (52M cached / 463K reads)
[OK] Query cache efficiency: 76.5% (1M cached / 2M selects)
[!!] Query cache prunes per day: 68656
[OK] Sorts requiring temporary tables: 3% (3K temp sorts / 99K sorts)
[!!] Joins performed without indexes: 1710
[!!] Temporary tables created on disk: 31% (14K on disk / 46K total)
[OK] Thread cache hit rate: 99% (425 created / 213K connections)
[!!] Table cache hit rate: 0% (64 open / 49K opened)
[OK] Open file limit used: 11% (114/1K)
[!!] Table locks acquired immediately: 93%
[!!] InnoDB data size / buffer pool: 13.9M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
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
Increase table_cache gradually to avoid file descriptor limits
Optimize queries and/or use InnoDB to reduce lock wait
Variables to adjust:
query_cache_size (> 16M)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)
table_cache (> 64)
innodb_buffer_pool_size (>= 13M)
Click to expand...

tuning-primer.sh
-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -

MySQL Version 5.1.66-0+squeeze1 x86_64

Uptime = 1 days 4 hrs 37 min 27 sec
Avg. qps = 34
Total Questions = 3567742
Threads Connected = 3

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.1/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 NOT enabled.
Current long_query_time = 10.000000 sec.
You have 4 out of 3567763 that take longer than 10.000000 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.1/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 5
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 151
Current threads_connected = 3
Historic max_used_connections = 25
The number of used connections is 16% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
Current InnoDB index space = 8 M
Current InnoDB data space = 13 M
Current InnoDB buffer pool free = 0 %
Current innodb_buffer_pool_size = 8 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 109 M
Configured Max Per-thread Buffers : 405 M
Configured Max Global Buffers : 42 M
Configured Max Memory Limit : 447 M
Physical Memory : 11.73 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 113 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 113
Key buffer free ratio = 80 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 16 M
Current query_cache_used = 10 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 62.57 %
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 = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 1737 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 64 tables
Current table_definition_cache = 256 tables
You have a total of 1548 tables
You have 65 open tables.
Current table_cache hit rate is 0%
, while 101% of your table cache is in use
You should probably increase your table_cache
You should probably increase your table_definition_cache value.

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 16 M
Of 32304 temp tables, 31% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 428989 : 1
You have a high ratio of sequential access requests to SELECTs
You may benefit from raising read_buffer_size and/or improving your use of indexes.

TABLE LOCKING
Current Lock Wait ratio = 1 : 13
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.
Click to expand...

Ich habe das ganze jetzt mal in einer ruhigen Minute ausgeführt. Fehler?
 
Einen Haufen! Bei einem 64 GB Server hast Du sehr viele Möglichkeiten.

Die MySQL Werte sind allesamt zu klein. Die 2 GB DB kannst Du ruhigen Gewissens komplett in den Speicher laden lassen.

Dazu solltest Du innodb_buffer_pool_size auf 8 GB erhöhen:
innodb_buffer_pool_size = 8GB

Sinnvoll wären auch diese Werte:
table_cache = 4096
sort_buffer_size = 256K
read_buffer_size = 256K
key_buffer_size = 4096M
query_cache_limit = 1024M
query_cache_size = 2048M
query_cache_type=1


Zusätzlich kannst Du den temporären Speicher von der Festplatte in den Ram schieben:

Mounte dazu die disk:
mount -t tmpfs -o size=512M none /var/tmpfs

Damit erstellst Du eine solche ramdisk mit 512MB, danach solltest Du das in die my.cnf einfügen bzw. ändern:
tmpdir = /var/tmpfs
tmp_table_size=32M
max_heap_table_size=32M



Ich bin auch nach wie vor der Meinung das Du einen reverse proxy mit einem grossen cache im RAM dringend brauchst, damit entlastest Du Apache und nutzt deinen massiven Speicher besser aus.
 
Last edited by a moderator:
Ein kleiner aber entscheidender Hinweis am Rand:
Generell ist unter Linux-Distros die access-time der Dateien aktiv, ein Zugriff (sei es aus dem Disk-Cache bedienbar oder nicht) verursacht also mindestens einen Schreibzugriff was die Systemleistung katastrophal nach unten zieht.
Es ist also oft empfehlenswert die Mount-Optionen data=writeback und noatime zu setzen, generell fällt die Disk IO eines belasteten Webservers damit um über 50%.
 
Zusätzlich zur ext4-Mountoption "noatime" kann auch noch "nordiratime" gesetzt werden.
Vor dem Setzen von "data=writeback" sollte man den Writeback-Mode aber auch noch via tune2fs aktivieren, sonst fährt der Server nicht mehr hoch. ;)
 
You must log in or register to reply here.
Back
Top