È normale che l'applicazione Rails mantenga così tante connessioni Puma e Postgres inattive?

Question

Ho un'app Rails con server Puma e DelayedJob. Ho eseguito alcuni test di carico su di esso - richieste multiple allo stesso tempo ecc. E quando ho guardato htop ho trovato un certo numero di processi che mi hanno fatto sospettare che il puma stia perdendo/non uccidendo i processi. D'altra parte può essere un comportamento normale. Tuttavia, ho visto aumentare la memoria.

Ho 2 dipendenti Puma in totale nella configurazione di Rails e 2 lavoratori in differita.

Qualcuno con esperienza con puma può confermare/eliminare le mie preoccupazioni sulla perdita di memoria?

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

Se il numero di processi corrisponde alla configurazione della concorrenza direi che è ok, se si continua a crescere con ogni richiesta allora si può avere un problema con i processi di impiccagione. Il valore predefinito per puma credo sia 16. Sembra inoltre che si stia utilizzando la modalità cluster in modo che abbia più processi e più thread per processo.