Ist es normal für die Rails-Anwendung, so viele Puma- und Postgres-Verbindungen im Leerlauf zu behalten?

Question

Ich habe eine Rails App mit Puma Server und DelayedJob. Ich habe einige Lasttests gemacht - mehrere Anfragen gleichzeitig usw. Und als ich auf htop schaute, fand ich eine Reihe von Prozessen, die mich misstrauisch machten, dass Puma undicht ist/Prozesse nicht abtötet. Auf der anderen Seite kann es normales Verhalten sein. Ich sah zwar, dass die Speicherkapazität stieg.

Ich habe 2 Puma Arbeiter insgesamt in Rails Konfiguration und 2 verzögerte Job Arbeiter.

Kann jemand mit Erfahrung mit Puma meine Bedenken über Gedächtnisverlust bestätigen/verwerfen?

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

Wenn die Anzahl der Prozesse Ihre Concurrency-Konfiguration entspricht, würde ich sagen, das ist in Ordnung, wenn es mit jeder Anforderung wächst, dann können Sie ein Problem mit Prozessen hängen haben. Der Standardwert für Puma ist 16. Es sieht auch so aus, als ob Sie den Cluster-Modus verwenden, so dass es mehrere Prozesse und mehrere Threads pro Prozess gibt.