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.
```
# 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.
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.
--
Christopher Faulet
