Auteur Sujet: problème de performance réseau debian jessie  (Lu 15104 fois)

0 Membres et 1 Invité sur ce sujet

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
problème de performance réseau debian jessie
« Réponse #36 le: 26 février 2016 à 14:26:41 »
on n'a toujours pas:
ps: et la latence vers 1.testdebit.info (mtr 1.testdebit.info par exemple ou juste un ping)

les 2 PC ont-ils bien exactement le meme OS (uname -a & lsb_release -a) ?

Causes possible de baisse de debit :
- un mauvais ajustement de TCP a la latence sur le PC malade (les buffers sont ok mais y'a d'autre paramètres)
- saturation CPU du PC a cause d'un filtre en entrée (iptable ou autre firewall) qui s'active sauf si le traffic est local
- mauvais ajustement de TCP sur le PC a cause des pertes de paquets (rare).

Le test suivant c'est avec UDP mais pas evident à  faire depuis Internet

iperf3 -u -b 1G  -c ping.online.net
A faire en local aussi: le serveur en mode serveur (iperf3 -s) et le test UDP depuis les 2 PC.

Si ca donne rien, on peut tester avec de la latence localement:

Sur le serveur:

sudo tc qdisc add dev ethX root netem delay 100ms(ethX = carte lan du serveur, au lieu de 100ms mettre la latence vers 1.testdebit.info).

puis comparer les 2 PC avec un iperf3 -R ou un wget

pour remettre le serveur en normal:

sudo tc qdisc del dev ethX root netem delay 100ms
('sudo tc qdisc ' tout court permet de voir si on a quelque chose d'actif).

Si ce n'est pas la latence c'est peut être des pertes de paquets quelque parts. c'est plus rare mais ca arrive.

Pour tester avec des pertes:

sudo tc qdisc change dev ethX root netem loss 0.1%
et refaire les iperfs.

Tester aussi en coupant iptables sur le PC malade.

jeremyp3

  • Abonné Orange Fibre
  • *
  • Messages: 715
  • Pau (64)
problème de performance réseau debian jessie
« Réponse #37 le: 27 février 2016 à 05:00:16 »
bonjour,

je pensais que le traceroute suffisait

donc un ping donne:
--- 1.testdebit.info ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 6999ms
rtt min/avg/max/mdev = 20.477/20.528/20.595/0.129 ms

les deux machines ont strictement le même OS, provient du même tar.gz.

une debian 8.3 avec le noyau 4.3 des backports.

le iperf en udp:

root@portable-Jessie:/home/jeremy#
root@portable-Jessie:/home/jeremy# iperf3 -u -b 1G  -c ping.online.net
Connecting to host ping.online.net, port 5201
[  4] local 192.168.80.10 port 54130 connected to 62.210.18.40 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec   102 MBytes   856 Mbits/sec  13058 
[  4]   1.00-2.00   sec   112 MBytes   942 Mbits/sec  14376 
[  4]   2.00-3.00   sec   114 MBytes   955 Mbits/sec  14573 
[  4]   3.00-4.00   sec   114 MBytes   955 Mbits/sec  14567 
[  4]   4.00-5.00   sec   113 MBytes   951 Mbits/sec  14507 
[  4]   5.00-6.00   sec   114 MBytes   956 Mbits/sec  14585 
[  4]   6.00-7.00   sec   113 MBytes   951 Mbits/sec  14507 
[  4]   7.00-8.00   sec   114 MBytes   956 Mbits/sec  14593 
[  4]   8.00-9.00   sec   113 MBytes   946 Mbits/sec  14428 
[  4]   9.00-10.00  sec   113 MBytes   951 Mbits/sec  14512 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec  0.344 ms  139243/139634 (1e+02%) 
[  4] Sent 139634 datagrams

iperf Done.

en udp de serveur a pc malade j'ai bien 940 mbps dans les deux sens.


après avoir mis de la latence, le wget est tout de suite moins sexy:

donc j'ai mis 20 ms comme le ping si-dessus,

et le wget donne ça sur les deux pc vers le serveur:
--2016-02-27 04:47:05--  http://192.168.80.1/5000Mo.dat
Connexion à 192.168.80.1:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 5000000000 (4,7G) [application/octet-stream]
Sauvegarde en : « /dev/null »

/dev/null           100%[=====================>]   4,66G  46,7MB/s   ds 1m 43s

2016-02-27 04:48:49 (46,2 MB/s) — « /dev/null » sauvegardé [5000000000/5000000000]

quand la latence est local, les deux pc sont touché.

si malgré ses informations les autres test sont encore utile, merci de me le dire.

jerem

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
problème de performance réseau debian jessie
« Réponse #38 le: 27 février 2016 à 13:37:56 »
Le test UDP n'est pas dans le bon je me suis trompé. il faut ajouter -R.

iperf3 -R -u -b 1G  -c ping.online.net
Il faut que ping.online.net envoie un flux UDP a 1Gbps (et pas envoyé un flux vers online).
Le résultat peut être faussé par les anti-DDoS d'Online ou d'ailleurs dans le chemin.

quand la latence est local, les deux pc sont touché.

ca peut être le serveur qui a du mal a èmettre avec de la latence. Le point concluant c'est que les 2 PC donnent pareil.

on s'oriente sur un souci iptables/firewall en TCP. faut tester en coupant iptables. et bien vérifier le cpu du PC malade avec 'top' (j’espère que c'est le cas avec chaque test sinon on perd notre temps pour rien la...).



