Es normal que un proceso de pitchfork asuma la mayor parte de la carga; los demás procesos solo se seleccionan cuando el primero está ocupado. También es normal que la memoria crezca con el tiempo. Aunque debería alcanzar un estado estable eventualmente, una vez que todo, como las cachés y ruby-JIT, esté «calentado».
Aquí hay un gráfico de uno de nuestros clústeres de producción, durante un período de 7 días. Este rastrea el proceso individual con el mayor uso de memoria. Las líneas punteadas de color verde indican despliegues (es decir, reinicios frescos de pitchfork):
Así que puedes ver que sí crece después del lanzamiento inicial, pero luego se estabiliza en poco menos de 1.4 GB. Este clúster sirve a cientos de sitios, por lo que quizás no sea la mejor comparación en términos de números… pero espero que la visualización del crecimiento sea útil.
Mirar los números de RSS por proceso no cuenta toda la historia. Pitchfork es un «servidor web que realiza fork». Así que arranca el proceso «molde» (mold) y luego todos los trabajadores (workers) se bifurcan de él con un patrón de memoria de copia bajo escritura (copy-on-write). Por lo tanto, aunque el RSS podría mostrar 500 MB para worker[0], aproximadamente 200 MB de eso están compartidos con el molde y todos los demás trabajadores.
En un futuro no muy lejano, esperamos habilitar la función de «reforking» de Pitchfork. Esto mata periódicamente a los trabajadores y vuelve a bifurcarlos desde un trabajador ya calentado, para que compartan la mayor cantidad de memoria posible con el tiempo. Sin embargo, se necesita algo de trabajo para asegurarse de que todo nuestro código sea compatible con ese tipo de patrón 