Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 01/09/2022, à 10:54

Herby

Serveur NFS qui bouffe la mémoire swap

Bonjour,

J'ai un serveur NFS qui tourne sur un kubuntu 20.04LTS. J'ai remarqué que lorsque le serveur est sollicité pendant de longues périodes (comme actuellement où j'encode des fichiers vidéos hébergés sur le serveur pendant des journées entières), la mémoire swap du serveur est utilisée alors qu'il reste env 70% des 8GB de RAM disponibles. Cela a pour effet de ralentir considérablement le serveur.
J'ai baissé le réglage du "swappiness" à 40 grâce à cette méthode : https://askubuntu.com/questions/103915/ … swappiness
Mais cette dernière manip n'a rien changé.
Y'a-t-il un réglage au niveau du serveur pour éviter ce problème ?

Hors ligne

#2 Le 01/09/2022, à 14:26

geole

Re : Serveur NFS qui bouffe la mémoire swap

Bonjour
Es-tu certain de ton diagnostic?        Cela n'est peut-être pas spécial à NFS
Peux-tu donner ces retours

cat /proc/sys/vm/swappiness
sudo service procps restart
sudo swapoff -av
sudo swapon -av
LANG=C free -h

Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#3 Le 02/09/2022, à 06:27

Herby

Re : Serveur NFS qui bouffe la mémoire swap

Alors :

cat /proc/sys/vm/swappiness
40

"sudo service procps restart" ne renvoie rien

sudo swapoff -av
swapoff /dev/sdc5
sudo swapon -av
swapon: /dev/sdc5 : signature trouvée [pagesize=4096, signature=swap]
swapon: /dev/sdc5 : taille de page : 4096, taille d'espace d'échange : 12769558528, taille de périphérique : 12769558528
swapon /dev/sdc5
LANG=C free -h
              total        used        free      shared  buff/cache   available
Mem:          7,7Gi       1,6Gi       2,8Gi        57Mi       3,3Gi       5,8Gi
Swap:          11Gi          0B        11Gi

Après, je ne suis pas sûr à 100% que le problème vienne effectivement du serveur NFS mais ce problème n'apparaît que lorsque j'accède beaucoup et sur de longues périodes (plusieurs heures) aux fichiers partagés sur le serveur.

Hors ligne

#4 Le 02/09/2022, à 08:57

geole

Re : Serveur NFS qui bouffe la mémoire swap

Bonjour,
Je ne sais pas trop quoi proposer pour rechercher
A part surveiller avec cette commande

LANG=C free -h

Puis, lorsque le swap est important, il faudrait trouver une méthode pour savoir ce que c'est.
Je vais te donner ce  lien https://forum.ubuntu-fr.org/viewtopic.php?id=2023909
Spécialement échange 1 voir 26

Dernière modification par geole (Le 02/09/2022, à 09:14)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#5 Le 02/09/2022, à 11:14

Herby

Re : Serveur NFS qui bouffe la mémoire swap

J'ai attendu qques heures après avoir démarré le serveur et le swap commence à se remplir :

LANG=C free -h
              total        used        free      shared  buff/cache   available
Mem:          7,7Gi       2,7Gi       295Mi       124Mi       4,8Gi       4,7Gi
Swap:          11Gi       137Mi        11Gi
free -m ; echo ; top -b -n1 | head -5
              total       utilisé      libre     partagé tamp/cache   disponible
Mem:           7910        2712         212         124        4985        4783
Partition d'échange:       12177         137       12040

top - 17:06:05 up  4:56,  3 users,  load average: 0,20, 0,52, 0,74
Tâches: 246 total,   1 en cours, 244 en veille,   0 arrêté,   1 zombie
%Cpu(s):  1,5 ut,  3,0 sy,  0,0 ni, 95,5 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   7910,3 total,    211,8 libr,   2711,7 util,   4986,8 tamp/cache
MiB Éch:  12178,0 total,  12040,4 libr,    137,6 util.   4784,7 dispo Mem 
echo -e "\n\tCharge RAM en % décroissant :" ; ps aux | awk '{print $1,$2,$4,$11,$12 | "sort -k3Vr | column -t | head -25"}'

        Charge RAM en % décroissant :
USER      PID     %MEM  COMMAND
herby     5662    9.0   /usr/lib/firefox/firefox
herby     125183  5.9   /usr/lib/firefox/firefox                                             -contentproc
herby     5506    4.3   /usr/lib/thunderbird/thunderbird
herby     1560    3.5   /usr/bin/plasmashell
herby     123528  2.8   /usr/lib/firefox/firefox                                             -contentproc
herby     6027    2.8   /usr/lib/firefox/firefox                                             -contentproc
herby     21264   2.7   /usr/bin/telegram
herby     6105    2.1   /usr/lib/firefox/firefox                                             -contentproc
root      1274    1.9   /usr/lib/xorg/Xorg                                                   -nolisten
herby     5961    1.7   /usr/lib/firefox/firefox                                             -contentproc
herby     100661  1.5   /usr/lib/firefox/firefox                                             -contentproc
herby     1872    1.5   /home/herby/.cache/protonmail/bridge/updates/2.1.3/proton-bridge     --no-window
herby     107021  1.4   /usr/lib/firefox/firefox                                             -contentproc
herby     5842    1.3   /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
herby     1558    1.3   /usr/bin/kwin_x11
herby     14219   1.1   /usr/lib/firefox/firefox                                             -contentproc
herby     1509    1.1   kded5
herby     5639    1.0   /usr/lib/thunderbird/thunderbird                                     -contentproc
herby     154123  1.0   /usr/lib/firefox/firefox                                             -contentproc
herby     5691    0.9   /usr/lib/thunderbird/thunderbird                                     -contentproc
herby     164299  0.9   /usr/lib/firefox/firefox                                             -contentproc
herby     170512  0.9   /usr/lib/firefox/firefox                                             -contentproc
herby     174262  0.9   /usr/lib/firefox/firefox                                             -contentproc
herby     170639  0.8   /usr/bin/konsole
echo -e "\n\tPourcentage total de RAM consommée par leS processuS de firefox, hors Web Content et plugin-container :"; ps auxww | awk 'BEGIN{m=0.0} /firefox/{m+=$4} END{print m}'

        Pourcentage total de RAM consommée par leS processuS de firefox, hors Web Content et plugin-container :
24
echo -e "\n\tPourcentage total de RAM consommée par les tâches plugin-container et Web Content :"; top -bn1 | awk 'BEGIN{m=0.0} /plugin-co|[Ww]eb [Cc]o/{sub(",",".",$10) ; m+=$10} END{print m}'

        Pourcentage total de RAM consommée par les tâches plugin-container et Web Content :
11

Si je comprends bien, il semble que ce soit le cache qui prend ses aises au niveau de la RAM...

Hors ligne

#6 Le 02/09/2022, à 11:49

geole

Re : Serveur NFS qui bouffe la mémoire swap

Herby a écrit :

Si je comprends bien, il semble que ce soit le cache qui prend ses aises au niveau de la RAM...

C'est exactement cela..
A titre d'exemple, j'ai vu une documentation disant que si on veut utiliser ZFS, il faut au moins 64 Go de RAM afin que la compression des données soit efficace.

Tous les liens que je t'ai donné c'est pour le logiciel. Pour la gestion des caches, je ne connais pas. Du coup, il semble normal de NFS cherche à les utiliser au maxima afin d'éviter des échanges réseaux
Je découvre ces liens. https://serverfault.com/questions/66794 … s-from-nfs
https://docs.oracle.com/cd/E19620-01/80 … index.html
There is a huge memory usage on the client (could be more than 64GB, it takes as much memory as it can).
Optimizing Your NFS Filesystem

https://www.admin-magazine.com/HPC/Articles/Useful-NFS-Options-for-Tuning-and-Management a écrit :

Mémoire système

Les options de réglage du système ne sont pas vraiment des options de réglage NFS, mais une modification du système peut entraîner une modification des performances NFS. En général, Linux et ses services aiment la mémoire et prendront autant de mémoire système que possible. Bien sûr, cette mémoire est restituée si le système en a besoin pour d'autres applications, mais plutôt que de la perdre (c'est-à-dire qu'elle n'est pas utilisée), il l'utilise pour les tampons et les caches.

