Mesafe Üzerinden Yavaş Transferler

NY Veri Merkezimizden, daha uzaktaki yerlere yapılan transferler düşük performans gösteriyor.

Çeşitli yerleri test etmek için hız testini kullanarak, 100 mbit uplink'imizi Boston ve Philadelphia'ya kolayca doyurabiliriz. ABD veya Avrupa'nın batı kıyısındaki hız testini kullandığımda, genellikle sadece yaklaşık 9 mbit / s görüyorum.

İlk tepkim bunun bir pencere ölçeklendirme problemi (Bant Genişliği Gecikme Ürünü) olduğudur. Bununla birlikte, batı kıyısındaki bir test makinesinde Linux çekirdek parametreleriyle ayarladım ve iperf'i, pencerenin saniyede 100 MegaBit'i destekleyecek kadar büyük olduğu ve hala düşük hızlara sahip olduğu noktaya kadar kullandım (Doğrulanmış Yakalama). Ayrıca Nagle algoritmasını devre dışı bırakmayı denedim.

Hem Linux hem de Windows'tan düşük performans alıyoruz, ancak Windows'u kullanma hızı önemli ölçüde daha kötü (1/3).

Transfer şekli (Nagle olmadan):

10'ların etrafındaki Dip ~ 100 çift ack'e sahiptir.

Zaman içinde alıcının Min Penceresi boyutunun şekli:

Şişe boynumuzu batırmak için nereye gideceğine dair bir fikir var mı?

Bazı Hız testi sonuçları (speedtest.net kullanarak yükleyin):

• Philadelphia: 44 mbit (Sitemizi kullananlar geri kalanını kullanıyor ;-))
• Miami: 15 mbit
• Dallas: 14 mbit
• San Jose: 9 mbit
• Berlin: 5 mbit
• Sidney: 2,9 mbit

Daha Fazla Veri:
Miami: 69.241.6.18

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.579 ms  0.588 ms  0.594 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.562 ms  0.569 ms  0.565 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.634 ms  0.640 ms  0.637 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126)  4.120 ms  4.126 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.673 ms
 6  ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  1.236 ms ae-91-91.ebr1.newyork1.level3.net (4.69.134.77)  0.956 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  0.600 ms
 7  ae-10-10.ebr2.washington12.level3.net (4.69.148.50)  6.059 ms  6.029 ms  6.661 ms
 8  ae-1-100.ebr1.washington12.level3.net (4.69.143.213)  6.084 ms  6.056 ms  6.065 ms
 9  ae-6-6.ebr1.atlanta2.level3.net (4.69.148.105)  17.810 ms  17.818 ms  17.972 ms
10  ae-1-100.ebr2.atlanta2.level3.net (4.69.132.34)  18.014 ms  18.022 ms  18.661 ms
11  ae-2-2.ebr2.miami1.level3.net (4.69.140.141)  40.351 ms  40.346 ms  40.321 ms
12  ae-2-52.edge2.miami1.level3.net (4.69.138.102)  31.922 ms  31.632 ms  31.628 ms
13  comcast-ip.edge2.miami1.level3.net (63.209.150.98)  32.305 ms  32.293 ms comcast-ip.edge2.miami1.level3.net (64.156.8.10)  32.580 ms
14  pos-0-13-0-0-ar03.northdade.fl.pompano.comcast.net (68.86.90.230)  32.172 ms  32.279 ms  32.276 ms
15  te-8-4-ur01.northdade.fl.pompano.comcast.net (68.85.127.130)  32.244 ms  32.539 ms  32.148 ms
16  te-8-1-ur02.northdade.fl.pompano.comcast.net (68.86.165.42)  32.478 ms  32.456 ms  32.459 ms
17  te-9-3-ur05.northdade.fl.pompano.comcast.net (68.86.165.46)  32.409 ms  32.390 ms  32.544 ms
18  te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198)  33.938 ms  33.775 ms  34.430 ms
19  te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198)  32.896 ms !X * *

