Il est normal qu’un seul processus pitchfork supporte la majeure partie de la charge — les autres ne sont sollicités que lorsque le premier est occupé. Il est également normal que la mémoire augmente avec le temps. Bien qu’elle devrait finir par atteindre un état stable, une fois que tout est « réchauffé », comme les caches et le JIT Ruby.
Voici un graphique issu de l’un de nos clusters de production, sur une période de 7 jours. Il suit le processus ayant la plus forte consommation mémoire. Les lignes vertes en pointillés indiquent les déploiements (c’est-à-dire les redémarrages complets de pitchfork) :
On peut donc voir qu’il augmente après le démarrage initial, mais se stabilise ensuite juste en dessous de 1,4 Go. Ce cluster sert des centaines de sites, donc la comparaison en termes de chiffres n’est peut-être pas la plus pertinente… mais j’espère que la visualisation de la croissance est utile.
Regarder les valeurs RSS par processus ne donne pas toute l’histoire. Pitchfork est un « serveur web à fourchette » (forking web server). Il démarre donc le processus « moule » (mold), puis tous les travailleurs (workers) sont créés par fourchetage (fork) à partir de celui-ci, avec un modèle mémoire en écriture-copie (copy-on-write). Ainsi, bien que le RSS puisse afficher 500 Mo pour worker[0], environ 200 Mo de cette quantité sont partagés avec le moule et tous les autres travailleurs.
Dans un avenir proche, nous espérons pouvoir activer la fonctionnalité de « reforking » de Pitchfork. Elle tue périodiquement les travailleurs et les recrée par fourchetage à partir d’un travailleur déjà réchauffé, afin qu’ils partagent le maximum de mémoire possible au fil du temps. Il faudra toutefois effectuer certains travaux pour s’assurer que tout notre code est compatible avec ce type de modèle 