Hi Christopher. On 04.05.20 11:28, Christopher Faulet wrote: > Le 03/05/2020 à 09:52, Aleksandar Lazic a écrit : >> Hi. >> >> I play a little bit with proto fcgi and see something what I don't >> understand. >> >> Hopefully someone can explain it a bit. >> >> My php-fpm have the following settings. >> >> ``` >> pm = dynamic >> pm.max_children = 10 >> pm.min_spare_servers = 4 >> pm.start_servers = 5 >> pm.max_spare_servers = 6 >> pm.max_requests = 500 >> ``` >> >> The haproxy server line have the following settings. >> Btw: is fullconn deprecated or removed in 2.2 because it's still in the doc? >> I don't know if the health check connection is counted in the maxconn value >> or not, is it? >> >> ``` >> server server1 127.0.0.1:9000 proto fcgi check maxconn 9 minconn 5 maxqueue 0 >> ``` >> >> Now my assumption is that I should never get this message in the php-fpm >> output because maxconn is 9 and pm.max_children = 10 but I got it. >> >> >> ``` >> [03-May-2020 07:27:44] WARNING: [pool www] server reached pm.max_children >> setting (10), consider raising it >> ``` >> >> This means that the connections to php-fpm are higher then maxcon configured >> in haproxy and this is what I not understand. >> Here some haproxy logs from the overload. >> > > > Hi Aleks, > > I've made some tests on my side and the fork politic of php-fpm seems to be a > bit strange > because with the same config and the check disabled, I've the same warning > and 10 php-fpm > children with only 3 clients. When I checked the opened connections, I only > have 4 connections. > So there is no reason to have 10 children.
Thank you for your time answer. >> ``` >> # normal run >> 127.0.0.1:36466 [03/May/2020:07:37:55.995] myproxy phpservers/server1 >> 0/69/0/2/71 200 66318 - - ---- 50/50/8/4/0 0/9 "GET /pinf.php HTTP/1.1" >> 127.0.0.1:36462 [03/May/2020:07:37:56.000] myproxy phpservers/server1 >> 0/66/0/2/68 200 66318 - - ---- 50/50/7/4/0 0/8 "GET /pinf.php HTTP/1.1" >> 127.0.0.1:36488 [03/May/2020:07:37:56.002] myproxy phpservers/server1 >> 0/66/0/2/109 200 66318 - - ---- 50/50/6/4/0 0/8 "GET /pinf.php HTTP/1.1" >> 127.0.0.1:36470 [03/May/2020:07:37:56.004] myproxy phpservers/server1 >> 0/106/0/2/109 200 66318 - - ---- 50/50/5/4/0 0/8 "GET /pinf.php HTTP/1.1" >> 127.0.0.1:36546 [03/May/2020:07:37:56.007] myproxy phpservers/server1 >> 0/106/0/2/108 200 66318 - - ---- 50/50/4/4/0 0/8 "GET /pinf.php HTTP/1.1" >> >> # I think this a queued request >> 127.0.0.1:36576 [03/May/2020:07:37:55.334] myproxy phpservers/server1 >> 0/69/0/1402/1471 200 66318 - - ---- 50/50/3/3/0 0/38 "GET /pinf.php HTTP/1.1" >> 127.0.0.1:36484 [03/May/2020:07:37:55.363] myproxy phpservers/server1 >> 0/41/0/1402/1443 200 66318 - - ---- 50/50/3/3/0 0/39 "GET /pinf.php HTTP/1.1" >> > > Here, these both requests were not queued more longer than others (time spent > in queue is the second value, 69 and 41). But php-fpm was a quite long to > response. 1.4 seconds to have the response headers. > >> 127.0.0.1:36480 [03/May/2020:07:37:55.363] myproxy phpservers/server1 >> 0/41/0/2402/2444 200 66318 - - ---- 50/50/1/1/0 0/40 "GET /pinf.php HTTP/1.1" >> 127.0.0.1:36486 [03/May/2020:07:37:55.363] myproxy phpservers/server1 >> 0/42/0/2402/2444 200 66318 - - ---- 50/50/0/0/0 0/41 "GET /pinf.php HTTP/1.1" > > And here, 2.4 seconds. It may be the reason why the health checks timed out. This could be because php-fpm forks childs. > So maybe there is too many opened connections. It may be a problem with idle > connections. > But you should not trust php-fpm warnings :) Monitor connections really > established instead. Thanks I will go that way.