ispCP - Board - Support
Response zu lange - Printable Version

+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega International Area (/forum-22.html)
+--- Forum: German Corner (/forum-26.html)
+--- Thread: Response zu lange (/thread-4125.html)

Pages: 1 2


Response zu lange - the_condor - 08-26-2008 10:29 PM

Hallo Gemeinde,

ich habe das Problem das die Response von php5-cgi einfach zu lange dauert,ich bin am überlegen das ganze wieder als mod_php laufen zu lassen.
Bevor ich jedoch solche sachen mache würde ich mir gerne Hilfe bei euch holen.

Mein System:
1,2 GHZ, 1 GB RAM, Sys debian etch 32bit, php 5.2.6 dot, ispCP RC4, mysql 5.0.67

Das Hauptproblem ist das der Server eine hohe CPU Last bekommt und das der load in die höhe steigt.

Auszug der TOP:
Code:
20954 vu2002    20   0 55800  15m  10m R 11.0  1.6   0:54.46 php5-cgi
20955 vu2001   20   0 54120  14m  10m S  7.3  1.5   1:05.60 php5-cgi

Dateien wie fastcgi_ispcp.conf wurden nicht geändert, ich habe jetzt mod_info Aktiviert um zu sehen wo die hohe Last herkommt, welches php Script genau diese Probs macht. Jedoch kann ich mit den ganzen Daten von mod_info nix anfangen.

Quote: Total accesses: 1344 - Total Traffic: 3.1 MB
CPU Usage: u.58 s.27 cu0 cs0 - .153% CPU load
2.43 requests/sec - 5.6 kB/second - 2384 B/request
1 requests currently being processed, 9 idle workers

Meine Frage wäre, wie kann ich das am besten beheben oder wie kann ich für diesen einen Host mod_php zur Verfügung stellen?


Vielen Dank für jegliche Hilfe


RE: Response zu lange - gOOvER - 08-26-2008 10:38 PM

Naja, die RC4 ist schon ein wenig alt. Da wurde was an der fcgi geändert, ich glaube in RC5.


RE: Response zu lange - the_condor - 08-26-2008 11:05 PM

Danke g00vER für deine schnelle Antwort,

ich konnte weder in der change log von RC5 oder auch RC6 erkennen das an der fastcgi was geändert worden ist.
Ich habe das von RC2 auf RC 4 feststellen können, aber in dem jetzigen fall nicht.

Ein Hauptproblem ist auch die Forensoftware und deren Hacks, dennoch eine andere Idee ?


RE: Response zu lange - ephigenie - 08-27-2008 12:06 AM

was ist bei dir hohe cpu last ?
Hast du einen php - cache


RE: Response zu lange - the_condor - 08-27-2008 12:22 AM

Hallo ephigenie,
bei mir ist eine hohe last wenn er über 63 % geht und von da aus denn auf die 100 % zu steuert.

Normale last ist bei mir wenn er zwischen 0 % und 63 % hin und her schwangt!

Was verstehst Du unter:
Quote:Hast du einen php - cache

Meinst du sowas wie Zend Opti oder der ecc ?

Hier mal eine Aktuelle top Ausgabe:
Code:
top - 16:20:50 up 22:55,  2 users,  load average: 10.40, 6.02, 2.75
Tasks: 204 total,  11 running, 192 sleeping,   0 stopped,   1 zombie
Cpu(s): 12.1%us,  2.1%sy,  1.2%ni, 84.0%id,  0.4%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:    994476k total,   903596k used,    90880k free,    61980k buffers
Swap:  1044208k total,        4k used,  1044204k free,   646548k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2532 mysql     20   0 54192  36m 5120 S 35.2  3.7  87:55.11 mysqld
14939 vu2002    20   0 57296  12m 5592 R 11.7  1.3   0:17.72 php5-cgi
9348 vu2002    20   0 55084  14m 9880 R  7.8  1.5   1:05.79 php5-cgi
14938 vu2002    20   0 54188  11m 8048 R  7.8  1.2   0:16.44 php5-cgi
14941 vu2002    20   0 54176  10m 6756 R  7.8  1.1   0:16.40 php5-cgi
14942 vu2002    20   0 54000 9084 5488 R  7.8  0.9   0:16.30 php5-cgi
14944 vu2002    20   0 53988 9192 5608 R  7.8  0.9   0:14.66 php5-cgi
14945 vu2002    20   0 55360  10m 6152 R  7.8  1.1   0:14.36 php5-cgi
15573 vu2002    20   0 53976 7776 4204 R  7.8  0.8   0:01.06 php5-cgi
15574 vu2002    20   0 54172 9592 5820 R  7.8  1.0   0:01.24 php5-cgi
9349 vu2002    20   0 55068  15m  11m R  5.9  1.6   1:05.10 php5-cgi
14859 www-data  20   0 25304 4952 1448 S  3.9  0.5   0:00.02 apache2
14871 www-data  20   0 25296 4952 1448 S  3.9  0.5   0:00.02 apache2
14885 www-data  20   0 25164 4936 1444 S  3.9  0.5   0:00.02 apache2
14895 www-data  20   0 25164 4936 1444 S  3.9  0.5   0:00.02 apache2
14898 www-data  20   0 25304 4952 1448 S  3.9  0.5   0:00.02 apache2
14901 www-data  20   0 25304 4952 1448 S  3.9  0.5   0:00.02 apache2

