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.

Reply via email to