1 votes

Baisse de la vitesse d'écriture NFS en cas de procédure commit défectueuse

Tout d'abord, je m'excuse de poser une question d'étude évidente. Je sais que c'est une mauvaise habitude, mais j'espère que j'obtiendrai encore de l'aide ici, car j'ai fait une tonne de recherches et je n'ai pas trouvé de réponse à cette question.

Les scénario est la suivante : Un client NFS écrit un fichier unique de 50 Go sur le serveur NFS. Après avoir écrit 4GB avec une vitesse moyenne de 125 MByte/s, il tombe à 12MByte/s.

Question : Comment pouvez-vous expliquer cela ?

Les donné responder**** La réponse à la question est la suivante : Après 4 Go d'écriture, le serveur ne répond pas au commit et le client envoie périodiquement des commit jusqu'à ce que le serveur y réponde, parce que le client veut vider son cache. Dans ce laps de temps, le débit de données tombe au niveau de l'élément le plus lent.

Tout ce que je peux trouver sur le processus commit est une explication comme celle-ci :

Le client écrit des données et lorsque les données sont transférées au serveur, le client envoie le message commit. Le serveur écrit les données dans le stockage stable et répond au commit avec le verf-Cookie. Si le cookie n'est PAS différent de celui du client, le client peut vider son cache.

Voici donc ma question : Est-il vrai que si le serveur ne répond pas à la procédure commit en envoyant le verf-cookie, le client envoie périodiquement des commit et le débit de données diminue considérablement ? Si oui, jusqu'à quel niveau le débit baisse-t-il ? Je ne peux pas conclure à partir de la réponse à quel niveau le débit de données baisse.

1voto

kofemann Points 4088

Je pense qu'il se passe ce qui suit :

Les données envoyées par le client sont enregistrées dans la mémoire cache du serveur. Une fois que la requête commit est envoyée, ces données commencent à être transférées vers le stockage persistant (DISK). En fonction des performances du disque du serveur, cette opération peut prendre un certain temps. Supposons que la performance du disque soit de 300MB/s. Pour transférer 4 Go, il faudra 13 secondes. Si ce temps est supérieur au délai d'attente de NFS, le client peut envoyer une autre requête commit, en supposant que la première a été perdue. Le vérificateur commit/WRITE est utilisé pour s'assurer que le serveur n'est pas redémarré entre ces opérations.

Dans ce cas, vous pouvez agir :

  • augmenter le délai d'attente NFS sur le client en spécifiant timeo= option de montage. Bien que cela ne permette que de fixer retried commits.
  • indique au serveur de commencer à extraire les données suffisamment tôt pour éviter les retards dans l'enregistrement.

utiliser

sysctl -w vm.dirty_background_ratio=0
sysctl -w vm.dirty_ratio=0
sysctl -w vm.dirty_background_bytes=67108864
sysctl -w vm.dirty_bytes=536870912

Les tailles doivent être ajustées en fonction des performances IO du serveur et de l'étendue du réseau.

Permet de contrôler le moment où le noyau commence à vider les données sur le disque du serveur et les envoie au serveur du côté du client.

REMARQUE : ces options sont globales et affectent tous les systèmes de fichiers.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X