jeremyp3

  • Abonné Orange Fibre
  • *
  • Messages: 715
  • Pau (64)
problème de performance réseau debian jessie
« Réponse #39 le: 27 février 2016 à 13:42:08 »
on s'oriente sur un souci iptables/firewall en TCP. faut tester en coupant iptables.

si seulement c'était si simple ...

pas d'iptables ni de pare feu de configuré sur le pc "malade" seulement des masquerading pour virtualbox. ça peut jouer, tu penses ?

jerem

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
problème de performance réseau debian jessie
« Réponse #40 le: 27 février 2016 à 13:48:02 »
j'avais pas fini ma phrase :p

jeremyp3

  • Abonné Orange Fibre
  • *
  • Messages: 715
  • Pau (64)
problème de performance réseau debian jessie
« Réponse #41 le: 27 février 2016 à 14:07:13 »
Le test UDP n'est pas dans le bon je me suis trompé. il faut ajouter -R.
voilà le résultat:
root@portable-Jessie:/home/jeremy# iperf3 -R -u -b 1G  -c ping.online.net
Connecting to host ping.online.net, port 5201
Reverse mode, remote host ping.online.net is sending
[  4] local 192.168.80.10 port 41607 connected to 62.210.18.40 port 5201
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-1.00   sec  7.23 MBytes  60.7 Mbits/sec  0.208 ms  14368/15294 (94%) 
[  4]   1.00-2.00   sec  6.89 MBytes  57.8 Mbits/sec  0.237 ms  14634/15516 (94%) 
[  4]   2.00-3.00   sec  6.85 MBytes  57.5 Mbits/sec  0.286 ms  14202/15079 (94%) 
[  4]   3.00-4.00   sec  6.80 MBytes  57.0 Mbits/sec  0.140 ms  14637/15507 (94%) 
[  4]   4.00-5.00   sec  6.61 MBytes  55.4 Mbits/sec  0.139 ms  14030/14876 (94%) 
[  4]   5.00-6.00   sec  7.33 MBytes  61.5 Mbits/sec  0.175 ms  14503/15441 (94%) 
[  4]   6.00-7.00   sec  7.03 MBytes  59.0 Mbits/sec  0.182 ms  13729/14629 (94%) 
[  4]   7.00-8.00   sec  6.84 MBytes  57.3 Mbits/sec  0.213 ms  15213/16088 (95%) 
[  4]   8.00-9.00   sec  6.71 MBytes  56.3 Mbits/sec  0.173 ms  14215/15074 (94%) 
[  4]   9.00-10.00  sec  6.59 MBytes  55.3 Mbits/sec  0.169 ms  14632/15476 (95%) 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.17 GBytes  1.00 Gbits/sec  0.169 ms  144163/152980 (94%) 
[  4] Sent 152980 datagrams

