Bonjour,
Soit c’est la fin de semaine, soit c’est ma mémoire qui me fait défaut, mais pour moi le swapiness définit le seuil de RAM libre à partir duquel la machine va commencer à swapper ?
Du coup, si je mets un swapiness à 1, je ne devrais pas avoir de données dans le swap tant que moins de 99 % de la RAM est utilisée.
Or, ce n’est pas ce que je vois actuellement : root@erispoe:~# sysctl vm.swappiness vm.swappiness = 1 root@erispoe:~# free -m total used free shared buffers cached Mem: 16034 13151 2882 419 28 470 -/+ buffers/cache: 12652 3381 Swap: 15359 1092 14267
Il y a presque 3G de RAM non-allouée sur 16G au total (ce qui fait clairement moins de 1 %), pourtant, il y a 1G de swap utilisé.
Quelqu’un a une idée pour expliquer ça ? La machine est une proxomox, donc basée sur Debian 8.6.
Hello, je te conseille sous proxmox d'éviter de forcer l'utilisation de la ram en lieu et place du swap, et surtout de ne pas mettre swappiness à 0 : ça augmente considérablement le risque d'un OOM killing lorqu'il y a une grande utilisation de la mémoire et des i/o, sans pour autant qu'elle soit intégralement consommée.
amicalement,
De ce que je comprends de https://github.com/torvalds/linux/blob/master/Documentation/sysctl/vm.txt#L7..., le swappiness correspond à une pondération de l'algorithm qui détermine si il faut swapper et non à un taux d'occupation de la mémoire servant de déclencheur.
Jo
On 12/16/2016 10:20 AM, Alarig Le Lay wrote:
Bonjour,
Soit c’est la fin de semaine, soit c’est ma mémoire qui me fait défaut, mais pour moi le swapiness définit le seuil de RAM libre à partir duquel la machine va commencer à swapper ?
Du coup, si je mets un swapiness à 1, je ne devrais pas avoir de données dans le swap tant que moins de 99 % de la RAM est utilisée.
Or, ce n’est pas ce que je vois actuellement : root@erispoe:~# sysctl vm.swappiness vm.swappiness = 1 root@erispoe:~# free -m total used free shared buffers cached Mem: 16034 13151 2882 419 28 470 -/+ buffers/cache: 12652 3381 Swap: 15359 1092 14267
Il y a presque 3G de RAM non-allouée sur 16G au total (ce qui fait clairement moins de 1 %), pourtant, il y a 1G de swap utilisé.
Quelqu’un a une idée pour expliquer ça ? La machine est une proxomox, donc basée sur Debian 8.6.
Liste de diffusion du FRsAG http://www.frsag.org/
vendredi 16 décembre 2016, 10:20:56 CET Alarig Le Lay wrote:
Bonjour,
Soit c’est la fin de semaine, soit c’est ma mémoire qui me fait défaut, mais pour moi le swapiness définit le seuil de RAM libre à partir duquel la machine va commencer à swapper ?
Du coup, si je mets un swapiness à 1, je ne devrais pas avoir de données dans le swap tant que moins de 99 % de la RAM est utilisée.
Or, ce n’est pas ce que je vois actuellement : root@erispoe:~# sysctl vm.swappiness vm.swappiness = 1 root@erispoe:~# free -m total used free shared buffers cached Mem: 16034 13151 2882 419 28 470 -/+ buffers/cache: 12652 3381 Swap: 15359 1092 14267
Il y a presque 3G de RAM non-allouée sur 16G au total (ce qui fait clairement moins de 1 %), pourtant, il y a 1G de swap utilisé.
Quelqu’un a une idée pour expliquer ça ? La machine est une proxomox, donc basée sur Debian 8.6.
Question con : tu regardes la mémoire de ta machine au bout de combien de temps ? Il y a pu avoir une période bourrine sur la machine qui l'a fait swapper, et comme elle n'a pas eu besoin des données en swap depuis, c'est resté dans la swap.
Si tu as un munin, tu devrais pouvoir regarder ça.
On Fri Dec 16 10:38:40 2016, Luc Didry wrote:
Question con : tu regardes la mémoire de ta machine au bout de combien de temps ? Il y a pu avoir une période bourrine sur la machine qui l'a fait swapper, et comme elle n'a pas eu besoin des données en swap depuis, c'est resté dans la swap.
Si tu as un munin, tu devrais pouvoir regarder ça.
J’ai un munin, et il n’y a pas eu de bourrinage car nous n’avons pas créé de nouvelle VM et la RAM est réservée pour chaque VM (chaque processus KVM prend 512M de RAM).
https://monitoring.grifon.fr/munin/grifon.fr/erispoe.grifon.fr/memory.html
La baisse de swap, c’est quand on l’a vidé pour changer la valeur de swapiness.
vendredi 16 décembre 2016, 10:56:50 CET Alarig Le Lay wrote:
J’ai un munin, et il n’y a pas eu de bourrinage car nous n’avons pas créé de nouvelle VM et la RAM est réservée pour chaque VM (chaque processus KVM prend 512M de RAM).
https://monitoring.grifon.fr/munin/grifon.fr/erispoe.grifon.fr/memory.html
La baisse de swap, c’est quand on l’a vidé pour changer la valeur de swapiness.
Tu vois la belle ligne vert foncé qui part vers l'infini et l'au-delà ? (committed) C'est ça qui te fait swapper, j'ai eu le même problème en début de semaine. Mon problème venait d'une appli faisant partie de Jitsi meet, en la redémarrant, hop, a plus problème. Depuis je lui ai mis un restart avec le logrotate.
Tu dois avoir une appli qui fait la même chose.
Mon problème venait d'une appli faisant partie de Jitsi meet, en la redémarrant, hop, a plus problème. Depuis je lui ai mis un restart avec le logrotate.
Je peux en profiter pour demander quoi exactement ? J'ai mis un jitsi meet en place la semaine dernière donc ça m'intrigue.
vendredi 16 décembre 2016, 11:39:38 CET Kevin Lemonnier wrote:
Mon problème venait d'une appli faisant partie de Jitsi meet, en la redémarrant, hop, a plus problème. Depuis je lui ai mis un restart avec le logrotate.
Je peux en profiter pour demander quoi exactement ? J'ai mis un jitsi meet en place la semaine dernière donc ça m'intrigue.
J'ai pas cherché très loin, j'ai redémarré jicofo et jitsi-videobridge. Je voulais rétablir le service le plus vite possible.
Après, ça ne s'est pas fait en une semaine hein, ça a bouffé les 3Gio de ram au bout d'un mois, avec ±1000 rooms par semaine (je ne sais pas par contre combien de fois par semaine une room est utilisée).
J'ai pas cherché très loin, j'ai redémarré jicofo et jitsi-videobridge. Je voulais rétablir le service le plus vite possible.
Après, ça ne s'est pas fait en une semaine hein, ça a bouffé les 3Gio de ram au bout d'un mois, avec ±1000 rooms par semaine (je ne sais pas par contre combien de fois par semaine une room est utilisée).
Mh ok, bon à savoir, merci ! On a clairement pas une utilisation aussi importante donc je dois avoir de la marge, en tout cas j'espère :)
vendredi 16 décembre 2016, 12:14:13 CET Kevin Lemonnier wrote:
Mh ok, bon à savoir, merci ! On a clairement pas une utilisation aussi importante donc je dois avoir de la marge, en tout cas j'espère :)
Sinon, un petit restart du service au niveau du logrotate et c'est bon hein :-)
On Fri Dec 16 11:18:18 2016, Luc Didry wrote:
vendredi 16 décembre 2016, 10:56:50 CET Alarig Le Lay wrote:
J’ai un munin, et il n’y a pas eu de bourrinage car nous n’avons pas créé de nouvelle VM et la RAM est réservée pour chaque VM (chaque processus KVM prend 512M de RAM).
https://monitoring.grifon.fr/munin/grifon.fr/erispoe.grifon.fr/memory.html
La baisse de swap, c’est quand on l’a vidé pour changer la valeur de swapiness.
Tu vois la belle ligne vert foncé qui part vers l'infini et l'au-delà ? (committed) C'est ça qui te fait swapper, j'ai eu le même problème en début de semaine. Mon problème venait d'une appli faisant partie de Jitsi meet, en la redémarrant, hop, a plus problème. Depuis je lui ai mis un restart avec le logrotate.
Tu dois avoir une appli qui fait la même chose.
Okay, donc si je comprends bien, la RAM commitée est la RAM qui a été demandée par un programme, qu’elle soit utilisée ou pas ? Le kernel voit ça, et met la RAM qui n’est pas souvent demandée en swap ?
Salut,
On Fri, Dec 16, 2016 at 02:40:31PM +0100, Alarig Le Lay wrote:
On Fri Dec 16 11:18:18 2016, Luc Didry wrote:
vendredi 16 décembre 2016, 10:56:50 CET Alarig Le Lay wrote:
J’ai un munin, et il n’y a pas eu de bourrinage car nous n’avons pas créé de nouvelle VM et la RAM est réservée pour chaque VM (chaque processus KVM prend 512M de RAM).
https://monitoring.grifon.fr/munin/grifon.fr/erispoe.grifon.fr/memory.html
La baisse de swap, c’est quand on l’a vidé pour changer la valeur de swapiness.
Tu vois la belle ligne vert foncé qui part vers l'infini et l'au-delà ? (committed) C'est ça qui te fait swapper, j'ai eu le même problème en début de semaine. Mon problème venait d'une appli faisant partie de Jitsi meet, en la redémarrant, hop, a plus problème. Depuis je lui ai mis un restart avec le logrotate.
Tu dois avoir une appli qui fait la même chose.
Okay, donc si je comprends bien, la RAM commitée est la RAM qui a été demandée par un programme, qu’elle soit utilisée ou pas ? Le kernel voit ça, et met la RAM qui n’est pas souvent demandée en swap ?
Non, vu c'est de l'allocate on write par défaut, la valeur committed ne sert qu'a titre informatif et n'influe en rien les décisions de swap.
Par contre, le kernel préfère swapper des pages totalement -inutiles- pour avoir plus de cache disque -utile-, pour toutes les valeurs de vm.swappiness autre que 0.
Sylvain
Salut Alarig,
On Fri, Dec 16, 2016 at 10:56:50AM +0100, Alarig Le Lay wrote:
On Fri Dec 16 10:38:40 2016, Luc Didry wrote:
Question con : tu regardes la mémoire de ta machine au bout de combien de temps ? Il y a pu avoir une période bourrine sur la machine qui l'a fait swapper, et comme elle n'a pas eu besoin des données en swap depuis, c'est resté dans la swap.
Si tu as un munin, tu devrais pouvoir regarder ça.
J’ai un munin, et il n’y a pas eu de bourrinage car nous n’avons pas créé de nouvelle VM et la RAM est réservée pour chaque VM (chaque processus KVM prend 512M de RAM).
https://monitoring.grifon.fr/munin/grifon.fr/erispoe.grifon.fr/memory.html
C'est très etonnant comme graphe, surtout autant d'unused et plus rien en cache, t'utilises des huge pages ?
Y'a très clairement du leak (que ce soit en kernel land ou user land) et ton kernel essaye désespérement de trouver de la place pour faire un peu de cache disque.
$ cat /proc/meminfo
Sylvain
On Fri Dec 16 15:23:05 2016, Sylvain Rochet wrote:
https://monitoring.grifon.fr/munin/grifon.fr/erispoe.grifon.fr/memory.html
C'est très etonnant comme graphe, surtout autant d'unused et plus rien en cache, t'utilises des huge pages ?
Sauf si proxmox a décidé de le faire tout seul, non.
Y'a très clairement du leak (que ce soit en kernel land ou user land) et ton kernel essaye désespérement de trouver de la place pour faire un peu de cache disque.
Le stockage est géré par ZFS, et on a un L2ARC sur SSD ; je pense que ça doit jouer.
$ cat /proc/meminfo
https://paste.swordarmor.fr/raw/LaxQ
Bonjoir,
pour savoir qui swap combien il y a ça, trouvé ici : https://www.cyberciti.biz/faq/linux-which-process-is-using-swap/
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
testé & approuvé, mais ça n'explique pas les causes
++
Guillaume
Le 16/12/2016 à 10:38, Luc Didry a écrit :
vendredi 16 décembre 2016, 10:20:56 CET Alarig Le Lay wrote:
Bonjour,
Soit c’est la fin de semaine, soit c’est ma mémoire qui me fait défaut, mais pour moi le swapiness définit le seuil de RAM libre à partir duquel la machine va commencer à swapper ?
Du coup, si je mets un swapiness à 1, je ne devrais pas avoir de données dans le swap tant que moins de 99 % de la RAM est utilisée.
Or, ce n’est pas ce que je vois actuellement : root@erispoe:~# sysctl vm.swappiness vm.swappiness = 1 root@erispoe:~# free -m total used free shared buffers cached Mem: 16034 13151 2882 419 28 470 -/+ buffers/cache: 12652 3381 Swap: 15359 1092 14267
Il y a presque 3G de RAM non-allouée sur 16G au total (ce qui fait clairement moins de 1 %), pourtant, il y a 1G de swap utilisé.
Quelqu’un a une idée pour expliquer ça ? La machine est une proxomox, donc basée sur Debian 8.6.
Question con : tu regardes la mémoire de ta machine au bout de combien de temps ? Il y a pu avoir une période bourrine sur la machine qui l'a fait swapper, et comme elle n'a pas eu besoin des données en swap depuis, c'est resté dans la swap.
Si tu as un munin, tu devrais pouvoir regarder ça.
Si tu veux un listing plus détaillé :
https://raw.githubusercontent.com/aya/bin/master/check-memory-usage
On ven., déc. 16, 2016 at 6:45 , Guillaume GARNIER guillaume.garnier@mailoo.org wrote:
Bonjoir,
pour savoir qui swap combien il y a ça, trouvé ici : https://www.cyberciti.biz/faq/linux-which-process-is-using-swap/
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
testé & approuvé, mais ça n'explique pas les causes
++
Guillaume
Le 16/12/2016 à 10:38, Luc Didry a écrit :
vendredi 16 décembre 2016, 10:20:56 CET Alarig Le Lay wrote:
Bonjour,
Soit c’est la fin de semaine, soit c’est ma mémoire qui me
fait défaut,
mais pour moi le swapiness définit le seuil de RAM libre à
partir duquel
la machine va commencer à swapper ?
Du coup, si je mets un swapiness à 1, je ne devrais pas avoir de
données
dans le swap tant que moins de 99 % de la RAM est utilisée.
Or, ce n’est pas ce que je vois actuellement : root@erispoe:~# sysctl vm.swappiness vm.swappiness = 1 root@erispoe:~# free -m total used free shared buffers cached Mem: 16034 13151 2882 419 28 470 -/+ buffers/cache: 12652 3381 Swap: 15359 1092 14267
Il y a presque 3G de RAM non-allouée sur 16G au total (ce qui fait clairement moins de 1 %), pourtant, il y a 1G de swap utilisé.
Quelqu’un a une idée pour expliquer ça ? La machine est une
proxomox,
donc basée sur Debian 8.6.
Question con : tu regardes la mémoire de ta machine au bout de
combien de
temps ? Il y a pu avoir une période bourrine sur la machine qui
l'a fait
swapper, et comme elle n'a pas eu besoin des données en swap
depuis, c'est resté
dans la swap.
Si tu as un munin, tu devrais pouvoir regarder ça.
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir
L'explication est a mon avis que ta machine a du manquer de ram a un moment donné et mis des choses en swap.
Depuis la ram utilisée est redescendue mais les choses mises en swap ne sont remises en ram QUE quand le système en a réellement besoin.
Tu peux donc avoir du swap utilisé avec 90% de ram libre...
Je me permet de passer en mode troll
De mon expérience le swap, c'est le mal.
il y eut un temps ou le kilo de ram coutait plus cher que le kilo de pain et on avait pas trop le choix.
Mais aujourd'hui la moindre machine a tout plein de gigots au point qu'on ne sait plus toujours quoi en faire et je ne vois pas très bien comme un système bien conçu sature ça (sans rencontrer un autre goulot d'étranglement avant.)
D'expérience l'utilisation du Swap entraine une forte charge liée aux IO et au final une diminution de la capacité de traitement de la machine, ce qui se traduit par encore plus de ram utilisée par les process en concurrence et on va droit au crash...
Donc personellement, il n'y a plus jamais de swap dans mes serveurs sans une super bonne raison et soit on adapte le soft pour être surs de ne jamais saturer la ram (et en en laissant plein pour le cache disque), soit on augmente la capa de ram (ce qui est en fait vraiment très rare) .
On 16/12/2016 18:45, Guillaume GARNIER wrote:
Bonjoir,
pour savoir qui swap combien il y a ça, trouvé ici : https://www.cyberciti.biz/faq/linux-which-process-is-using-swap/
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
testé & approuvé, mais ça n'explique pas les causes
++
Guillaume
Le 16/12/2016 à 10:38, Luc Didry a écrit :
vendredi 16 décembre 2016, 10:20:56 CET Alarig Le Lay wrote:
Bonjour,
Soit c’est la fin de semaine, soit c’est ma mémoire qui me fait défaut, mais pour moi le swapiness définit le seuil de RAM libre à partir duquel la machine va commencer à swapper ?
Du coup, si je mets un swapiness à 1, je ne devrais pas avoir de données dans le swap tant que moins de 99 % de la RAM est utilisée.
Or, ce n’est pas ce que je vois actuellement : root@erispoe:~# sysctl vm.swappiness vm.swappiness = 1 root@erispoe:~# free -m total used free shared buffers cached Mem: 16034 13151 2882 419 28 470 -/+ buffers/cache: 12652 3381 Swap: 15359 1092 14267
Il y a presque 3G de RAM non-allouée sur 16G au total (ce qui fait clairement moins de 1 %), pourtant, il y a 1G de swap utilisé.
Quelqu’un a une idée pour expliquer ça ? La machine est une proxomox, donc basée sur Debian 8.6.
Question con : tu regardes la mémoire de ta machine au bout de combien de temps ? Il y a pu avoir une période bourrine sur la machine qui l'a fait swapper, et comme elle n'a pas eu besoin des données en swap depuis, c'est resté dans la swap.
Si tu as un munin, tu devrais pouvoir regarder ça.
Liste de diffusion du FRsAG http://www.frsag.org/
Et avec tout cet étalage de nourriture on s'étonne que le stéréotype de l'adminsys c'est un gros barbu...
Quand c'est qu'on passe au dessert ? =o)
On 17/12/2016 00:41, Pierre Colombier wrote:
il y eut un temps ou le kilo de ram coutait plus cher que le kilo de pain et on avait pas trop le choix.
Mais aujourd'hui la moindre machine a tout plein de gigots au point qu'on ne sait plus toujours quoi en faire et je ne vois pas très bien comme un système bien conçu sature ça (sans rencontrer un autre goulot d'étranglement avant.)
Hello,
Sauf que y a tj un mec dans la boîte qui vient faire chier à demander un environnement Java (sous couvert de Big data tout ça...) je suis d'accord il faudrait le licencier immédiatement mais en attendant c'est la fête du Swap...
</Troll>
Le 17 déc. 2016 00:42, "Pierre Colombier" pcdwarf@pcdwarf.net a écrit :
Bonsoir
L'explication est a mon avis que ta machine a du manquer de ram a un moment donné et mis des choses en swap.
Depuis la ram utilisée est redescendue mais les choses mises en swap ne sont remises en ram QUE quand le système en a réellement besoin.
Tu peux donc avoir du swap utilisé avec 90% de ram libre...
Je me permet de passer en mode troll
De mon expérience le swap, c'est le mal.
il y eut un temps ou le kilo de ram coutait plus cher que le kilo de pain et on avait pas trop le choix.
Mais aujourd'hui la moindre machine a tout plein de gigots au point qu'on ne sait plus toujours quoi en faire et je ne vois pas très bien comme un système bien conçu sature ça (sans rencontrer un autre goulot d'étranglement avant.)
D'expérience l'utilisation du Swap entraine une forte charge liée aux IO et au final une diminution de la capacité de traitement de la machine, ce qui se traduit par encore plus de ram utilisée par les process en concurrence et on va droit au crash...
Donc personellement, il n'y a plus jamais de swap dans mes serveurs sans une super bonne raison et soit on adapte le soft pour être surs de ne jamais saturer la ram (et en en laissant plein pour le cache disque), soit on augmente la capa de ram (ce qui est en fait vraiment très rare) .
On 16/12/2016 18:45, Guillaume GARNIER wrote:
Bonjoir,
pour savoir qui swap combien il y a ça, trouvé ici : https://www.cyberciti.biz/faq/linux-which-process-is-using-swap/
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
testé & approuvé, mais ça n'explique pas les causes
++
Guillaume
Le 16/12/2016 à 10:38, Luc Didry a écrit :
vendredi 16 décembre 2016, 10:20:56 CET Alarig Le Lay wrote:
Bonjour,
Soit c’est la fin de semaine, soit c’est ma mémoire qui me fait défaut, mais pour moi le swapiness définit le seuil de RAM libre à partir duquel la machine va commencer à swapper ?
Du coup, si je mets un swapiness à 1, je ne devrais pas avoir de données dans le swap tant que moins de 99 % de la RAM est utilisée.
Or, ce n’est pas ce que je vois actuellement : root@erispoe:~# sysctl vm.swappiness vm.swappiness = 1 root@erispoe:~# free -m total used free shared buffers cached Mem: 16034 13151 2882 419 28 470 -/+ buffers/cache: 12652 3381 Swap: 15359 1092 14267
Il y a presque 3G de RAM non-allouée sur 16G au total (ce qui fait clairement moins de 1 %), pourtant, il y a 1G de swap utilisé.
Quelqu’un a une idée pour expliquer ça ? La machine est une proxomox, donc basée sur Debian 8.6.
Question con : tu regardes la mémoire de ta machine au bout de combien
de temps ? Il y a pu avoir une période bourrine sur la machine qui l'a fait swapper, et comme elle n'a pas eu besoin des données en swap depuis, c'est resté dans la swap.
Si tu as un munin, tu devrais pouvoir regarder ça.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On Sat Dec 17 00:41:33 2016, Pierre Colombier wrote:
De mon expérience le swap, c'est le mal.
il y eut un temps ou le kilo de ram coutait plus cher que le kilo de pain et on avait pas trop le choix.
Mais aujourd'hui la moindre machine a tout plein de gigots au point qu'on ne sait plus toujours quoi en faire et je ne vois pas très bien comme un système bien conçu sature ça (sans rencontrer un autre goulot d'étranglement avant.)
La machine est raz-la-gueule en RAM, mais si tu as des barrettes 8G ECC en DDR3, on prend, c’est pas un souci :)
Mon propos est de dire que
- Soit tu a un bug/ fuite mémoire et ajouter du swap n'est pas une solution.
- Soit ton applicatif est mal branlé et fait une conso anormale de RAM et il faut taper sur les dev. (ou le sysadmin qui a autorisé plus de 1000 process concurrents sur son webserver)
- Soit tu as un besoin spécifique genre big data et là il faut expliquer à ton client qu'il te faut du big serveur et du big money parce que le swap ne sera jamais qu'une roue de secours. (une très mauvaise roue de secours parce que sur du disque mécanique, c'est affreusement lent, et sur du SSD, tu va vite cramer la flash, ce qui coutera rapidement autant que les barettes de ram)
Le 17/12/2016 à 14:47, Alarig Le Lay a écrit :
La machine est raz-la-gueule en RAM, mais si tu as des barrettes 8G ECC en DDR3, on prend, c’est pas un souci :)
Sur les serveurs physiques, plutôt que de virer la swap, tu peux la monter... en ram :)
https://www.kernel.org/doc/Documentation/blockdev/zram.txt
On dim., déc. 18, 2016 at 12:04 , Pierre Colombier pcdwarf@pcdwarf.net wrote:
Mon propos est de dire que
- Soit tu a un bug/ fuite mémoire et ajouter du swap n'est pas une
solution.
- Soit ton applicatif est mal branlé et fait une conso anormale de
RAM et il faut taper sur les dev. (ou le sysadmin qui a autorisé plus de 1000 process concurrents sur son webserver)
- Soit tu as un besoin spécifique genre big data et là il faut
expliquer à ton client qu'il te faut du big serveur et du big money parce que le swap ne sera jamais qu'une roue de secours. (une très mauvaise roue de secours parce que sur du disque mécanique, c'est affreusement lent, et sur du SSD, tu va vite cramer la flash, ce qui coutera rapidement autant que les barettes de ram)
Le 17/12/2016 à 14:47, Alarig Le Lay a écrit :
La machine est raz-la-gueule en RAM, mais si tu as des barrettes 8G
ECC
en DDR3, on prend, c’est pas un souci :)
Liste de diffusion du FRsAG http://www.frsag.org/
On Mon Dec 19 09:10:50 2016, yann+frsag@autissier.net wrote:
Sur les serveurs physiques, plutôt que de virer la swap, tu peux la monter... en ram :)
L’intérêt du swap, c’est justement de ne pas utiliser la RAM. Alors mettre le swap en RAM, je ne vois pas trop à quoi ça peut servir.
Zram, c'est de la ram compressée
Donc, c'est plus lent que de la ram "pure", mais ça prends moins de place
C'est une techno nettement moins délétère que le swap over hdd, pour sûr
On 19/12/2016 10:53, Alarig Le Lay wrote:
On Mon Dec 19 09:10:50 2016, yann+frsag@autissier.net wrote:
Sur les serveurs physiques, plutôt que de virer la swap, tu peux la monter... en ram :)
L’intérêt du swap, c’est justement de ne pas utiliser la RAM. Alors mettre le swap en RAM, je ne vois pas trop à quoi ça peut servir.
Liste de diffusion du FRsAG http://www.frsag.org/
On Mon Dec 19 10:58:59 2016, frsag@jack.fr.eu.org wrote:
Zram, c'est de la ram compressée
Donc, c'est plus lent que de la ram "pure", mais ça prends moins de place
C'est une techno nettement moins délétère que le swap over hdd, pour sûr
Mon problème n’était pas la place mais de savoir pourquoi ça swappait. Luc m’a donné l’explication et Guillaume et Yann m’ont donné du grain à moudre.
Mis à part ça, la machine se porte très bien, je ne vois donc aucune raison pour virer le swap et mettre autre chose à la place. Je vais me contenter de regarder ça en lab et ensuite on verra ce que l’on fait en prod.
Le 16/12/2016 à 10:20, Alarig Le Lay a écrit :
Bonjour,
« Ne rien tenter un vendredi » Proverbe Barbu circa 1990.
Exatement le mm problème. Le sysctl n'a pas changé, mais nos machines qui hébergent MariaDB swapent en Debian 8 alors qu'elles ne swapaient pas en Debian 7.
On Fri, 16 Dec 2016 10:20:56 +0100 Alarig Le Lay alarig@swordarmor.fr wrote:
Bonjour,
Soit c’est la fin de semaine, soit c’est ma mémoire qui me fait défaut, mais pour moi le swapiness définit le seuil de RAM libre à partir duquel la machine va commencer à swapper ?
Du coup, si je mets un swapiness à 1, je ne devrais pas avoir de données dans le swap tant que moins de 99 % de la RAM est utilisée.
Or, ce n’est pas ce que je vois actuellement : root@erispoe:~# sysctl vm.swappiness vm.swappiness = 1 root@erispoe:~# free -m total used free shared buffers cached Mem: 16034 13151 2882 419 28 470 -/+ buffers/cache: 12652 3381 Swap: 15359 1092 14267
Il y a presque 3G de RAM non-allouée sur 16G au total (ce qui fait clairement moins de 1 %), pourtant, il y a 1G de swap utilisé.
Quelqu’un a une idée pour expliquer ça ? La machine est une proxomox, donc basée sur Debian 8.6.
-
Alarig Le Lay -
Alexandre -
Christophe Casalegno (DN) -
frsag＠jack.fr.eu.org -
Guillaume GARNIER -
Jacques Lav!gnotte. -
Jonathan Tremesaygues -
Kevin Lemonnier -
Luc Didry -
merlin8282 -
Pierre Colombier -
Sylvain Rochet -
yann+frsag＠autissier.net -
Yohann Quinton