Auteur Sujet: Comparatif des performances coté serveur - Ubuntu Server 11.04 vs 11.10  (Lu 6716 fois)

0 Membres et 1 Invité sur ce sujet

Boris de Bouygues Telecom

  • AS5410 Expert Bouygues Telecom
  • Abonné Bbox fibre
  • *
  • Messages: 2 763
  • Technopôle de Bouygues Telecom sur Meudon (92)
Edit Vivien : la réponse aux questions posées sur l’augmentation des performances avec un noyeau linux récent est décris dans le post Patch Google ou "TCP Initial Congestion Window" à 10

Comparatif des performances coté serveur - Ubuntu Server 11.04 <=> Ubuntu Server 11.10.

Ubuntu 11.10 est sorti la semaine dernière (le 13 octobre 2011) et j'ai réalisé des tests de non régression de performance, avant une mise en prod, Bouygues Telecom ayant certains serveurs équipé d'Ubuntu (et beaucoup de Solaris). On parle là des performance lié au système d’exploitation serveur et non le système d'exploitation client.

Quelle surprise quand je constate que les résultats sont nettement meilleurs en passant d'Ubuntu Server 11.04 (équipé de linux 2.6.38) à Ubuntu Server 11.10 (équipé du nouveau noyau Linux 3.0). La montée en débit de TCP se fait bien plus vite avec le noyeau linux 3.0 (je suppose que c'est lié a la pile TCP/IP du noyeau, mais ce n'est qu'une supposition)

Si vous avez des informations sur cette différence de performance, je suis intéressé car je n'ai pas lu de gros changement au niveau de la couche TCP/IP entre le noyeau 2.6.38 et le noyeau 3.0.

La courbe noire (Ubuntu 11.10) se met tout de suite au débit maximal de 100 Mb/s alors que la courbe rouge met du temps à monter en débit, ce qui explique une durée de téléchargement du fichier plus importante. J'ai réaliser ces tests avec une Bbox fibre 100 Mb/s en maquette : Je suis seul sur ma poche afin d'être sur d'avoir 100% du temps le débit maximal.


Un plus petit fichier avec un client Windows 7, afin de vérifier que le gain est bien pour tous les clients et pas uniquement les Linux :

vivien

  • Administrateur
  • *
  • Messages: 47 178
    • Twitter LaFibre.info
Comparatif des performance coté serveur - Ubuntu Server 11.04 vs 11.10
« Réponse #1 le: 18 octobre 2011 à 07:44:07 »
Je viens de migrer ce matin LaFibre.info (et donc le serveur PingTest et SpeedTest de Lyon) de Ubuntu Server 11.04 à Ubuntu Server 11.10.

Boris de Bouygues Telecom

  • AS5410 Expert Bouygues Telecom
  • Abonné Bbox fibre
  • *
  • Messages: 2 763
  • Technopôle de Bouygues Telecom sur Meudon (92)
Comparatif des performance coté serveur - Ubuntu Server 11.04 vs 11.10
« Réponse #2 le: 18 octobre 2011 à 09:43:17 »
Le serveur SpeedTest d'Aubervilliers, hébergé par Bouygues Telecom, va migrer de Ubuntu Server 11.04 à Ubuntu Server 11.10 lundi 31 octobre au soir.

Cela donne 2 semaines pour faire des tests comparatifs  ;)

Cordialement,
Boris de Bouygues Telecom.

corrector

  • Invité