69.241.6.0/23 *[BGP/170] 1d 00:55:07, MED 3241, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 20214 I
> to 216.187.115.166 via xe-0/0/0.0

San Jose: 208.79.45.81

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.477 ms  0.549 ms  0.547 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.543 ms  0.586 ms  0.636 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.518 ms  0.569 ms  0.566 ms
 5  vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.620 ms vlan99.csw4.newyork1.level3.net (4.68.16.254)  9.275 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.759 ms
 6  ae-62-62.ebr2.newyork1.level3.net (4.69.148.33)  1.848 ms  1.189 ms ae-82-82.ebr2.newyork1.level3.net (4.69.148.41)  1.011 ms
 7  ae-2-2.ebr4.sanjose1.level3.net (4.69.135.185)  69.942 ms  68.918 ms  69.451 ms
 8  ae-81-81.csw3.sanjose1.level3.net (4.69.153.10)  69.281 ms ae-91-91.csw4.sanjose1.level3.net (4.69.153.14)  69.147 ms ae-81-81.csw3.sanjose1.level3.net (4.69.153.10)  69.495 ms
 9  ae-23-70.car3.sanjose1.level3.net (4.69.152.69)  69.863 ms ae-13-60.car3.sanjose1.level3.net (4.69.152.5)  69.860 ms ae-43-90.car3.sanjose1.level3.net (4.69.152.197)  69.661 ms
10  smugmug-inc.car3.sanjose1.level3.net (4.71.112.10)  73.298 ms  73.290 ms  73.274 ms
11  speedtest.smugmug.net (208.79.45.81)  70.055 ms  70.038 ms  70.205 ms

208.79.44.0/22 *[BGP/170] 4w0d 08:03:46, MED 0, localpref 59, from 216.187.115.12
AS path: 3356 11266 I
> to 216.187.115.166 via xe-0/0/0.0

Philly: 68.87.64.49

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.578 ms  0.576 ms  0.570 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.615 ms  0.613 ms  0.602 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.584 ms  0.580 ms  0.574 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126)  0.817 ms vlan69.csw1.newyork1.level3.net (4.68.16.62)  9.518 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  9.712 ms
 6  ae-91-91.ebr1.newyork1.level3.net (4.69.134.77)  0.939 ms ae-61-61.ebr1.newyork1.level3.net (4.69.134.65)  1.064 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  1.075 ms
 7  ae-6-6.ebr2.newyork2.level3.net (4.69.141.22)  0.941 ms  1.298 ms  0.907 ms
 8  * * *
 9  comcast-ip.edge1.newyork2.level3.net (4.71.186.14)  3.187 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.34)  2.036 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.2)  2.682 ms
10  te-4-3-ar01.philadelphia.pa.bo.comcast.net (68.86.91.162)  3.507 ms  3.716 ms  3.716 ms
11  te-9-4-ar01.ndceast.pa.bo.comcast.net (68.86.228.2)  7.700 ms  7.884 ms  7.727 ms
12  te-4-1-ur03.ndceast.pa.bo.comcast.net (68.86.134.29)  8.378 ms  8.185 ms  9.040 ms

68.80.0.0/13 *[BGP/170] 4w0d 08:48:29, MED 200, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 I
> to 216.187.115.166 via xe-0/0/0.0

Berlin: 194.29.226.25

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.483 ms  0.480 ms  0.537 ms
 3  oc48-po2-0.nyc-telx-dis-2.peer1.net (216.187.115.133)  0.532 ms  0.535 ms  0.530 ms
 4  oc48-so2-0-0.ldn-teleh-dis-1.peer1.net (216.187.115.226)  68.550 ms  68.614 ms  68.610 ms
 5  linx1.lon-2.uk.lambdanet.net (195.66.224.99)  81.481 ms  81.463 ms  81.737 ms
 6  dus-1-pos700.de.lambdanet.net (82.197.136.17)  80.767 ms  81.179 ms  80.671 ms
 7  han-1-eth020.de.lambdanet.net (217.71.96.77)  97.164 ms  97.288 ms  97.270 ms
 8  ber-1-eth020.de.lambdanet.net (217.71.96.153)  89.488 ms  89.462 ms  89.477 ms
 9  ipb-ber.de.lambdanet.net (217.71.97.82)  104.328 ms  104.178 ms  104.176 ms