NFS est certainement l'un des services, en particulier sur le serveur, qui utilisera autant d'espace tampon que possible. Avec ces tampons, NFS peut fusionner les demandes d'E/S pour améliorer la bande passante. Par conséquent, plus vous pouvez ajouter de mémoire physique au serveur NFS, plus les performances sont susceptibles de s'améliorer, en particulier si de nombreux clients NFS accèdent au serveur en même temps. La question est : De combien de mémoire votre serveur NFS a-t-il besoin ?

La réponse n'est pas facile à déterminer en raison d'objectifs contradictoires. Idéalement, vous devriez mettre autant de mémoire dans le serveur que vous pouvez vous le permettre. Mais si les budgets sont un peu serrés, vous devrez faire des compromis entre acheter la plus grande quantité de mémoire pour le serveur NFS ou investir de l'argent dans d'autres aspects du système. Pourriez-vous réduire la mémoire sur le serveur NFS de 512 à 256 Go et peut-être acheter un nœud de calcul supplémentaire ? Est-ce que ça vaut l'échange ? La réponse dépend de vous.

En règle générale, pour les systèmes HPC de production, cependant, j'ai tendance à mettre pas moins de 64 Go sur le serveur NFS, car la mémoire est globalement moins chère. Vous pouvez toujours utiliser moins de mémoire, peut-être 16 Go, mais vous pourriez payer une pénalité de performance. Cependant, si vos applications n'effectuent pas beaucoup d'E/S, le compromis peut en valoir la peine.

