Çok düşük iSCSI / NFS performansı için sorun giderme stratejisi

9

Üç Windows 2008 R2 kutusuna iSCSI hedefleri ve bir OpenBSD 5.0 kutusuna NFS sunan yeni bir Synology RS3412RPx'lerimiz var.

Ssh ile RS3412'de oturum açmak ve dd ve çeşitli blok boyutları kullanarak hem küçük dosyaları hem de 6GB dosyalarını okumak / yazmak harika disk G / Ç performansı gösterir.

İSCSI / NFS istemcilerinde dd veya iometer kullanarak 20Mbps'ye kadar ulaşıyoruz (bu bir yazım hatası değil. Yirmi Mbps). Synology'deki çoklu Gbit NIC'leri daha iyi kullanmayı umuyorduk.

Anahtarı doğruladım ve NIC bağlantı noktası yapılandırması otomatik anlaşma değil, gigabit olarak ayarlandı. Fark olmadan Jumboframes ile ve onsuz denedik. MTU'nun şu anda 9000 olduğunu ping ile doğruladım. İki bellenim yükseltmesi konuşlandırıldı.

Geçiş sorunlarını devre dışı bırakmak için iSCSI hedefi ve başlatıcı arasında doğrudan bağlantı deneyeceğim, ancak diğer seçeneklerim nelerdir?

Eğer wireshark / tcpdump'ı dağıtırsam, ne ararım?

— Alex Holst
kaynak

Akış kontrolü etkin mi? Arasında ne tür bir geçiş var?

— SpacemanSpiff

@SpacemanSpiff: Akış kontrolü etkin değil. Bunun bir fark yaratmasını bekler misiniz? Bu bir ZyXEL GS2200.

— Alex Holst

Bir tür zayıf arka panel, ancak bundan daha iyi performans elde etmek için yeterli. Çapraz kablonun size performansı akıllıca getirdiğini merak ediyorum.

— SpacemanSpiff

4

Buradaki ortak tema gibi göründüğü gibi, anahtarlardaki akış kontrol ayarlarına bir kez daha bakın. Anahtar (lar) ın Ethernet sayaç istatistikleri varsa bunlara bir göz atın ve çok sayıda Ethernet DURAKLATMA çerçevesi olup olmadığına bakın. Eğer öyleyse, muhtemelen sizin probleminizdir. Genel olarak, anahtar (lar) daki QOS'un devre dışı bırakılması bu sorunu çözer.

— joeqwerty
kaynak

Bir kez daha baktım. Akış kontrolü devre dışı bırakıldı ve PAUSE sayaçları tüm arabirimlerde sıfırdı. Akış kontrolünü etkinleştirmek, DURAKLATMA sayaçlarının paket sayısının% 25'ini artırmasını sağladı. Aynı zayıf performansı göstermeyen bazı donanımları belirledik, şimdi nic sürücüleri güncellemek ve belirli nics'leri daha yetenekli olanlarla değiştirmek istiyoruz. QoS anahtarda zaten devre dışı bırakıldı. Girdiniz için teşekkürler.

— Alex Holst

Yardım

— etmekten memnunum

3

Bunun gibi akışlar bana çeşitli TCP akış denetimi yöntemlerinin düzgün çalışmadığını gösteriyor. Vista sonrası Windows sürümleriyle konuşan Linux çekirdeğinde bazı sorunlar gördüm ve bunun gibi verim elde edersiniz. Bir kez baktığınızda Wireshark'ta oldukça iyi görünüyorlar.

Mutlak en kötü olasılık, TCP gecikmeli ack'in tamamen kırılmış olması ve aşağıdaki gibi bir trafik deseni görmenizdir:

packet
packet
[ack]
packet
packet
[ack]

Bunu Windows sunucularına NIC sürücü güncellemeleri uygulayarak çözdüm. Bazı (broadcom) sunucularla birlikte gelen akıllı NIC'ler bazen ilginç şekillerde başarısız olabilir ve bu da bir tanesidir.

Normal bir trafik modeli çok sayıda paket ve ardından bir Ack paketi olur.

Aranacak diğer şey uzun gecikmelerdir. Şüpheli değerler 0,2 saniye ve 1,0 saniyedir. Bu, bir tarafın beklediği şeyi almadığını ve yanıt vermeden önce bir zaman aşımının sona ermesini beklediğini gösterir. Yukarıdaki kötü paket desenini ACK için 200 ms'lik bir gecikmeyle birleştirin ve 1MB / s'lik bir bobin verimi elde edin.

Bunlar fark edilmesi kolay kötü trafik düzenleridir.

Bu tür bir NAS cihazıyla çalışmadım, bu yüzden bulunanları düzeltmenin ne kadar ince ayarlı olduğunu bilmiyorum.

— sysadmin1138
kaynak

Ayrıca,

— SpacemanSpiff