1つのpitchforkプロセスが負荷の大部分を担うのは正常なことです。他のプロセスは、最初のプロセスがビジー状態の場合にのみ選択されます。メモリが時間の経過とともに増加することもあります。キャッシュやruby-JITなどがウォームアップされると、最終的には安定した状態に達するはずです。
これは、1つの本番クラスタの7日間にわたるグラフです。ここでは、メモリ使用量が最も多い単一のプロセスを追跡しています。緑色の点線はデプロイ（つまりpitchforkの新しい起動）を示しています：
ご覧のとおり、初期起動後に増加しますが、その後約1.4GBで落ち着いています。このクラスタは数百のサイトを処理しているため、数値の比較としては最適ではないかもしれませんが、成長の可視化は役立つと思います。
プロセスごとのRSSの数値だけでは、全容がわかりません。Pitchforkは「フォーク型Webサーバー」です。つまり、まず「モールド」プロセスを起動し、その後、すべてのワーカーがコピーオンライトメモリパターンでそこからフォークされます。したがって、worker[0]のRSSが500MBを示していても、そのうち約200MBはモールドおよび他のすべてのワーカーと共有されています。
近いうちに、Pitchforkの"reforking"機能を有効にできるようにしたいと考えています。これは定期的にワーカーを殺し、すでにウォームアップされたワーカーから再フォークすることで、時間の経過とともに可能な限り多くのメモリを共有できるようにするものです。ただし、すべてのコードがこの種のパターンと互換性があることを確認するためには、いくつかの作業が必要です 