Memoire

La formule

pic ≈ 12 Mio                                  base (14,5 Mio en glibc)
    + 5,5 Mio                                 si un backend S3 sert
    + hash_workers × m + 2 Mio                verifications de mot de passe
    + sessions × 0,15 Mio
    + connexions en file de hachage × 70 Kio  au plus hash_queue
    + transferts locaux × 4 Mio
    + uploads S3 × 26 Mio + downloads S3 × 8 Mio
    + adresses suivies par les bans × 225 o

m est le plus grand m argon2 du fichier d’utilisateurs : 19 Mio au profil owasp-min (defaut de hash-password), 64 Mio au profil rfc9106-low-mem. La ligne de demarrage donne ce terme : peak_memory="1 thread × 19 MiB = 19 MiB". Voir Verification des mots de passe.

La formule est une borne haute : elle additionne des pics qui ne tombent pas tous au meme instant. Aucun cas mesure ne l’a depassee. La taille des fichiers n’y entre pas : les transferts sont en flux.

Les termes sont des mesures sur l’image publiee (binaire musl statique, x86_64), client OpenSSH ; une connexion en file de hachage pese ~42 Kio en Basic, un telechargement local 2,3 Mio. A grande echelle avec S3, les uploads dominent : 4 fils a m=65536 et 10 uploads S3 mesurent 415 Mio (formule : 537). Rien ne plafonne le nombre d’uploads S3 simultanes ; max_sessions_per_user borne par utilisateur.

Un petit deploiement sous 80 Mo

30 utilisateurs, ~900 fichiers par jour : quelques clients simultanes.

[auth]
hash_workers = 1      # une verification a la fois : 1 × 19 Mio
hash_queue = 32       # une file pleine : 32 × 70 Kio = 2,2 Mio

Avec des hashs hash-password (profil owasp-min), sans aucun hash rfc9106-low-mem dans le fichier :

Variante	Formule	Tient sous 80 Mo
backend local	45,5 Mio	oui
2 fils, backend local	64,5 Mio	oui
S3, un upload a la fois	64,7 Mio	oui
S3, 3 uploads simultanes	116,5 Mio	non
profil `rfc9106-low-mem`	90,5 Mio	non : une seule verification depasse le budget
file par defaut (1024)	+70 Mio file pleine	non

Binaires glibc

Les images Docker (musl) rendent la memoire apres chaque pic ; un binaire glibc (releases, hote glibc) garde dans ses arenes la memoire des hashs : 95 Mio retenus apres une rafale (4 fils, m=19456), 19 Mio avec MALLOC_MMAP_THRESHOLD_=4194304. Posez cette variable (Environment= dans l’unite systemd) et ne reglez pas MALLOC_ARENA_MAX, qui monte le pic.

Kubernetes

Reglage	Ce qu’il doit couvrir
`limits.memory`	le pic de la formule, sur le nombre de transferts et de sessions simultanes attendus, plus une marge
`requests.memory`	la memoire au repos et en charge ordinaire : base et sessions

Le chart livre requests.memory: 64Mi et limits.memory: 256Mi. Avec son defaut (1 fil, tire de requests.cpu: 100m), 1000 connexions SSH en file au profil rfc9106-low-mem montent a 146 Mio. Sur un noeud charge, montez la requete vers le pic attendu.

Un pod sans limits.cpu voit les CPU du noeud : voir Verification des mots de passe pour fixer le pool.

Suivre la memoire

/metrics expose process_resident_memory_bytes et process_peak_resident_memory_bytes (Linux seulement), et la console les trace en direct. Voir Metriques.

Non mesure : transferts REST, proxy SFTP, telemetrie active, milliers d’utilisateurs, aarch64 et Windows.