iperf Done.
bien vérifier le cpu du PC malade avec 'top' (j’espère que c'est le cas avec chaque test sinon on perd notre temps pour rien la...).
non, je vérifie pas le CPU avec chaque test, comme j'ai dit plus haut, top n'est pas du tout pratique a utiliser pour moi. mais vu que ça marche en local, le soucis n'est pas la, si ?

mais voici un top (par défault) en pj durant un wget sur le pc malade


kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
problème de performance réseau debian jessie
« Réponse #42 le: 27 février 2016 à 14:48:17 »
comme je m'y attendait le test UDP se sert a rien y'a un bridage a 50Mbs quelque part entre Online et Orange.

franchement la je ne vois pas.

dump tout les paramétrages tcp:
sysctl net.ipv4 | grep tcpet compare les avec l'autre PC.

jeremyp3

  • Abonné Orange Fibre
  • *
  • Messages: 715
  • Pau (64)
problème de performance réseau debian jessie
« Réponse #43 le: 27 février 2016 à 15:20:49 »
bonjour,

voici les valeur qui diffèrent

première ligne vieux pc seconde lignes pc malade

net.ipv4.tcp_max_orphans = 16384
net.ipv4.tcp_max_orphans = 32768

net.ipv4.tcp_max_syn_backlog = 128
net.ipv4.tcp_max_syn_backlog = 256

net.ipv4.tcp_max_tw_buckets = 16384
net.ipv4.tcp_max_tw_buckets = 32768

net.ipv4.tcp_mem = 46068   61424   92136
net.ipv4.tcp_mem = 93360   124482   186720

si c'est pas important, je vais arrêter de chercher et je testerai avec un live

jerem

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
problème de performance réseau debian jessie
« Réponse #44 le: 28 février 2016 à 16:02:40 »
iperf3 en UDP introduit une sorte de protocole TCP au-dessus. Les perf s'écroulent avec la latence qui augmente.

Je conseille iperf2 pour un test performant en UDP. Iperf2 va envoyer des paquets sans se soucier si cela provoque un DDOS.

Personnellement, j'utilise iperf3 en TCP et iperf2 en UDP.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
problème de performance réseau debian jessie
« Réponse #45 le: 28 février 2016 à 23:32:06 »
Quel est le CPU du PC malade ?
Il y a 78% d'idle (en moyenne sur l’ensemble des cœurs), donc le PC n'est pas surchargé, cependant :
 - wget consomme 36%
 - 6 processus sd_ibmtts (5 autour de 9% chacun, 1 à 2.6%) : est-ce que qu'il essaye de lire la sortie de top/wget ?

wget affiche la vitesse et sa barre de progression sur stderr (l'écriture est donc synchrone).
Je ne sais pas comment fonctionne le système de text-to-speech, mais si ça bloque wget trop longtemps les buffers côté kernel seront pleins, et le téléchargement va se mettre brièvement en pause, avant de repartir progressivement, et ainsi de suite.
Qu'est-ce que ça donne en redirigeant la sortie vers un fichier (par exemple avec -o log.txt pour wget) ?

jeremyp3

  • Abonné Orange Fibre
  • *
  • Messages: 715
  • Pau (64)
problème de performance réseau debian jessie
« Réponse #46 le: 29 février 2016 à 09:25:14 »
Quel est le CPU du PC malade ?
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 1367.511
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 4589.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 1375.597
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 4589.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 1341.636
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 4589.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 1318.277
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs :
bogomips : 4589.80
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

- 6 processus sd_ibmtts (5 autour de 9% chacun, 1 à 2.6%) : est-ce que qu'il essaye de lire la sortie de top/wget ?
non, le processus qui lit c'est "orca". ibmtts, c'est uniquement la synthèse vocale.
wget affiche la vitesse et sa barre de progression sur stderr (l'écriture est donc synchrone).
Je ne sais pas comment fonctionne le système de text-to-speech, mais si ça bloque wget trop longtemps les buffers côté kernel seront pleins, et le téléchargement va se mettre brièvement en pause, avant de repartir progressivement, et ainsi de suite.
Qu'est-ce que ça donne en redirigeant la sortie vers un fichier (par exemple avec -o log.txt pour wget) ?
c'est à tester.

jerem

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
problème de performance réseau debian jessie
« Réponse #47 le: 29 février 2016 à 14:31:38 »
Je ne sais pas comment fonctionne le système de text-to-speech, mais si ça bloque wget trop longtemps les buffers côté kernel seront pleins, et le téléchargement va se mettre brièvement en pause, avant de repartir progressivement, et ainsi de suite.
Qu'est-ce que ça donne en redirigeant la sortie vers un fichier (par exemple avec -o log.txt pour wget) ?

pourquoi ca ralentirait un téléchargement venant du Net et pas un téléchargement local ?

Tout le probleme depuis le début de ce sujet c'est qu'en local ca transfert a fond.

donc soit y'a un "traitement différent" quelque part dans le PC si l'IP distante n'est pas locale: on peut tester ca en utilisant l'IP public du routeur/serveur (si le hairpin/loopback et le firewall du routeur/serveur sont bien configurer)

soit y'a un a paramétrage particulier de TCP pour ce PC: on n'a rien vu de particulier pour le moment.

soit le fait que le flux traverse le routeur/serveur introduit un ralentissement quand la destination finale est le PC malade (et que lui): une règle iptables particuliere sur le routeur/serveur ou un truc du genre ?

soit X ?