Czy aplikacja Rails jest normalna, aby zachować tak dużo wolnych połączeń Puma i Postgres?

Question

Mam aplikację Rails z serwerem Puma i DelayedJob. Zrobiłem kilka testów obciążenia - wiele żądań w tym samym czasie itd. I kiedy spojrzałem na htop, znalazłem szereg procesów, które sprawiły, że podejrzewałem, że puma przecieka/nie zabija procesów. Z drugiej strony może to być normalne zachowanie. Widziałem jednak, że pamięć rośnie.

Mam 2 pracowników Puma ogółem w konfiguracji Rails i 2 pracowników opóźnionych.

Czy ktoś z doświadczeniem z pumą może potwierdzić/odrzucić moje obawy dotyczące wycieku pamięci?

CPU[|               1.3%]  Tasks: 54, 19 thr; 1 running 
    Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||| 746/1652MB]  Load average: 0.02 0.03 0.05 
    Swp[              0/2943MB]  Uptime: 1 day, 12:48:05 


1024 admin  20 0 828M 183M 3840 S 0.0 11.1 0:00.00 puma: cluster worker 0: 819 
1025 admin  20 0 828M 183M 3840 S 0.0 11.1 0:00.00 puma: cluster worker 0: 819 
1026 admin  20 0 828M 183M 3840 S 0.0 11.1 0:02.68 puma: cluster worker 0: 819 
1027 admin  20 0 828M 183M 3840 S 0.0 11.1 0:00.43 puma: cluster worker 0: 819 
1028 admin  20 0 828M 183M 3840 S 0.0 11.1 0:07.04 puma: cluster worker 0: 819 
1029 admin  20 0 828M 183M 3840 S 0.0 11.1 0:00.05 puma: cluster worker 0: 819 
1022 admin  20 0 828M 183M 3840 S 0.0 11.1 0:13.23 puma: cluster worker 0: 819 
1034 admin  20 0 829M 178M 3900 S 0.0 10.8 0:00.00 puma: cluster worker 1: 819 
1035 admin  20 0 829M 178M 3900 S 0.0 10.8 0:00.00 puma: cluster worker 1: 819 
1037 admin  20 0 829M 178M 3900 S 0.0 10.8 0:02.68 puma: cluster worker 1: 819 
1038 admin  20 0 829M 178M 3900 S 0.0 10.8 0:00.44 puma: cluster worker 1: 819 
1039 admin  20 0 829M 178M 3900 S 0.0 10.8 0:07.12 puma: cluster worker 1: 819 
1040 admin  20 0 829M 178M 3900 S 0.0 10.8 0:00.00 puma: cluster worker 1: 819 
1033 admin  20 0 829M 178M 3900 S 0.0 10.8 0:14.28 puma: cluster worker 1: 819 
1043 admin  20 0 435M 117M 3912 S 0.0 7.1 0:00.00 delayed_job.0 
1041 admin  20 0 435M 117M 3912 S 0.0 7.1 0:52.71 delayed_job.0 
1049 admin  20 0 435M 116M 3872 S 0.0 7.1 0:00.00 delayed_job.1 
1047 admin  20 0 435M 116M 3872 S 0.0 7.1 0:52.98 delayed_job.1 
1789 postgres 20 0 125M 10964 7564 S 0.0 0.6 0:00.26 postgres: admin app_production_ [local] idle 
1794 postgres 20 0 127M 11160 6460 S 0.0 0.7 0:00.18 postgres: admin app_production_ [local] idle 
1798 postgres 20 0 125M 10748 7484 S 0.0 0.6 0:00.24 postgres: admin app_production_ [local] idle 
1811 postgres 20 0 127M 10996 6424 S 0.0 0.6 0:00.11 postgres: admin app_production_ [local] idle 
1817 postgres 20 0 127M 11032 6460 S 0.0 0.7 0:00.12 postgres: admin app_production_ [local] idle 
1830 postgres 20 0 127M 11032 6460 S 0.0 0.7 0:00.14 postgres: admin app_production_ [local] idle 
1831 postgres 20 0 127M 11036 6468 S 0.0 0.7 0:00.20 postgres: admin app_production_ [local] idle 
1835 postgres 20 0 127M 11028 6460 S 0.0 0.7 0:00.06 postgres: admin app_production_ [local] idle 
1840 postgres 20 0 125M 7288 4412 S 0.0 0.4 0:00.04 postgres: admin app_production_ [local] idle 
1847 postgres 20 0 125M 7308 4432 S 0.0 0.4 0:00.06 postgres: admin app_production_ [local] idle 
1866 postgres 20 0 125M 7292 4416 S 0.0 0.4 0:00.06 postgres: admin app_production_ [local] idle 
1875 postgres 20 0 125M 7300 4424 S 0.0 0.4 0:00.04 postgres: admin app_production_ [local] idle 

Answer 1

Jeśli liczba procesów dopasowuje swoją konfigurację współbieżności chciałbym powiedzieć, że jest ok, jeśli rośnie z każdą prośbę, możesz mieć problem z procesami powieszenie. Domyślną wartością dla puma jest 16. Wygląda również na to, że używasz trybu klastrowego, aby mieć wiele procesów i wiele wątków na proces.