Proxmox Vider le swap d'un lxc unprivileged

[Nincha]

Bonjour,
Suite à quelques tests sur un container Jellyfin, j'ai vu par deux fois la taille du "boot disk" augmenter d'un coup..
J'essaie de faire des tests pour augmenter la réactivité de Jellyfin derrière un reverse proxy. Pour se faire je laisse épisode de série en pause puis le relance pour voir s'il lag toujours.
Je modifie la.config, redémarre à plusieurs reprises et là plus de Jellyfin. Et le boot disk à 95% d'occupation.
En faisant un swapon -s je vois que j'ai pas loin de 4go de swap utilisé. Apparemment en faisant deux lignes de commandes on peut désactiver le swap puis le vider et relancer mais je me prends un message "not superuser".
Bon ça paraît cohérent pour un container unprivileged, mais comment je peux vider ce swap ?
Merci d'avance

 

[Cram28]

Bonsoir,

Je me trompe peut-être mais pour moi, un système qui swap est un système qui n'a pas assez de RAM pour faire ce à quoi il est destiné: En gros, il est mal dimensionné...

Plutôt que de tenter de vider le swapp, ne vaudrait-il pas mieux éviter qu'il se remplisse, en donnant plus de RAM à ton container ?

 

[Nincha]

Alors effectivement je me suis aussi posé la question de pourquoi il swappait. J'avoue ne pas très bien connaître ce mécanisme.
Une fois la RAM augmentée, le swap se viderait-il de lui même ?
Ou alors il faut encore que j'augmente la taille du disque ? Sachant que là je suis déjà à 12go, j'ai regardé mes dossiers docker de la précédente installation prenaient à peine 3 go....

 

[Cram28]

Bonsoir,

Le swap sert de zone d'échange entre mémoire vive (RAM) et mémoire de masse (disque). Ce que je comprends du truc (dans un cas hors "hibernation" qui est un peu particulier) c'est que le swap est activé quand il n'y a plus assez de RAM et que le système transvase alors des données qui sont en RAM et qu'il doit conserver, sur une partition swap (ou un fichier «spécial swap») sur disque. Alors ce n'est a priori pas en ajoutant de l'espace disque dédié au swap - qui est la destination des données swappées - que çà changera le mécanisme ni diminuera la quantité de données (au contraire, le système pourrait occuper la place dont il dispose).
Le swap peut aussi servir à stocker les pages mémoire "inactives" et utiliser la mémoire disponible de façon plus efficace, par exemple comme cache pour des fichiers "actifs". Et tu parles de Jellyfin, donc de streaming vidéo, avec peut-être une espèce de «cache» possible avant d'envoyer au client... ? Je ne connais pas ce soft mais peut-être existe-t-il un paramétrage ou une config. à ce niveau ?

Ça dépend en fait de beaucoup de critères et par exemple il existe des débats à n'en plus finir sur la taille du swap à réserver quand on installe un système Linux : taille de swap égale à la taille de la RAM, ou 2 fois la taille de la RAM, selon à quoi il est destiné, selon qu'il y a une interface graphique, etc...

Quant à vider le swap, je pense qu'il y a un moment où les données du swap seront remises en RAM quand l' appli concernée en aura besoin et s'il y a suffisamment de RAM pour le faire, et il devrait ainsi se «vider».

Normalement un conteneur (privilégié ou pas) n’a pas son propre fichier d’échange ou partition de swap, mais il doit y avoir un swap actif sur l'hôte pour que le mécanisme soit possible.

1. Est-ce bien le cas chez toi ? (chez moi, par défaut, Proxmox ne définit pas de partition ou fichier de swap [mais j'ai opter pour ZFS en file system, c'est sans doute particulier])
2. Ta commande swapon -s tu l'exécutes sur l'hôte ou dans le container ?
3. C'est quoi que tu appelles le «boot disk» ? Ça concerne l'hôte ou le container ? Comment le vois-tu augmenter ?
4. Et comment est occupée la RAM: container et hôte ?

