J'ai récemment eu l'occasion de revoir les paramètres du noyau, alors notez-les.
Après avoir examiné diverses informations de réglage au cours des dernières années, il semblait bon de définir les paramètres suivants.
| Le nom du paramètre | Définir la valeur | La description |
|---|---|---|
| fs.file-max | Verification requise | Limite du descripteur de fichier à l'échelle du système |
| kernel.threads-max | Verification requise | Nombre maximum de processus dans l'ensemble du système |
| net.core.netdev_max_backlog | Verification requise | Nombre maximum de paquets que le noyau peut mettre en file d'attente |
| net.netfilter.nf_conntrack_max | Verification requise | Ajustez le nombre maximum de connexions simultanées avec netfilter |
| vm.swappiness | 0 | Définissez la facilité de SWAP * Si SWAP est exécuté même avec 0, SWAP est exécuté. |
| Le nom du paramètre | Définir la valeur | La description |
|---|---|---|
| kernel.sysrq | 0 | SysRq(Configuration requise)Désactiver la clé |
| net.ipv4.conf.all.accept_source_route | 0 | Désactiver le routage source |
| net.ipv4.conf.all.rp_filter | 1 | rp_filter(reverse path filter)Activer |
| net.ipv4.conf.default.rp_filter | 1 | rp_filter(reverse path filter)Activer |
| net.ipv4.ip_forward | 0 | Désactiver le transfert IP |
| net.ipv4.tcp_syncookies | 1 | tcp_Activer les cookies de synchronisation * Mesures SYN FLOOD |
| Le nom du paramètre | Définir la valeur | La description |
|---|---|---|
| net.core.rmem_max | Verification requise | Définir la taille maximale du tampon de réception TCP |
| net.core.somaxconn | Verification requise | Longueur maximale de la file d'attente pour stocker les demandes de connexion acceptées par les sockets TCP |
| net.core.wmem_max | Verification requise | Taille maximale du tampon d'envoi TCP |
| net.ipv4.ip_local_port_range | Verification requise | TCP/Modifier la plage de ports de transmission IP |
| net.ipv4.tcp_fin_timeout | 5〜30 | Délai d'expiration du paquet FIN |
| net.ipv4.tcp_keepalive_intvl | sec<75 | Intervalle d'envoi du paquet TCP keepalive(Secondes) |
| net.ipv4.tcp_keepalive_time | sec<7200 | Il est temps d'envoyer un paquet TCP keepalive(Secondes) |
| net.ipv4.tcp_keepalive_probes | count<9 | Nombre de fois pour envoyer un paquet keepalive |
| net.ipv4.tcp_max_syn_backlog | Verification requise | Le nombre de connexions qui peuvent contenir une connexion qui accepte SYN par socket et ne reçoit pas ACK |
| net.ipv4.tcp_max_tw_buckets | Verification requise | TIME détenu par le système en même temps_Nombre maximum de prises WAIT |
| net.ipv4.tcp_orphan_retries | Verification requise | Nombre de renvois avant de mettre fin à la connexion TCP fermée à partir d'ici |
| net.ipv4.tcp_rfc1337 | 1 | Conformez-vous à RFC1337 ※TIME_Si RST est reçu en état WAIT, TIME_Fermez la prise sans attendre la fin de la période WAIT |
| net.ipv4.tcp_slow_start_after_idle | 0 | Désactiver le démarrage lent une fois la communication inactive |
| net.ipv4.tcp_syn_retries | 3 | Nombre de tentatives d'envoi de SYN TCP |
| net.ipv4.tcp_tw_reuse | 1 | TIME_Réutiliser la connexion WAIT |
Il existe de nombreux éléments de réglage pour les paramètres du noyau, et il existe un outil conçu pour faciliter la gestion par les humains.
Dans le réglage, le réglage peut être effectué par un profil en fonction du type de serveur, et j'ai examiné les éléments à régler en référence à ces valeurs de réglage.
Les profils sont préparés en fonction du type de serveur comme suit.
Puisque le profil décrit les paramètres typiques du noyau pour le réglage, considérons les paramètres du noyau en référence à cela.
$ ls -l /usr/lib/tuned/
total 56
drwxr-xr-x. 2 root root 4096 Sep 9 2019 balanced
drwxr-xr-x. 2 root root 4096 Sep 9 2019 desktop
-rw-r--r-- 1 root root 14413 Mar 14 2019 functions
drwxr-xr-x. 2 root root 4096 Sep 9 2019 latency-performance
drwxr-xr-x. 2 root root 4096 Sep 9 2019 network-latency
drwxr-xr-x. 2 root root 4096 Sep 9 2019 network-throughput
drwxr-xr-x. 2 root root 4096 Sep 9 2019 powersave
drwxr-xr-x. 2 root root 4096 Sep 9 2019 recommend.d
drwxr-xr-x. 2 root root 4096 Sep 9 2019 throughput-performance
drwxr-xr-x. 2 root root 4096 Sep 9 2019 virtual-guest
drwxr-xr-x. 2 root root 4096 Sep 9 2019 virtual-host
Par la description ʻinclude = throughput-performance, vous pouvez voir que le modèle de throughput-performance` est inclus.
** * La ligne de commentaire est masquée car seule la valeur définie est affichée **
/usr/lib/tuned/virtual-guest/tuned.conf
[main]
summary=Optimize for running inside a virtual guest
include=throughput-performance
[sysctl]
vm.dirty_ratio = 30
vm.swappiness = 30
Voici le modèle débit-performances inclus.
Vous pouvez voir qu'il contient les paramètres du processeur et du disque en plus des paramètres du noyau.
/usr/lib/tuned/throughput-performance/tuned.conf
[main]
summary=Broadly applicable tuning that provides excellent performance across a variety of common server workloads
[cpu]
governor=performance
energy_perf_bias=performance
min_perf_pct=100
[disk]
readahead=>4096
[sysctl]
kernel.sched_min_granularity_ns = 10000000
kernel.sched_wakeup_granularity_ns = 15000000
vm.dirty_ratio = 40
vm.dirty_background_ratio = 10
vm.swappiness=10
J'ai défini les paramètres du noyau définis en tant qu'essai et j'ai essayé de lister les valeurs réellement définies comme suit.
Il semble que s'il y a la même valeur de paramètre que le modèle inclus, il sera fusionné, mais comme il s'agit de vm.swappiness = 30, il ne remplace pas nécessairement après Inclure.
| Le nom du paramètre | Définir la valeur | La description |
|---|---|---|
| vm.dirty_ratio | 40 | Quantité maximale absolue de mémoire système pouvant être remplie de pages sales avant d'être validées sur le disque |
| vm.swappiness | 30 | Définissez la facilité de SWAP |
| kernel.sched_min_granularity_ns | 10000000 | Période minimale du planificateur pour les cibles sur lesquelles une seule tâche s'exécute |
| kernel.sched_wakeup_granularity_ns | 15000000 | Granularité de préemption lorsqu'une tâche est lancée |
| vm.dirty_background_ratio | 10 | Lorsque le pourcentage de pages sales atteint cette valeur, pdflush exportera dans un arrière-plan de faible priorité. |
Par la description ʻinclude = throughput-performance, vous pouvez voir que le modèle de throughput-performance` est inclus.
** * La ligne de commentaire est masquée car seule la valeur définie est affichée **
/usr/lib/tuned/network-throughput/tuned.conf
[main]
summary=Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
include=throughput-performance
[sysctl]
net.ipv4.tcp_rmem="4096 87380 16777216"
net.ipv4.tcp_wmem="4096 16384 16777216"
net.ipv4.udp_mem="3145728 4194304 16777216"
Le modèle inclus de "performance de débit" a déjà été décrit dans la section précédente et sera omis.
J'ai défini les paramètres du noyau définis en tant qu'essai et j'ai essayé de lister les valeurs réellement définies comme suit.
Il semble que s'il y a la même valeur de paramètre que le modèle inclus, il sera fusionné, mais comme il s'agit de vm.swappiness = 30, il ne remplace pas nécessairement après Inclure.
| Le nom du paramètre | Définir la valeur | La description |
|---|---|---|
| vm.dirty_ratio | 40 | Quantité maximale absolue de mémoire système pouvant être remplie de pages sales avant d'être validées sur le disque |
| vm.swappiness | 30 | Définissez la facilité de SWAP |
| kernel.sched_min_granularity_ns | 10000000 | Période minimale du planificateur pour les cibles sur lesquelles une seule tâche s'exécute |
| kernel.sched_wakeup_granularity_ns | 15000000 | Granularité de préemption lorsqu'une tâche est lancée |
| vm.dirty_background_ratio | 10 | Lorsque le pourcentage de pages sales atteint cette valeur, pdflush exportera dans un arrière-plan de faible priorité. |
| net.ipv4.tcp_rmem | 4096 87380 16777216 | Recevoir la taille du tampon du socket TCP(min, default, max) |
| net.ipv4.tcp_wmem | 4096 16384 16777216 | Taille du tampon d'envoi du socket TCP(min, default, max) |
| net.ipv4.udp_mem | 3145728 4194304 16777216 | Taille du tampon de socket UDP(min, default, max) |
invité virtuel, la même valeur par défaut que lors de la construction du serveur (varie pour chaque serveur) est définie.network-throughput, la taille de la mémoire tampon a été augmentée par rapport à la valeur par défautvm.swappiness et vm.dirty_ratio, il semble qu'une bonne politique change de manière appropriée en fonction de l'environnement à utiliser.Je pense qu'il est logique du point de vue des performances de sécurité de définir correctement les paramètres du noyau pour chaque serveur.
Récemment, la popularité des technologies de conteneurs telles que k8s augmente, mais même ainsi, il semble qu'il existe encore de nombreuses opportunités pour exploiter des serveurs, pas seulement sur le pré-cloud, donc je voudrais les définir de manière appropriée.
Recommended Posts