Rails 应用程序保持这么多空闲的 Puma 和 Postgres 连接是否正常?

Is it normal for Rails application to keep so many idle Puma and Postgres connections?

我有一个带有 Puma 服务器和 DelayedJob 的 Rails 应用程序。 我对它做了一些负载测试——同时有多个请求等。当我查看 htop 时,我发现了许多进程,这让我怀疑 puma 正在泄漏/没有杀死进程。另一方面,这可能是正常行为。我确实看到内存增加了。

我在 Rails 配置中总共有 2 个 Puma 工人和 2 个延迟工作工人。

有 puma 经验的人可以确认/排除我对内存泄漏的担忧吗?

  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

如果进程数与您的并发配置相匹配,我会说没关系,如果它随着每个请求而不断增长,那么您可能会遇到进程挂起的问题。我认为 puma 的默认值是 16。看起来您正在使用集群模式,因此每个进程将有多个进程和多个线程。