하나의 pitchfork 프로세스가 대부분의 부하를 처리하는 것은 정상적인 현상입니다. 첫 번째 프로세스가 바쁠 때만 다른 프로세스가 선택되므로 그렇습니다. 시간이 지남에 따라 메모리가 증가하는 것도 정상입니다. 캐시나 ruby-JIT와 같은 모든 것이 워밍업을 마친 후에는 결국 안정 상태에 도달해야 합니다.
아래는 7일간의 기간 동안 우리 프로덕션 클러스터 중 하나의 그래프입니다. 이는 가장 많은 메모리를 사용하는 단일 프로세스를 추적한 것입니다. 녹색 점선은 배포(즉, pitchfork의 새로운 시작)를 나타냅니다:
보시다시피, 초기 출시 후 메모리가 증가하지만, 결국 약 1.4GB 미만에서 안정화됩니다. 이 클러스터는 수백 개의 사이트를 서비스하고 있으므로 숫자 측면에서 가장 좋은 비교 대상은 아닐 수 있습니다… 하지만 성장 추세를 시각적으로 보여주는 데는 도움이 되기를 바랍니다.
프로세스별 RSS 수치를 살펴보는 것만으로는 전체 이야기를 파악할 수 없습니다. Pitchfork는 "포킹 웹 서버"입니다. 즉, ‘모드(mold)’ 프로세스를 부팅한 다음, 모든 워커가 쓰기 시 복제(copy-on-write) 메모리 패턴을 사용하여 해당 모드에서 포크됩니다. 따라서 RSS가 worker[0]에 대해 500mb를 표시하더라도, 그 중 약 200mb는 모드 및 다른 모든 워커와 공유되고 있습니다.
가까운 장래에 Pitchfork의 “리포킹(reforking)” 기능을 활성화하는 것을 목표로 하고 있습니다. 이 기능은 워커를 주기적으로 종료하고, 이미 워밍업된 워커에서 다시 포크하여 시간이 지남에 따라 가능한 한 많은 메모리를 공유하게 합니다. 다만, 모든 코드가 이러한 패턴과 호환되도록 하는 데 일부 작업이 필요합니다 