A small Portal in one place is just a few thousand PVS, and it is often unavailable now. Log prompt: {code...} a cloud's 4-core 4G120G SSD cloud disk. Centos7 + Nginx + PHP5.4 + RDS (Mysql5.6 ). Opened memcached is mainly php hanging, PHP-FPM... a small portal, also thousands of pv, suddenly now often don't open.
Log prompt:
WARNING: [pool www] child 13760, script '/home/wwwroot/luntan/forum.php' (request: "GET /forum.php") execution timed out (77.310180 sec), terminating
A cloud SSD with 4 cores, 4G, 120G.
Centos 7 + Nginx + PHP5.4 + RDS (Mysql 5.6 ). Memcached
Mainly or php hung, PHP-FPM parameters are as follows:
pm = dynamicpm.max_children = 180pm.start_servers = 100pm.min_spare_servers = 60pm.max_spare_servers = 180pm.max_requests = 3096pm.process_idle_timeout = 10srequest_terminate_timeout = 60request_slowlog_timeout = 0
From the performance monitoring point of view, when the website is opened for a longer period of time, the database reading also gets longer. do you want to adjust the database parameters? However, after reading the database monitoring, the maximum iops, connection usage, and memory usage of all parameters is about 80%.
I can't figure it out. ask for help.
Reply content:
A small Portal in one place is just a few thousand PVS, and it is often unavailable now.
Log prompt:
WARNING: [pool www] child 13760, script '/home/wwwroot/luntan/forum.php' (request: "GET /forum.php") execution timed out (77.310180 sec), terminating
A cloud SSD with 4 cores, 4G, 120G.
Centos 7 + Nginx + PHP5.4 + RDS (Mysql 5.6 ). Memcached
Mainly or php hung, PHP-FPM parameters are as follows:
pm = dynamicpm.max_children = 180pm.start_servers = 100pm.min_spare_servers = 60pm.max_spare_servers = 180pm.max_requests = 3096pm.process_idle_timeout = 10srequest_terminate_timeout = 60request_slowlog_timeout = 0
From the performance monitoring point of view, when the website is opened for a longer period of time, the database reading also gets longer. do you want to adjust the database parameters? However, after reading the database monitoring, the maximum iops, connection usage, and memory usage of all parameters is about 80%.
I can't figure it out. ask for help.
This situation seems like php resources are exhausted, so it cannot handle new situations, and then it goes down.
However, thousands of PVS cannot produce such a result. Thousands of UVS are still possible, or cc attacks.
You can:
Thoroughly solve server load balancer problems
Increase the number of php-fpm sub-processes and the maximum number of requests to temporarily solve the problem.