Post Installation Debian Stretch 9

Le montage de disque NFS sous OS X 10.12 (Sierra) était très lent et de nombreux messages d'erreurs de la forme suivante apparaissent dans les logs du noyau :

Jul 30 19:20:14 popeye kernel: [16805.379707] lockd: cannot monitor portable.home

Après plusieurs heures de recherche, il s'avère que OS X ne fait toujours pas des montages en NFS v4 mais v3 ce qui nécessite plusieurs options à mettre en oeuvre via le fichier /etc/default/nfs-common :

/etc/default/nfs-common

# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=yes
 
# Options for rpc.statd.
#   Should rpc.statd listen on a specific port? This is especially useful
#   when you have a port-based firewall. To use a fixed port, set this
#   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
#   For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
STATDOPTS=
 
# Do you want to start the idmapd daemon? It is only needed for NFSv4.
NEED_IDMAPD=yes
 
# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=

et surtout l'activation du service rpc-statd :

sudo systemctl enable rpc-statd
sudo systemctl start rpc-statd

Un reboot, pour être sûr de bien relancer le démon NFS et les montages sous OS X passent alors sans problèmes !

Par défaut, le governor de changement de fréquence du CPU optimise la consommation d'énergie. C'est intéressant mais pour un serveur avec une fréquence si petite, cela fait la différence. Ici, la taille compte .

Pour commencer, vérifions le governor utilisé :

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

Et de manière cohérente, la fréquence de la CPU est loin d'être à son maximum :

grep -E '^model name|^cpu MHz' /proc/cpuinfo
model name      : Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
cpu MHz         : 479.980
model name      : Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
cpu MHz         : 479.980
model name      : Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
cpu MHz         : 479.980
model name      : Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
cpu MHz         : 482.226

Le paquet cpufrequtils contient le programme cpufreq-info offrant peu plus de détails :

sudo cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.         
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  hardware limits: 480 MHz - 2.08 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 480 MHz and 2.08 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 894 GHz (asserted by call to hardware).
[...]
analyzing CPU 3:                      
  driver: intel_pstate               
  CPUs which run at the same hardware frequency: 3   
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 0.97 ms.                                    
  hardware limits: 480 MHz - 2.08 GHz
  available cpufreq governors: performance, powersave             
  current policy: frequency should be within 480 MHz and 2.08 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.              
  current CPU frequency is 716 MHz (asserted by call to hardware). 

Pour changer le governor en performance (fréquence CPU montant plus facilement au maximum), il suffit de passer la commande suivante :

for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n performance > $CPUFREQ; done

Par contre, après un redémarrage, cela est perdu. Pour charger les governors au boot, activer le script d'init suivant :

sudo systemctl enable cpufrequtils.service

Créer un fichier de configuration /etc/default/cpufrequtils avec :

/etc/default/cpufrequtils

ENABLE="true"
GOVERNOR="performance"
MIN_SPEED="1000"

et lancer le service :

sudo systemctl start cpufrequtils.service

verifier son statut :

sudo systemctl status cpufrequtils.service
● cpufrequtils.service - LSB: set CPUFreq kernel parameters
   Loaded: loaded (/etc/init.d/cpufrequtils; generated; vendor preset: enabled)
   Active: active (exited) since Sun 2017-08-13 22:11:38 CEST; 12min ago
     Docs: man:systemd-sysv-generator(8)
 
Aug 13 22:11:38 popeye systemd[1]: Starting LSB: set CPUFreq kernel parameters...
Aug 13 22:11:38 popeye cpufrequtils[25261]: CPUFreq Utilities: Setting performance CPUFreq governor...CPU0...CPU1...CPU2...CPU3...done.
Aug 13 22:11:38 popeye systemd[1]: Started LSB: set CPUFreq kernel parameters.

Vérifions rapidement le governors :

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance

La fréquence CPU n'est pas encore au max mais monte beaucoup plus facilement qu'avant :

