Erlang: différence de chiffres utilisation de la mémoire

Question

Quand je lance mon test WebSocket, je trouve les résultats de l'utilisation de la mémoire intéressantes suivantes:

serveur indiqué, aucun lien

[{total,573263528}, 
{processes,17375688}, 
{processes_used,17360240}, 
{system,555887840}, 
{atom,472297}, 
{atom_used,451576}, 
{binary,28944}, 
{code,3774097}, 
{ets,271016}] 
44 processes, 
System:705M, 
Erlang Residence:519M 

100K Connexions

[{total,762564512}, 
{processes,130105104}, 
{processes_used,130089656}, 
{system,632459408}, 
{atom,476337}, 
{atom_used,456484}, 
{binary,50160}, 
{code,3925064}, 
{ets,7589160}] 
100044 processes, 
System: 1814M, 
Erlang Residence: 950M 

200K Connexions

(redémarrer le serveur et créer à partir de 0 connexion, et non c ontinuer de cas 2)

[{total,952040232}, 
{processes,243161192}, 
{processes_used,243139984}, 
{system,708879040}, 
{atom,476337}, 
{atom_used,456484}, 
{binary,70856}, 
{code,3925064}, 
{ets,14904760}] 
200044 processes, 
System:3383M, 
Erlang: 1837M 

Les chiffres de « Système » et « Erlang: » sont fournies htop, d'autres sont de sortie appel mémoire() de la coquille de erlang. S'il vous plaît regardez le total et erlang mémoire de résidence. Quand il n'y a pas de connexion, ces deux sont à peu près les mêmes, avec des connexions 100K, la mémoire de résidence est un peu plus grande que le total, avec 200K connexions, la mémoire de résidence est presque le double du total.

Quelqu'un peut-il expliquer?

Answer 1

La réponse la plus probable pour votre quersion est la fragmentation de la mémoire.

L'allocation de la mémoire du système d'exploitation coûte cher, donc Erlang essaie de gérer la mémoire pour vous. Lorsque Erlang alloue de la mémoire, il crée une entité appelée "carrier", constituée de plusieurs "blocs". La mémoire Erlang (total) rapporte la somme de toutes les tailles de blocs (mémoire réellement utilisée). OS rapporte la somme de toutes les tailles de porteuses (somme de la mémoire utilisée et préallouée). La somme des tailles de blocs et des tailles de support peut être lue depuis Erlang VM. Si (tailles de bloc)/(tailles de support) < < 1, que VM a du mal à libérer les supports. Il pourrait y avoir beaucoup de grands transporteurs avec seulement quelques blocs utilisés. Vous pouvez le lire avec: erlang: system_info ({allocator, Type}). mais il y a un moyen plus facile. Vous pouvez le vérifier en utilisant la bibliothèque Recon:

http://ferd.github.io/recon/recon_alloc.html

vérifier d'abord:

recon_alloc:fragmentation(current). 

et suivant:

recon_alloc:fragmentation(max). 

Cela devrait expliquer la différence entre la mémoire totale déclarée par Erlang VM et OS Si vous envoyez beaucoup de petits messages sur websockets, vous pouvez réduire la fragmentation en exécutant Erlang avec 2 options:

erl +MBas aobf +MBlmbcs 512 

La première option va changer la stratégie d'allocation de bloc de meilleur ajustement pour répondre pour meilleur ajustement, ce qui pourrait aider à presser plus de blocs dans les premiers porteurs et le second diminue la taille maximale du porteur multibloc, ce qui rend les porteurs plus petits (cela devrait faciliter leur libération).