TCP-Tuning

TCP Performance

This page describes how to enhance the performance of data transfers. It mainly focus on the optimization of the Linux kernel parameters.

Quattor

The Quattor TCP Tuning guide aims to be a good documentation for helping you tuning your TCP Performance with Quattor.

Kernel tuning

The following parameters are important for TCP tuning:

• net.ipv4.tcp_rmem
• net.ipv4.tcp_wmem
• net.core.rmem_default
• net.core.wmem_default
• net.core.rmem_max
• net.core.wmem_max
• net.ipv4.tcp_dsack
• net.ipv4.tcp_sack
• net.ipv4.tcp_timestamps
• net.core.netdev_max_backlog

They can be modified:

• By directly passing the parameter to the sysctl command. This method is useful for testing a parameter, as the modification will not persist after the next reboot.
• By adding the parameter to the /etc/sysctl.conf file and loading it with the sysctl command. This way is interesting when you want to preserve the modification over a reboot.

The following values are recommended:

• net.ipv4.tcp_rmem = 131072 1048576 2097152
• net.ipv4.tcp_wmem = 131072 1048576 2097152
• net.core.rmem_default = 1048576
• net.core.wmem_default = 1048576
• net.core.rmem_max = 2097152
• net.core.wmem_max = 2097152
• net.ipv4.tcp_dsack = 0
• net.ipv4.tcp_sack = 0
• net.ipv4.tcp_timestamps = 0
• net.core.netdev_max_backlog = 10000

External links

• http://fasterdata.es.net/
• http://monalisa.cern.ch/FDT/documentation_syssettings.html
• http://indico.cern.ch/contributionDisplay.py?sessionId=31&contribId=55&confId=61917
• http://www.psc.edu/networking/projects/tcptune/
• http://onlamp.com/pub/a/onlamp/2005/11/17/tcp_tuning.html
• http://en.wikipedia.org/wiki/TCP_tuning

Tuning disk I/O

Kernel tuning

Le fait d'ajuster quelques paramètres du kernel permet d'améliorer les performances au niveau des I/O disques. Le tuning doit être fait au niveau des block devices après chaque reboot du serveur. Ce tuning peut être très utile sur les serveurs de fichiers (DPM disk servers, xrootd servers, ...).

Voici les valeurs recommandées pour un disque /dev/sdb par exemple :

• getra : 16384
• queue_depth : 256
• nr_requests : 512
• scheduler : deadline (au lieu de cfq)

Pour lire les valeurs actuelles de votre serveur pour le disque /dev/sdb, faire:

blockdev --getra /dev/sdb
cat /sys/block/sdb/device/queue_depth
cat /sys/block/sdb/queue/nr_requests
cat /sys/block/sdb/queue/scheduler

Exemple:

# blockdev --getra /dev/sdb
16384
# cat /sys/block/sdb/device/queue_depth
256
# cat /sys/block/sdb/queue/nr_requests
512
# cat /sys/block/sdb/queue/scheduler
noop anticipatory [deadline] cfq 
# 

Pour faire le tuning des I/O pour le disque sdb, faire:

blockdev=sdb
blockdev --setra 16384 /dev/${blockdev}
echo 512 > /sys/block/${blockdev}/queue/nr_requests
echo deadline > /sys/block/${blockdev}/queue/scheduler
echo 256 > /sys/block/${blockdev}/device/queue_depth

Le plus simple est de faire un script qui boucle sur tous les 'block devices' à tuner et d'ajuster les paramètres kernel pour chaque disque.

N.B.: chaque site peut tester éventuelement d'autres valeurs et benchmarker pour trouver les valeurs appropriées pour ses serveurs.

Une remarque concernant queue_depth: selon le modèle de serveur, il y a une valeur max qui ne peut être dépassée. Si on essaye d'affecter une valeur plus grande, c'est la valeur max possible qui sera affectée à queue_depth.

Par exemple sur un SUN X4500 si vous faites "echo 256 > /sys/block/sda/device/queue_depth", vous aurez en fait 31 (la valeur max autorisée) dans queue_depth.

External links

• https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/main-io.html
• https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/main-fs.html
• http://www.gluster.org/community/documentation/index.php/Linux_Kernel_Tuning
• http://insights.oetiker.ch/linux/raidoptimization/
• http://mylabfr.kaminoweb.com/increase-disk-queue-depth-on-linux/
• http://www.redhat.com/magazine/008jun05/features/schedulers/