Si vous choisissez d'utiliser le mode NFS asynchrone, vous aurez besoin de plus de mémoire pour tirer parti de l'asynchronisme, car le serveur NFS stockera d'abord la demande d'E/S en mémoire, répondra au client NFS, puis retirera les E/S en faire en sorte que le système de fichiers l'écrive dans un stockage stable. Par conséquent, vous avez besoin d'autant de mémoire que possible pour obtenir les meilleures performances.

Le tout dernier mot que je veux ajouter à propos de la mémoire système concerne la vitesse et le nombre de canaux mémoire. Pour tirer le meilleur parti des performances de votre serveur NFS, vous souhaiterez la mémoire la plus rapide possible, tout en reconnaissant le compromis entre la capacité de mémoire et les performances de la mémoire. La solution au compromis dépend vraiment de vous, mais j'aime voir combien de mémoire je peux obtenir en utilisant les modules DIMM de mémoire les plus rapides possibles. Si la capacité de la mémoire n'est pas assez grande, vous souhaiterez peut-être passer au niveau supérieur de la vitesse de la mémoire pour augmenter la capacité.

Pour obtenir les meilleures performances possibles, vous souhaitez également un serveur NFS avec le nombre maximal de canaux de mémoire pour augmenter la bande passante mémoire globale du serveur. Dans chaque canal mémoire, veillez à mettre :
    au moins un module DIMM dans chaque canal,
    le même nombre de modules DIMM dans chaque canal, et
    la même taille et la même vitesse DIMM dans chaque canal.

Encore une fois, cela est plus susceptible d'être critique si vous utilisez le mode asynchrone, mais c'est une bonne idée même pour le mode synchrone.

Je ne sais pas en dire plus.

Dernière modification par geole (Le 02/09/2022, à 12:20)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#7 Le 02/09/2022, à 12:16

Herby

Re : Serveur NFS qui bouffe la mémoire swap

geole a écrit :

J'ai vu une documentation disant que si on veux utiliser ZFS, il faut au moins 64 Go de RAM afin que la compression des données soit efficace.