grep -E '^model name|^cpu MHz' /proc/cpuinfo
model name      : Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
cpu MHz         : 860.742
model name      : Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
cpu MHz         : 799.023
model name      : Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
cpu MHz         : 1284.179
model name      : Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
cpu MHz         : 1140.917

Le temps de reconstruction de la grappe raid est limité par 2 paramètres logiciels : débit minimum et maximum. La première option permet, si le débit des disques est suffisant, de garantir un temps de reconstruction minimal, la 2^e option évite de saturer les ressources qu'avec la reconstruction pour continuer à rendre service aux utilisateurs. Il faut avoir en tête que plus le temps de reconstruction est long, plus le risque de casse d'un disque pendant cette opération augmente.

# min : 50 Mo/s
echo 50000 > /proc/sys/dev/raid/speed_limit_min
# max : 200 Mo/s
echo 200000 > /proc/sys/dev/raid/speed_limit_max

Choix des disques en Raid 5

Pour construire une grappe raid, il faut utiliser des disques de marques différentes ou au moins de lot différent. En effet, en raid, comme les lectures et écritures sont dispatchées entre les disques, ils sont tous sollicités de la même manière, vont donc s'user à la même vitesse. Si les modèles sont identiques, lorsqu'un disque cassera, il y a une probabilité non négligeable que les autres suivent rapidement. Très rapidement. Genre pendant la reconstruction lors du remplacement du premier disque HS. Et là, c'est le drame . Pour mémoire, le raid5 ne supporte qu'une seule perte… C'est pour cela que le raid6 existe. Malheureusement je n'ai pas assez de place physique dans mon serveur pour y mettre 4 disques 3.5“ Un jour peut être, je passerais sur des disques 2.5” et là je pourrais refaire mon support de disques.

Le cache de pre-lecture des fichiers (read ahead) permet de mettre en mémoire les blocs de fichiers à venir, cette optimisation est decidée par le noyau et est notamment facile à appréhender sur les fichiers vidéos : la lecture démarre au début du fichier et avance granduellement le long du fichier au cours du temps. Pour diminuer les accès disques, le noyau va anticiper les lectures en lisant en avance les blocs suivants de ceux démandé et les stocke en mémoire RAM. Pour tailler au plus précis ce cache, il faut d'abord connaitre la taille des blocs lus :

sudo blockdev --report | grep /dev/md
rw  4096   512  4096          0   2000006676480   /dev/md1
rw   256   512  1024          0       197361664   /dev/md0

La 2^e colonne indique la taille du cache en nombre de bloc et la 3^e colonne la taille d'un bloc, donc ici, $4096*512=2097152$ octets, soit 2 Mo. Pour l'augmenter à 32 Mo, il faut utiliser :

blockdev --setra 65536 /dev/md1

Un autre cache peut être agrandi, uniquement en raid 5 : celui de répartition des écritures entre disque.

echo 32768 > /sys/block/md1/md/stripe_cache_size

Les disques sont capables de ré-ordonnancer les ordres d'écritures transmis par le noyau pour améliorer les perfs. Néanmoins, il semblerait que pour du raid5, cela dégrade les performances. Voici le bout de script pour désactive le NCQ des disques :

for i in sda sdb sdc
do
  echo 1 > /sys/block/$i/device/queue_depth
done

L'effet de toutes ces commandes est perdu à chaque reboot. Plusieurs solutions existent pour les rendre persistantes : règles udev, sysctl.conf.d/… et le bon vieux /etc/rc.local. Ce fichier est exécuté au démarrage du serveur si le bit d'exécution est positionné :

sudo chmod +x /etc/rc.local

Il suffit d'ajouter toutes ces commandes dedans pour qu'elles soient rejouées au démarrage.

• https://wiki.fd.io/view/VPP/How_To_Optimize_Performance_(System_Tuning)
• http://dak1n1.com/blog/7-performance-tuning-intel-10gbe/
• https://www.kernel.org/doc/Documentation/IRQ-affinity.txt
• http://www.alexonlinux.com/why-interrupt-affinity-with-multiple-cores-is-not-such-a-good-thing