Pour moi, c'est pas trivial du tout ces histoires... Un truc que tu pourrais tenter pour tuner un peu le bouzin, c'est de ne pas donner de limite de RAM à ton container et voir comment ça se comporte tout çà...

@+

 

[EVO]

Alors effectivement je me suis aussi posé la question de pourquoi il swappait. J'avoue ne pas très bien connaître ce mécanisme.
Une fois la RAM augmentée, le swap se viderait-il de lui même ?
Ou alors il faut encore que j'augmente la taille du disque ? Sachant que là je suis déjà à 12go, j'ai regardé mes dossiers docker de la précédente installation prenaient à peine 3 go....

Salut,
Un systeme peu avoir besoin de swap pour beaucoup beaucoup de raison. Souvent c'est un "pic" de demande de RAM, a un moment donné ( parfois très court ) ou le systeme a eu besoin d'un peu plus de RAM que d’habitude ! Pour éviter de saturer ou meme de prendre le risque de saturer la RAM.

Le SWAP n'est jamais vraiment vidé, mise a part redémarrage de la machine OU nouveau besoin de SWAP. Si la machine a de nouveau besoin de SWAP, alors elle se servira dans le SWAP qui ne lui sert plus. Mais le SWAP est conservé autrement, car il y a en réalité peu d'intéret a le vider. Il pourrai re-servir , et si c'est pas le cas, s'il faut le vider, l'opération est rapide et aussi puisque c'est une partition reservé pour cela, alors cela n'occupe pas de place sur ta partition de données / systeme, ..

 

[Nincha]

Hello, merci pour la précision de la réponse ;-)

Quant à vider le swap, je pense qu'il y a un moment où les données du swap seront remises en RAM quand l' appli concernée en aura besoin et s'il y a suffisamment de RAM pour le faire, et il devrait ainsi se «vider».

OK, je vais tenter d'ajouter de la ram pour voir s'il se vide de lui même. Etant donné que je n'avais pas rencontré ce problème avec docker (qui n'était pas limité en ram), le souci vient donc probablement de la ram.

Et tu parles de Jellyfin, donc de streaming vidéo, avec peut-être une espèce de «cache» possible avant d'envoyer au client... ? Je ne connais pas ce soft mais peut-être existe-t-il un paramétrage ou une config. à ce niveau ?

Aucune idée, je n'ai pas fait de réglages spécifique pour de la mise en cache. Jellyfin crée une sorte de cache, mais de ce que je vois sur les données de mon ancien container docker, ça ne dépassait pas les 4go, là on a multiplie par 3...

1. Est-ce bien le cas chez toi ? (chez moi, par défaut, Proxmox ne définit pas de partition ou fichier de swap [mais j'ai opter pour ZFS en file system, c'est sans doute particulier])
2. Ta commande swapon -s tu l'exécutes sur l'hôte ou dans le container ?
3. C'est quoi que tu appelles le «boot disk» ? Ça concerne l'hôte ou le container ? Comment le vois-tu augmenter ?
4. Et comment est occupée la RAM: container et hôte ?

1. Je n'ai pas fait de réglage particulier pour le swap, sur l'hôte, je pense donc que ça doit être organisé de la même façon qu'un debian, donc une petite partition de swap de quelques gigas.
2. Sur le container:

   root@jellyfin:~# swapon -sFilename                Type        Size        Used        Priority
   none                    virtual        4194304        0            0

3. Ce que j'appelle le boot disk est le terme utilisé par Proxmox dans la section summary. Je comprends par là que c'est le disque de boot, ou disque principal:
4. La ram semble assez peu occupée (cf capture ci-dessus), mais il y'a tellement plus de places que le service jellyfin n'est pas redémarré.... Je vais tenter d'augmenter la ram et redémarrer pour voir si jellyfin redémarre bien, et observer la ram en cours de lecture

C'est plus lisible avec un