Certes mais je n'utilise pas le ZFS. En l'occurence, le disque partagé par le serveur est en ext4.

A la lecture des différents liens dans le post précédent, j'ai le sentiment que la seule solution serait de rajouter de la RAM sur le serveur.

Hors ligne

#8 Le 02/09/2022, à 12:26

geole

Re : Serveur NFS qui bouffe la mémoire swap

Il y a probablement un paramétrage d'initialisation  dans NFS permettant de se limiter à   tant de taille...   
Le problème est de le trouver pour ta version logicielle actuelle  qui est 20.04

il faudrait chercher tunning nfs

# Check the NFS server statistics with nfsstat.
nfsstat -4 -s 

Dernière modification par geole (Le 02/09/2022, à 12:50)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#9 Le 02/09/2022, à 14:03

Herby

Re : Serveur NFS qui bouffe la mémoire swap

nfsstat -4 -s 
Server rpc stats:
calls      badcalls   badfmt     badauth    badclnt
1372284    0          0          0          0       

Server nfs v4:
null             compound         
0         0%     0         0%     

Server nfs v4 operations:
op0-unused       op1-unused       op2-future       access           close            
0         0%     0         0%     0         0%     0         0%     0         0%     
commit           create           delegpurge       delegreturn      getattr          
0         0%     0         0%     0         0%     0         0%     0         0%     
getfh            link             lock             lockt            locku            
0         0%     0         0%     0         0%     0         0%     0         0%     
lookup           lookup_root      nverify          open             openattr         
0         0%     0         0%     0         0%     0         0%     0         0%     
open_conf        open_dgrd        putfh            putpubfh         putrootfh        
0         0%     0         0%     0         0%     0         0%     0         0%     
read             readdir          readlink         remove           rename           
0         0%     0         0%     0         0%     0         0%     0         0%     
renew            restorefh        savefh           secinfo          setattr          
0         0%     0         0%     0         0%     0         0%     0         0%     
setcltid         setcltidconf     verify           write            rellockowner     
0         0%     0         0%     0         0%     0         0%     0         0%     
bc_ctl           bind_conn        exchange_id      create_ses       destroy_ses      
0         0%     0         0%     0         0%     0         0%     0         0%     
free_stateid     getdirdeleg      getdevinfo       getdevlist       layoutcommit     
0         0%     0         0%     0         0%     0         0%     0         0%     
layoutget        layoutreturn     secinfononam     sequence         set_ssv          
0         0%     0         0%     0         0%     0         0%     0         0%     
test_stateid     want_deleg       destroy_clid     reclaim_comp     allocate         
0         0%     0         0%     0         0%     0         0%     0         0%     
copy             copy_notify      deallocate       ioadvise         layouterror      
0         0%     0         0%     0         0%     0         0%     0         0%     
layoutstats      offloadcancel    offloadstatus    readplus         seek             
0         0%     0         0%     0         0%     0         0%     0         0%     
write_same       
0         0%   

En voyant ce résultat, j'ai fait :

nfsstat -3 -s 
Server rpc stats:
calls      badcalls   badfmt     badauth    badclnt
1376249    0          0          0          0       

Server nfs v3:
null             getattr          setattr          lookup           access           
2         0%     19169     1%     0         0%     288667   20%     99038     7%     
readlink         read             write            create           mkdir            
0         0%     861345   62%     0         0%     0         0%     0         0%     
symlink          mknod            remove           rmdir            rename           
0         0%     0         0%     0         0%     0         0%     0         0%     
link             readdir          readdirplus      fsstat           fsinfo           
0         0%     0         0%     99159     7%     8831      0%     1         0%     
pathconf         commit           
1         0%     0         0%     

... et je me dis que, peut-être, en passant tout ça en NFS V4, ça pourrait être mieux. Je ne vois pas de la raison pour laquelle le serveur fonctionne en V3 !

ps: entre 2, j'ai désactivé/réactivé le sawp (sudo swapoff -av puis sudo swapon -av) et, pour l'instant, le swap reste à 0%.

Hors ligne