10  vl506.cs22.b1.ipberlin.com (91.102.8.4)  90.556 ms  90.564 ms  90.553 ms
11  cic.ipb.de (194.29.226.25)  90.098 ms  90.233 ms  90.106 ms

194.29.224.0/19 *[BGP/170] 3d 23:14:47, MED 0, localpref 69, from 216.187.115.15
AS path: 13237 20647 I
> to 216.187.115.182 via xe-0/1/0.999

Güncelleme:

Tall Jeff ile biraz daha derinlere inerek garip bir şey bulduk. Gönderenin yanındaki TCPDump'a göre , paketleri Internet üzerinden 65k paket olarak gönderir . Alıcı tarafındaki çöplüklere baktığımızda, beklediğiniz gibi parçalanmış 1448'e ulaşıyorlar.

Gönderen tarafında paket dökümü aşağıdaki gibidir:

O zaman, gönderenin sadece 64k paket gönderdiğini düşünüyor, ancak gerçekte alıcı söz konusu olduğunda paket patlamaları gönderiyor. Sonuçta tıkanıklık kontrolü bozulur. Bunun, gönderen tarafından gönderilen veri paketlerinin paket uzunluklarının bir grafiği olduğunu görebilirsiniz:

Gönderenin 64k MTU olduğunu düşünmesine neyin sebep olabileceğini bilen var mı? Belki bazıları /proc, ethtoolya da ifconfig parameter? ( ifconfigMTU'nun 1500 olduğunu gösterir). Şu anda en iyi tahminim bir çeşit donanım hızlandırma - ama özellikle ne olduğundan emin değilim.

Subedit 2-2 IV:
Sadece bir düşünce vardı, çünkü bu 64k paketler DF biti ayarlı, belki de sağlayıcım onları zaten parçalıyor ve MSS otomatik keşfini bozuyor! Ya da güvenlik duvarımız yanlış yapılandırılmış ...

Yardımcı Düzenleme 9.73.4 20-60:
64k paketleri görmemizin nedeni segment boşaltma (tso ve gso, bkz. Ethtool -K) açık olmasıdır. Bunları kapattıktan sonra, aktarım hızında herhangi bir gelişme görmüyorum. Şekil biraz değişir ve yeniden iletimler daha küçük segmentlerde bulunur:

Ayrıca, Linux üzerinde tüm farklı tıkanıklık algoritmalarını hiçbir gelişme olmadan denedim. NY sağlayıcımız, bulunduğumuz tesisten VEYA'daki bir test ftp sunucusuna dosya yüklemeyi denedi ve 3 kat hız alıyor.

NY'dan OR'ye istenen MTR raporu:

root@ny-rt01:~# mtr haproxy2.stackoverflow.com -i.05 -s 1400 -c 500 -r
HOST: ny-rt01.ny.stackoverflow.co Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. stackoverflow-nyc-gw.peer1.n  0.0%   500    0.6   0.6   0.5  18.1   0.9
  2. gig4-0.nyc-gsr-d.peer1.net    0.0%   500    0.6   0.6   0.5  14.8   0.8
  3. 10ge.xe-0-0-0.nyc-telx-dis-1  0.0%   500    0.7   3.5   0.5  99.7  11.3
  4. nyiix.he.net                  0.0%   500    8.5   3.5   0.7  20.8   3.9
  5. 10gigabitethernet1-1.core1.n  0.0%   500    2.3   3.5   0.8  23.5   3.8
  6. 10gigabitethernet8-3.core1.c  0.0%   500   20.1  22.4  20.1  37.5   3.6
  7. 10gigabitethernet3-2.core1.d  0.2%   500   72.2  72.5  72.1  84.4   1.5
  8. 10gigabitethernet3-4.core1.s  0.2%   500   72.2  72.6  72.1  92.3   1.9
  9. 10gigabitethernet1-2.core1.p  0.4%   500   76.2  78.5  76.0 100.2   3.6
 10. peak-internet-llc.gigabiteth  0.4%   500   76.3  77.1  76.1 118.0   3.6
 11. ge-0-0-2-cvo-br1.peak.org     0.4%   500   79.5  80.4  79.0 122.9   3.6
 12. ge-1-0-0-cvo-core2.peak.org   0.4%   500   83.2  82.7  79.8 104.1   3.2
 13. vlan5-cvo-colo2.peak.org      0.4%   500   82.3  81.7  79.8 106.2   2.9
 14. peak-colo-196-222.peak.org    0.4%   499   80.1  81.0  79.7 117.6   3.3

TCP penceresinin Bant Genişliği Gecikme Ürününü kapsayacak kadar geniş açıldığından emin olmak da benim ilk tahminim olurdu. Düzgün yapılandırıldığını (ve her iki uç tarafından desteklendiğini) varsayarsak, pencerenin gerçekten açıldığından ve yoldaki atlamalardan birinin pencere ölçeklendirmesini soymadığından emin olmak için bir paket izlemesi inceleyeceğim. Her şey yolundaysa ve yoldaki bant genişliği kısıtlı bir sıçramaya çarpmadığınızdan eminseniz, sorunlarınızın olası nedeni rastgele paket düşüşleridir. Bu hipotez, bahsettiğiniz kopya ACK'ların belirtilmesi ile desteklenir. (Çoğaltılan ACK'ler genellikle kayıp verilerin doğrudan bir sonucudur). Ayrıca, geniş bir bant genişliği geciktirme ürünü ve dolayısıyla geniş bir açık kayar pencere ile,