##
Code:
top - 16:25:52 up 23:00,  2 users,  load average: 6.80, 4.47, 2.83
Tasks: 224 total,   9 running, 215 sleeping,   0 stopped,   0 zombie
Cpu(s): 90.7%us,  9.3%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    994476k total,   875612k used,   118864k free,    60864k buffers
Swap:  1044208k total,        4k used,  1044204k free,   584952k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2532 mysql     20   0 54192  36m 5120 S 59.8  3.8  88:38.04 mysqld
9348 vu2002    20   0 54824  14m  10m R  6.6  1.5   1:12.75 php5-cgi
15844 vu2002    20   0 53824 7984 4604 R  6.0  0.8   0:04.00 php5-cgi
14939 vu2002    20   0 58116  14m 7660 R  4.6  1.5   0:24.44 php5-cgi
9349 vu2002    20   0 58708  19m  11m R  4.0  2.0   1:12.56 php5-cgi
15843 vu2002    20   0 57724  11m 4868 R  4.0  1.2   0:03.94 php5-cgi
14938 vu2002    20   0 58164  16m 9608 R  3.3  1.7   0:23.38 php5-cgi
15942 vu2002    20   0 57724  11m 4824 R  3.3  1.2   0:03.98 php5-cgi
15943 vu2002    20   0 57724  11m 4648 R  3.3  1.2   0:03.90 php5-cgi
15956 vu2002    20   0 57724  11m 4584 S  3.3  1.2   0:03.54 php5-cgi
3183 root      20   0  6540 4760 1552 S  0.7  0.5   0:05.64 munin-node
16462 vu2002    20   0 53720 6764 3496 S  0.7  0.7   0:00.02 php5-cgi
3150 teamspea  20   0 79828 2164 1480 S  0.3  0.2   1:31.28 server_linux
3405 root      20   0 88544 3876 1412 S  0.3  0.4   1:50.95 python2.4
    1 root      20   0  1940  640  548 S  0.0  0.1   0:01.58 init
##
Code:
Document Path:          /forum/index.php
Document Length:        101336 bytes

Concurrency Level:      100
Time taken for tests:   280.695376 seconds
Complete requests:      1000
Failed requests:        2
   (Connect: 0, Length: 2, Exceptions: 0)