swapon --show

:

 

[Nincha]

Bon ben, un peu plus de ram et de place pour que le système puisse booter normalement et l'espace occupé a "légèrement" chuté



Je vais laisser l'état et voir ce que ça donne.

EDIT: een lançant deux flux, l'un depuis le reverse proxy (depuis le nom de domaine) et l'autre en local (depuis l'adresse ip lan), je vois la taille du bootdisk réaugmenter à plus de 8 go. Semblerait que Jellyfin écrive le cache/tampon nécessaire à la lecture directement sur le disque.
Dès que je coupe les lectures, la taille du bootdisk revient à la même chose que ma capture au dessus.
Le swap n'est donc à priori pas en cause, il s'agit plutôt de la mécanique interne à Jellyfin.

 

[Cram28]

Bonsoir,

D'accord: des images sont mieux qu'un long discours, c'est plus clair pour moi ...

En fouillant un peu, il y a un tuto de EVO ici qui précise qu'il faut un cache en effet !

Dans la mesure où tu n'as pas cette notion dans ton container LXC - c'est la différence fondamentale entre LXC, container système et Docker container appli - il pioche dans le disque que tu lui a donné à la création. Et ce n'est pas du swap en effet comme tu dis, tu noteras que dans ton écran le swap est vide, et qu'il fait la taille de la RAM attribuée (stratégie par défaut sur Proxmox/LXC).

A mon avis en effet, Jellyfin a plus besoin d'espace disque que de RAM ou de swap, et visiblement, plus il y a de clients, plus il y a de besoin.

Maintenant, il est peut-être intéressant de mettre cet espace de cache sur une zone plus appropriée/plus étendue sur l'hôte que là où il est par défaut ? Je ne sais pas, çà dépend de la place dont tu disposes dédiée aux disques virtuels de tes VM/CT.
Si c'est le cas, il faut trouver où se situe le cache dans la config de Jellyfin et faire un bind dans la config. du container pour faire pointer vers une zone disque de la machine qui convient mieux. Ce sera l'équivalent d'un volume dans la terminologie Docker.

@suivre, @+

 

[Nincha]

Bonsoir,

D'accord: des images sont mieux qu'un long discours, c'est plus clair pour moi ...

En fouillant un peu, il y a un tuto de EVO ici qui précise qu'il faut un cache en effet !

Dans la mesure où tu n'as pas cette notion dans ton container LXC - c'est la différence fondamentale entre LXC, container système et Docker container appli - il pioche dans le disque que tu lui a donné à la création. Et ce n'est pas du swap en effet comme tu dis, tu noteras que dans ton écran le swap est vide, et qu'il fait la taille de la RAM attribuée (stratégie par défaut sur Proxmox/LXC).

A mon avis en effet, Jellyfin a plus besoin d'espace disque que de RAM ou de swap, et visiblement, plus il y a de clients, plus il y a de besoin.

Maintenant, il est peut-être intéressant de mettre cet espace de cache sur une zone plus appropriée/plus étendue sur l'hôte que là où il est par défaut ? Je ne sais pas, çà dépend de la place dont tu disposes dédiée aux disques virtuels de tes VM/CT.
Si c'est le cas, il faut trouver où se situe le cache dans la config de Jellyfin et faire un bind dans la config. du container pour faire pointer vers une zone disque de la machine qui convient mieux. Ce sera l'équivalent d'un volume dans la terminologie Docker.

@suivre, @+

Hello, alors pour m'être un peu arraché les cheveux sur les binds, je sais qu'avec mon container unprivileged ça risque d'être compliqué.
Par contre, le boot disque pour ce lxc jellyfin est situé sur une partition du disque nvme de proxmox, donc je ne m'inquiète pas pour le temps de réaction du cache
Faudra juste que je surveille son occupation totale, car j'ai également un container pour Nextcloud sur cette même partition du nvme, et Nextcloud peut vite monter en espace disque occupé.