Comparatif des performance coté serveur - Ubuntu Server 11.04 vs 11.10
« Réponse #3 le: 25 octobre 2011 à 03:18:43 »
for x in /proc/sys/net/core/*mem* /proc/sys/net/ipv4/*tcp* ; do
echo "$x: `cat $x`"
done

Boris de Bouygues Telecom

  • AS5410 Expert Bouygues Telecom
  • Abonné Bbox fibre
  • *
  • Messages: 2 763
  • Technopôle de Bouygues Telecom sur Meudon (92)
Comparatif des performance coté serveur - Ubuntu Server 11.04 vs 11.10
« Réponse #4 le: 25 octobre 2011 à 10:27:43 »
J'ai déjà regardé les paramètres sensible tel que tcp_rmem et tcp_wmem sans voir de différence apporté entre les deux versions.

Voici les paramètres complets pour Ubuntu Server 11.10 64bits équipé de Linux 3.0.0
En rouge les paramètres qui différent pour Ubuntu Server 11.04 64bits équipé de Linux 2.6.38
Matériellement c'est dans les deux cas un serveur Dell PowerEdge R210 avec un Intel Xeon X3450 + 4 Go de RAM (la quantité de ram influe sur les valeurs de Rwin)

/proc/sys/net/core/optmem_max: 20480
/proc/sys/net/core/rmem_default: 126976
/proc/sys/net/core/rmem_max: 131071
/proc/sys/net/core/wmem_default: 126976
/proc/sys/net/core/wmem_max: 131071
/proc/sys/net/ipv4/tcp_abc: 0
/proc/sys/net/ipv4/tcp_abort_on_overflow: 0
/proc/sys/net/ipv4/tcp_adv_win_scale: 2
/proc/sys/net/ipv4/tcp_allowed_congestion_control: cubic reno
/proc/sys/net/ipv4/tcp_app_win: 31
/proc/sys/net/ipv4/tcp_available_congestion_control: cubic reno
/proc/sys/net/ipv4/tcp_base_mss: 512
/proc/sys/net/ipv4/tcp_congestion_control: cubic
/proc/sys/net/ipv4/tcp_cookie_size: 0
/proc/sys/net/ipv4/tcp_dma_copybreak: 4096
/proc/sys/net/ipv4/tcp_dsack: 1
/proc/sys/net/ipv4/tcp_ecn: 2
/proc/sys/net/ipv4/tcp_fack: 1
/proc/sys/net/ipv4/tcp_fin_timeout: 60
/proc/sys/net/ipv4/tcp_frto: 2
/proc/sys/net/ipv4/tcp_frto_response: 0
/proc/sys/net/ipv4/tcp_keepalive_intvl: 75
/proc/sys/net/ipv4/tcp_keepalive_probes: 9
/proc/sys/net/ipv4/tcp_keepalive_time: 7200
/proc/sys/net/ipv4/tcp_low_latency: 0
/proc/sys/net/ipv4/tcp_max_orphans: 262144
/proc/sys/net/ipv4/tcp_max_ssthresh: 0
/proc/sys/net/ipv4/tcp_max_syn_backlog: 2048
/proc/sys/net/ipv4/tcp_max_tw_buckets: 262144
/proc/sys/net/ipv4/tcp_mem: 96387   128516   192774   377856   503808   755712
/proc/sys/net/ipv4/tcp_moderate_rcvbuf: 1
/proc/sys/net/ipv4/tcp_mtu_probing: 0
/proc/sys/net/ipv4/tcp_no_metrics_save: 0
/proc/sys/net/ipv4/tcp_orphan_retries: 0
/proc/sys/net/ipv4/tcp_reordering: 3
/proc/sys/net/ipv4/tcp_retrans_collapse: 1
/proc/sys/net/ipv4/tcp_retries1: 3
/proc/sys/net/ipv4/tcp_retries2: 15
/proc/sys/net/ipv4/tcp_rfc1337: 0
/proc/sys/net/ipv4/tcp_rmem: 4096   87380   4112512    4096   87380   4194304
/proc/sys/net/ipv4/tcp_sack: 1
/proc/sys/net/ipv4/tcp_slow_start_after_idle: 1
/proc/sys/net/ipv4/tcp_stdurg: 0
/proc/sys/net/ipv4/tcp_syn_retries: 5
/proc/sys/net/ipv4/tcp_synack_retries: 5
/proc/sys/net/ipv4/tcp_syncookies: 1
/proc/sys/net/ipv4/tcp_thin_dupack: 0
/proc/sys/net/ipv4/tcp_thin_linear_timeouts: 0
/proc/sys/net/ipv4/tcp_timestamps: 1
/proc/sys/net/ipv4/tcp_tso_win_divisor: 3
/proc/sys/net/ipv4/tcp_tw_recycle: 0
/proc/sys/net/ipv4/tcp_tw_reuse: 0
/proc/sys/net/ipv4/tcp_window_scaling: 1
/proc/sys/net/ipv4/tcp_wmem: 4096   16384   4112512    4096   16384   4194304
/proc/sys/net/ipv4/tcp_workaround_signed_windows: 0


- net.ipv4.tcp_mem = TCP stack memory vector : la valeur basse passe de 377,9 Ko à 96,4 Ko

- net.ipv4.tcp_mem = TCP stack memory vector : la valeur "charge" passe de 503,8 Ko à 128,5 Ko

- net.ipv4.tcp_mem = TCP stack memory vector : la valeur max passe de 755,7 Ko à 192,8 Ko

- net.ipv4.tcp_rmem = Receive window memory vector : la valeur max passe de 4,19 Mo à 4,11 Mo

- net.ipv4.tcp_wmem = Send window memory vector : la valeur max passe de 4,19 Mo à 4,11 Mo

Les rares paramétres qui évoluant le font dans le mauvais sens, il me semble, ces changements ne semblent donc pas pouvoir expliquer le comportement du graphe ci-dessus.





Descriptif pour ceux qui ne comprennent rien :

tcp_mem (depuis Linux 2.4)

Il s'agit d'un vecteur de trois entiers : [bas, charge, haut]. Ces limites, mesurées dans une unité qui correspond à la taille des pages système, sont utilisées par TCP pour surveiller sa consommation mémoire. Les valeurs par défaut sont calculées au moment du démarrage à partir de la mémoire disponible. (TCP ne peut utiliser que la mémoire basse pour cela, qui est limitée aux environs de 900 Mo sur les systèmes 32 bits. Les systèmes 64 bits ne souffrent pas de cette limitation.)

low : TCP ne cherche pas à réguler ses allocations mémoire quand le nombre de pages qu'il a alloué est en-dessous de ce nombre

pressure : Lorsque la taille mémoire allouée par TCP dépasse ce nombre de pages, TCP modère sa consommation mémoire. L'état de mémoire chargée se termine lorsque le nombre de pages allouées descend en dessous de la marque bas.

high : Le nombre global maximal de pages que TCP allouera. Cette valeur surcharge tout autre limite imposée par le noyau.



tcp_rmem (depuis Linux 2.4)

Il s'agit d'un vecteur de trois entiers : [min, défaut, max]. Ces paramètres sont utilisés par TCP pour régler la taille du tampon de réception. TCP ajuste dynamiquement la taille à partir de la valeur par défaut, dans l'intervalle de ces valeurs, en fonction de la mémoire disponible sur le système.

min : taille minimale du tampon de réception utilisée par chaque socket TCP. La valeur par défaut est la taille des pages du système (sous Linux 2.4, la valeur par défaut est de 4 Ko et descend à PAGE_SIZE octets sur les systèmes avec peu de mémoire). Cette valeur assure qu'en mode de mémoire chargée, les allocations en-dessous de cette taille réussiront. Elle n'est pas utilisée pour limiter la taille du tampon de réception, déclarée en utilisant l'option SO_RCVBUF sur la socket.

default : la taille par défaut du tampon de réception pour une socket TCP. Cette valeur écrase la taille par défaut dans la valeur globale net.core.rmem_default définie pour tous les protocoles. La valeur par défaut est 87380 octets (sous Linux 2.4, elle descend à 43689 sur les systèmes avec peu de mémoire). Si une taille plus grande est désirée, il faut augmenter cette valeur (pour affecter toutes les sockets). Pour utiliser une grande fenêtre TCP, l'option net.ipv4.tcp_window_scaling doit être activée (par défaut).

max : la taille maximale du tampon de réception utilisé par chaque socket TCP. Cette valeur ne surcharge pas la valeur globale net.core.rmem_max. Elle ne permet pas de limiter la taille du tampon de réception déclarée avec l'option SO_RCVBUF sur la socket. La valeur par défaut est calculé par la formule : max(87380, min(4MB, tcp_mem[1]*PAGE_SIZE/128))
(Sous Linux 2.4, la valeur par défaut est de 87380*2 octets, et descendre à 87380 sur les systèmes avec peu de mémoire)



tcp_wmem (depuis Linux 2.4)

Il s'agit d'un vecteur de trois entiers : [min, défaut, max]. Ces paramètres servent à TCP pour réguler la taille du tampon d'émission. La taille est ajustée dynamiquement à partir de la valeur par défaut, dans l'intervalle de ces valeurs, en fonction de la mémoire disponible.

min : La taille minimale du tampon d'émission utilisé par chaque socket TCP. La valeur par défaut est la taille des pages du systeème (sous Linux 2.4, la valeur par défaut est de 4 Ko). Cette valeur assure qu'en mode de mémoire chargée, les allocations en-dessous de cette taille réussiront. Elle n'est pas utilisée pour limiter la taille du tampon de réception, déclarée en utilisant l'option SO_SNDBUF sur la socket.

default : La taille par défaut du tampon d'émission pour une socket TCP. Cette valeur surcharge la taille par défaut de valeur globale /proc/sys/net/core/wmem_default définie pour tous les protocoles. La valeur par défaut est 16 Ko. Si une taille plus grande est désirée, il faut augmenter cette valeur (pour affecter toutes les sockets). Pour utiliser une grande fenêtre TCP, /proc/sys/net/ipv4/tcp_window_scaling doit être positionné à une valeur non nulle (par défaut).

max : max - la taille maximale du tampon d'émission utilisé par chaque socket TCP. Cette valeur ne surcharge pas la valeur globale qui se trouve dans /proc/sys/net/core/wmem_max. Elle ne permet pas de limiter la taille du tampon de réception déclarée avec l'option SO_SNDBUF sur la socket. La valeur par défaut est calculée avec la formule : max(65536, min(4MB, tcp_mem[1]*PAGE_SIZE/128))
(Sous Linux 2.4, la valeur par défaut est de 128 Ko et descendre à 64 Ko sur les systèmes avec peu de mémoire)

vivien

  • Administrateur
  • *
  • Messages: 47 178
    • Twitter LaFibre.info
Comparatif des performance coté serveur - Ubuntu Server 11.04 vs 11.10
« Réponse #5 le: 25 octobre 2011 à 11:22:25 »
En noir, les paramètres complets pour Ubuntu Server 11.10 64bits (Linux 3.0.0) et de 4 Go de ram.
En bleu, les paramètres qui différent pour Ubuntu Server 11.10 64bits (Linux 3.0.0) et de 2 Go de ram.
En rouge, les paramètres qui différent pour Ubuntu Server 11.10 32bits (Linux 3.0.0) et de 1 Go de ram.
En rose, les paramètres qui différent pour Ubuntu Server 11.04 64bits (Linux 2.6.38) et de 1 Go de ram.

Cela montre que la quantité de ram et la version 32 bit / 64 bit influe sur de nombreux paramètres :

/proc/sys/net/core/optmem_max: 20480     10240
/proc/sys/net/core/rmem_default: 126976     114688
/proc/sys/net/core/rmem_max: 131071
/proc/sys/net/core/wmem_default: 126976     114688
/proc/sys/net/core/wmem_max: 131071
/proc/sys/net/ipv4/tcp_abc: 0
/proc/sys/net/ipv4/tcp_abort_on_overflow: 0
/proc/sys/net/ipv4/tcp_adv_win_scale: 2
/proc/sys/net/ipv4/tcp_allowed_congestion_control: cubic reno
/proc/sys/net/ipv4/tcp_app_win: 31
/proc/sys/net/ipv4/tcp_available_congestion_control: cubic reno
/proc/sys/net/ipv4/tcp_base_mss: 512
/proc/sys/net/ipv4/tcp_congestion_control: cubic
/proc/sys/net/ipv4/tcp_cookie_size: 0
/proc/sys/net/ipv4/tcp_dma_copybreak: 4096
/proc/sys/net/ipv4/tcp_dsack: 1
/proc/sys/net/ipv4/tcp_ecn: 2
/proc/sys/net/ipv4/tcp_fack: 1
/proc/sys/net/ipv4/tcp_fin_timeout: 60
/proc/sys/net/ipv4/tcp_frto: 2
/proc/sys/net/ipv4/tcp_frto_response: 0
/proc/sys/net/ipv4/tcp_keepalive_intvl: 75
/proc/sys/net/ipv4/tcp_keepalive_probes: 9
/proc/sys/net/ipv4/tcp_keepalive_time: 7200
/proc/sys/net/ipv4/tcp_low_latency: 0
/proc/sys/net/ipv4/tcp_max_orphans: 262144     131072     65536

tcp_max_orphans (entier ; valeur par défaut : voir ci-dessous ; depuis Linux 2.4)
Le nombre maximal de sockets TCP orphelines (attachées à aucun descripteur utilisateur) sur le système. Quand ce nombre est dépassé, la connexion orpheline est réinitialisée et un message d'avertissement est affiché. Cette limite n'existe que pour éviter les attaques par déni de service ; la diminuer n'est pas recommandé. Certaines situations peuvent réclamer d'augmenter cette limite, mais notez que chaque connexion orpheline peut consommer jusqu'à 64 ko de mémoire non-swappable. La valeur par défaut est égale au paramètre NR_FILE du noyau. Elle est ajustée en fonction de la mémoire disponible sur le système.

/proc/sys/net/ipv4/tcp_max_ssthresh: 0
/proc/sys/net/ipv4/tcp_max_syn_backlog: 2048     1024     512

tcp_max_syn_backlog (entier ; valeur par défaut : voir ci-dessous ; depuis Linux 2.2)
Le nombre maximal de requêtes de connexions en attente, qui n'ont pas encore reçu d'acquittement de la part du client se connectant. Si ce nombre est atteint, le noyau commencera à abandonner des requêtes. La valeur par défaut, 256, est augmentée jusqu'à 1024 si la mémoire présente est suffisante (>= 128 Mo) et peut être diminuée à 128 sur les systèmes avec très peu de mémoire (<= 32 Mo). Il est recommandé, s'il faut augmenter cette valeur au dessus de 1024, de modifier TCP_SYNQ_HSIZE dans include/net/tcp.h pour conserver TCP_SYNQ_HSIZE * 16 <= tcp_max_syn_backlog et de recompiler le noyau.

/proc/sys/net/ipv4/tcp_max_tw_buckets: 262144     131072     65536     65536

tcp_max_tw_buckets (entier ; valeur par défaut : voir ci-dessous ; depuis Linux 2.4)
Le nombre maximal de sockets dans l'état TIME_WAIT autorisées sur le système. Cette limite n'existe que pour éviter les attaques par déni de service. La valeur par défaut est NR_FILE*2, ajustée en fonction de la mémoire disponible. Si ce nombre est atteint, la socket est fermée et un avertissement est affiché.

/proc/sys/net/ipv4/tcp_mem: 96387   128516   192774   48240   64320   96480     21132   28179   42264     94272   125696   188544
/proc/sys/net/ipv4/tcp_moderate_rcvbuf: 1
/proc/sys/net/ipv4/tcp_mtu_probing: 0
/proc/sys/net/ipv4/tcp_no_metrics_save: 0
/proc/sys/net/ipv4/tcp_orphan_retries: 0
/proc/sys/net/ipv4/tcp_reordering: 3
/proc/sys/net/ipv4/tcp_retrans_collapse: 1
/proc/sys/net/ipv4/tcp_retries1: 3
/proc/sys/net/ipv4/tcp_retries2: 15
/proc/sys/net/ipv4/tcp_rfc1337: 0
/proc/sys/net/ipv4/tcp_rmem: 4096   87380   4112512     4096   87380   2058240    4096   87380   901728     4096   87380   4022272
/proc/sys/net/ipv4/tcp_sack: 1
/proc/sys/net/ipv4/tcp_slow_start_after_idle: 1
/proc/sys/net/ipv4/tcp_stdurg: 0
/proc/sys/net/ipv4/tcp_syn_retries: 5
/proc/sys/net/ipv4/tcp_synack_retries: 5
/proc/sys/net/ipv4/tcp_syncookies: 1
/proc/sys/net/ipv4/tcp_thin_dupack: 0
/proc/sys/net/ipv4/tcp_thin_linear_timeouts: 0
/proc/sys/net/ipv4/tcp_timestamps: 1
/proc/sys/net/ipv4/tcp_tso_win_divisor: 3
/proc/sys/net/ipv4/tcp_tw_recycle: 0
/proc/sys/net/ipv4/tcp_tw_reuse: 0
/proc/sys/net/ipv4/tcp_window_scaling: 1
/proc/sys/net/ipv4/tcp_wmem: 4096   16384   4112512     4096   16384   2058240    4096   16384   901728     4096   16384   4022272
/proc/sys/net/ipv4/tcp_workaround_signed_windows: 0

C'est donc bien autre chose qui doit expliquer les modifications de performance

Edit Vivien : la réponse aux questions posées sur l’augmentation des performances avec un noyeau linux récent est décris dans le post Patch Google ou "TCP Initial Congestion Window" à 10