Write errors:           0
Keep-Alive requests:    0
Total transferred:      101573004 bytes
HTML transferred:       101336004 bytes
Requests per second:    3.56 [#/sec] (mean)
Time per request:       28069.537 [ms] (mean)
Time per request:       280.695 [ms] (mean, across all concurrent requests)
Transfer rate:          353.38 [Kbytes/sec] received

Schon bissl komisch das ganze

mfg
the_condor


RE: Response zu lange - ephigenie - 08-27-2008 12:28 AM

ab wurde mit welchen parametern aufgerufen ? -n 1000 <url> und sonst ?


RE: Response zu lange - the_condor - 08-27-2008 12:31 AM

ab -n 1000 -c 100 -k http://www.ltd./index.php

erzeugt auch die hohe Last, das ist klar:

Code:
top - 16:33:14 up 23:07,  2 users,  load average: 9.32, 8.50, 5.45
Tasks: 215 total,  11 running, 204 sleeping,   0 stopped,   0 zombie
Cpu(s): 92.7%us,  7.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:    994476k total,   713512k used,   280964k free,    47288k buffers
Swap:  1044208k total,       40k used,  1044168k free,   433468k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2532 mysql     20   0 54448  37m 5120 S 12.6  3.8  91:51.54 mysqld
17784 vu2002    20   0 57472  11m 4636 R 10.6  1.2   0:01.44 php5-cgi
14939 vu2002    20   0 57864  15m 7936 R  9.0  1.5   0:44.46 php5-cgi
9348 vu2002    20   0 58464  18m  10m R  8.6  1.9   1:31.69 php5-cgi
14938 vu2002    20   0 58040  17m 9.8m R  8.3  1.8   0:43.52 php5-cgi
9349 vu2002    20   0 58448  19m  11m R  8.0  2.0   1:32.57 php5-cgi
15843 vu2002    20   0 57676  14m 7260 R  8.0  1.5   0:23.80 php5-cgi
15844 vu2002    20   0 57676  12m 6060 R  8.0  1.3   0:24.08 php5-cgi
15942 vu2002    20   0 57620  14m 7376 R  8.0  1.5   0:23.60 php5-cgi
15943 vu2002    20   0 57472  12m 5444 R  8.0  1.3   0:24.42 php5-cgi
17783 vu2002    20   0 57472  11m 4836 R  8.0  1.2   0:01.48 php5-cgi

edit//

Hier mal das ganze Ergebniss
Code:
Benchmarking *********** (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        Apache
Server Hostname:        ***********
Server Port:            80

Document Path:          /index.php
Document Length:        169832 bytes

Concurrency Level:      100
Time taken for tests:   1006.846339 seconds
Complete requests:      1000
Failed requests:        920
   (Connect: 0, Length: 920, Exceptions: 0)
Write errors:           0
Keep-Alive requests:    0
Total transferred:      170748455 bytes
HTML transferred:       170511455 bytes
Requests per second:    0.99 [#/sec] (mean)
Time per request:       100684.631 [ms] (mean)
Time per request:       1006.846 [ms] (mean, across all concurrent requests)
Transfer rate:          165.61 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.2      0      12
Processing: 12026 95908 25740.3 100438  151656
Waiting:    11929 95800 25742.5 100330  151487
Total:      12035 95909 25738.0 100438  151656

Percentage of the requests served within a certain time (ms)
  50%  100438
  66%  107825
  75%  112222
  80%  115420
  90%  126821
  95%  131656
  98%  140701
  99%  144154
100%  151656 (longest request)



RE: Response zu lange - ephigenie - 08-27-2008 12:48 AM

Ok

1) Dein Flaschenhals ist zuallerersteinmal deine MySQL
2) ~350kbyte / s sind jetzt nicht ungewöhnlich

Shopsystem bei mir DB - Bound (schaut ähnlich aus) :
Quote:Document Path: /index.php
Document Length: 103455 bytes

Concurrency Level: 1
Time taken for tests: 211.200733 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 103806000 bytes
HTML transferred: 103455000 bytes
Requests per second: 4.73 [#/sec] (mean)
Time per request: 211.201 [ms] (mean)
Time per request: 211.201 [ms] (mean, across all concurrent requests)
Transfer rate: 479.98 [Kbytes/sec] received


Joomla nicht ganz so db bound (aber ohne caching) :
Quote:Document Path: /index.php
Document Length: 12806 bytes

Concurrency Level: 10
Time taken for tests: 159.622590 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 13291000 bytes
HTML transferred: 12806000 bytes
Requests per second: 6.26 [#/sec] (mean)
Time per request: 1596.226 [ms] (mean)
Time per request: 159.623 [ms] (mean, across all concurrent requests)
Transfer rate: 81.31 [Kbytes/sec] received

Da schau mal einer an ... fast 40% schneller (gemessen an req/s)

Zum Vergleich dieses Forum mit lighttpd + php5-cgi (+eA)
Quote:Document Path: /forum/index.php
Document Length: 41579 bytes

Concurrency Level: 10
Time taken for tests: 117.942568 seconds
Complete requests: 1000
Failed requests: 204
(Connect: 0, Length: 204, Exceptions: 0)
Write errors: 0
Total transferred: 42073664 bytes
HTML transferred: 41576750 bytes
Requests per second: 8.48 [#/sec] (mean)
Time per request: 1179.426 [ms] (mean)
Time per request: 117.943 [ms] (mean, across all concurrent requests)
Transfer rate: 348.36 [Kbytes/sec] received

Die Werte sind nicht so unüblich.
Bitte mach einen Vergleichstest mit mod_php und beachte dabei die Serverload.

Bedenke bei deinem Test auch, dass in der Fastcgi Config -maxClassProcesses 10
Standard ist -> sprich >10 php requests unter einem User werden in die queue gestopft und erst nacheinander abgearbeitet. Vorteil an der Sache :
worker_mpm kann wunderbar mit so einer queue umgehen.
prefork_mpm kann es nicht - sondern würde für jede deiner Verbindungen einen Apache forken -> schau dann mal was deine anderen Domains zu machen Wink

Ergo : brauchst du mehr konkurrent connections auf einer domain musst du im Fastcgi noch ein wenig rumspielen. Aber bei >10 konkurrenten php zugriffen komm ich wieder auf den Punkt zurück - das da i.d.R. erstmal deine DB versagen wird.
Und das deine Mysql unkonfiguriert ist, sehe ich direkt mal an ihrem Speicherverbrauch Smile für 100 concurrent requests sollte da dann auch durchgehend auf performance getrimmt werden.
ispCP ist nicht die holy cow die dir alles und jedes abnimmt.
Aber lange Wartezeiten auf deine Db erzeugen requeststau beim php - damit mehr parallele prozesse (die alle auf die db warten) und damit mehr load ...

Zu guter letzt ist noch anzumerken - man sollte nat. nicht Äpfel mit Birnen vergleichen - unterschiedliche Applikationen = unterschiedlichen Anforderungen.

Der Punkt ist der - dass grade unter Hochlast am Ende ein ispCP mit fastcgi und apache mpm-worker und ordentlich konfigurierter DB deutlich stabiler läuft als ein prefork apache mit mod_php.
Hochlast = viele konkurrente unterschiedliche Zugriffe.
Pi * Daumen sagt man das fastcgi/php vs. mod_php etwa 90-95% der Leistung hat.
Aber dazu kommt halt noch - das mpm-worker deutlich schneller & Laststabiler bei der Auslieferung vieler statischer Dateien ist als prefork apache und zudem einen riesigen Unterschied in Bezug auf die Sicherheit deiner Hostingumgebung macht (www-data vs. vu20xx User)


RE: Response zu lange - the_condor - 08-27-2008 01:17 AM

Super ephigenie für dein Demo hier Wink

Das mysql auch eins meiner Probleme ist das dachte ich mir schon und das sieht man ja auch. Ich habe bei mysql noch nicht viel in der my.cnf eingestellt

Hier mal meine Einstellung:
Code:
#bind-address           = 127.0.0.1
#skip-networking
#
# * Fine Tuning
#
key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 128K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover          = BACKUP
table_cache            =  580
sort_buffer_size       = 1M
read_rnd_buffer_size = 128k
max_heap_table_size = 25M
low_priority_updates=1
concurrent_insert=2
# * Query Cache Configuration
#
query_cache_limit       = 7M
query_cache_size        = 8M
#
# * Logging and Replication
log-slow-queries = /var/log/mysql/slow-query.log
long_query_time = 4
log-queries-not-using-indexes
skip_innodb

Hier mal meine Ausgabe von dem tuner Script
Code:
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 4 sec.
You have 63050 out of 2342104 that take longer than 4 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 = 8
Current threads_cached = 7
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 1
Historic max_used_connections = 17
The number of used connections is 17% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 59 M
Configured Max Per-thread Buffers : 150 M
Configured Max Global Buffers : 34 M
Configured Max Memory Limit : 184 M
Physical Memory : 971.16 M
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 178 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 27
Key buffer fill ratio = 65.00 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 8 M
Current query_cache_used = 1 M
Current query_cache_limit = 7 M
Current Query cache Memory fill ratio = 19.50 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 1 M
Current read_rnd_buffer_size = 128 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 97 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 = 1270 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
You currently have open more than 75% of your open_files_limit
You should set a higher value for open_files_limit in my.cnf

TABLE CACHE
Current table_cache value = 580 tables
You have a total of 611 tables
You have 580 open tables.
Current table_cache hit rate is 5%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 25 M
Current tmp_table_size = 32 M
Of 24249 temp tables, 3% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 1477 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 437
You may benefit from selective use of InnoDB.

Da muß ich noch 2-3 änderungen vornehmen!

Zu mod_php steht der Eintrag ja auch unter ispcp.conf , wo kann ich das ganze ändern das es unter mod_php läuft?


RE: Response zu lange - the_condor - 08-27-2008 02:10 AM

ich gehe mal davon aus das ich die Änderung bezüglich des fastcgi unter /var/www/fcgi/domain.ltd/php5-fcgi-starter erledigen kann oder muss ich die fastcgi_ispcp.conf auch noch ausklammern?

Inhalt ausklammern und nur
PHPRC= und hier der Pfad zur php.ini ?
und
exec /usr/bin/php neuen Pfad angeben?

Oder wie habt Ihr euch das gedacht?

edit:// SQL Thema
hier mal
Code:
SHOW STATUS LIKE 'Qcache%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Qcache_free_blocks      | 35      |
| Qcache_free_memory      | 9052464 |
| Qcache_hits             | 2001257 |
| Qcache_inserts          | 560431  |
| Qcache_lowmem_prunes    | 371     |
| Qcache_not_cached       | 14576   |
| Qcache_queries_in_cache | 459     |
| Qcache_total_blocks     | 997     |
+-------------------------+---------+
8 rows in set (0.00 sec)

Also an der mysql wurde so noch nix geändert, was ich weiß das die lowmem_prunes und Qcache_free_blocks nicht solch einen Wert haben dürfen, der ist meiner Meinung nach zu hoch.

mfg
the_condor