Yan Not: TCP ve çok sekmeli WAN bağlantısı üzerinden toplu veri aktarımı için, Nagle'ı devre dışı bırakmaya gerek yoktur. Aslında, bu tam senaryo Nagle'ın var olmasının sebebidir. Genel olarak, Nagle'ın yalnızca MTU boyutundaki alt datagramların gecikmeksizin zorlanması gereken etkileşimli bağlantılar için devre dışı bırakılması gerekir. ie: Toplu aktarımlar için, her pakette mümkün olduğunca fazla veri istersiniz.

Paketinizi yeniden sıralayarak ayarladınız mı? Linux'ta / proc'da tcp_reordering üzerinde kontrol edin. Uzun borularda, yanlış paket kaybı sapmasına, yeniden iletimine ve grafiğinizde gönderdiğiniz hız düşüşlerine neden olmak çok yollu bir efekttir. Çok sayıda yinelenen Eylem'e neden olur, bu yüzden kontrol edilmeye değer. Borunun her iki tarafını da iyi sonuçlar verecek ve en az kübik kullanacak şekilde ayarlamanız gerektiğini unutmayın. Ftp gibi interaktif bir protokol, yapabileceğiniz uzun boru optimizasyonu için herhangi bir tcp'ye zarar verebilir. Yalnızca büyük dosyaları aktarmıyorsanız.

Çeşitli sitelerinize bildirdiğiniz gecikmeye bağlı olarak, gördüğünüz şey normal görünüyor. Gecikme, kullanılabilir bant genişliğinden bağımsız olarak hemen her bağlantıyı çok hızlı bir şekilde öldürecektir.

Silver Peak, belirli bir bant genişliği ile burada belirtilen bir gecikme düzeyini görmeyi beklediğiniz verim için hızlı ve kirli bir tahminci sunar: http://www.silver-peak.com/calculator/

Gördüğünüz uygun gecikmelerle 100mbit'lik bir bağlantı takın ve hızlarınızın gerçekten görmeyi beklediğiniz şeyle (Yaklaşık) eşleştiğini göreceksiniz.

Linux'tan daha düşük performans sağlayan Windows'a gelince, maalesef orada iyi öneriler sunamıyorum. Aynı donanımla (özellikle NIC'ler) bir elma-elma karşılaştırması yaptığınızı varsayıyorum?