2x25GbE LACP Yaptık Ama Neden Hala 25Gbps Geçmiyor? Linux Bonding, Hashing Algoritmaları ve vSwitch Tuzakları

Üretim ortamındaki bir veritabanı (PostgreSQL, Percona MySQL) veya KVM/Proxmox hipervizör sunucusunda zaman zaman uygulama katmanından “disk yazma zaman aşımı” veya “yavaş sorgu” alarmları gelir. Hemen sunucuya bağlanıp iostat -xz 1 çalıştırırsınız ve r_await / w_await değerlerinin 0.8 ms gibi gayet sağlıklı bir ortalamada seyrettiğini görürsünüz. Peki ortalama değerler bu kadar iyiyken uygulama neden darboğaz yaşıyor?
Cevap Ortalamaların Tiranlığıdır (Tyranny of Averages). Saniyede 10.000 IOPS yapan bir NVMe veya SAN LUN üzerinde, 9.990 isteğin 0.1 ms’de tamamlanıp sadece 10 isteğin (örneğin bir ZFS TXG flush, Ceph compaction veya SAN switch buffer credit tıkanması nedeniyle) 250 ms sürdüğünü düşünün. iostat size bu 1 saniyenin ortalamasını 0.35 ms olarak raporlar ve o kritik 250 milisaniyelik kuyruk (tail latency) sıçramasını tamamen gizler.
Bugünkü yazımızda, Linux çekirdeğinin içine kanca (hook) atarak her bir I/O ve TCP paketini sıfıra yakın yükle (overhead) tek tek ölçen eBPF (bcc-tools ve bpftrace) araçlarıyla bu gizli darboğazları nasıl yakalayacağımızı inceliyoruz.
1. biolatency: Ortalama Değil, Histogram (Dağılım) Analizi
iostat yerine blok katmanındaki gerçek gecikme dağılımını (logaritmik histogram olarak) görmek için bcc-tools paketi içindeki biolatency (RHEL/Ubuntu’da biolatency-bpfcc) aracını kullanmalısınız.

# Kurulum (Ubuntu / Debian / Proxmox VE)
sudo apt install bpfcc-tools linux-headers-$(uname -r) bpftrace -y

# Disk I/O gecikmelerini mikrosaniye (-u) cinsinden, cihaz bazlı (-D) 10 saniye boyunca topla
sudo biolatency-bpfcc -D -u 10 1

Örnek Çıktı ve Okunuşu:

disk = 'nvme0n1'
     usecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 1420     |********                                |
         8 -> 15         : 6840     |****************************************|
        16 -> 31         : 2150     |************                            |
       ...
     16384 -> 32767      : 14       |                                        |
     32768 -> 65535      : 6        |                                        |

Yukarıdaki histogramda gördüğünüz gibi, I/O işlemlerinin neredeyse tamamı 8-31 mikrosaniye arasında biterken, 20 adet işlem 16 ms ile 65 ms (32768-65535 usecs) arasında takılmıştır. İşte uygulamanızdaki anlık teklemenin (jitter) kanıtı buradadır.
2. biosnoop: Hangi Süreç (PID) Hangi Disk Bloğunda Takıldı?
Histogramda gecikme sıçramalarını gördükten sonraki adım, o an hangi sürecin (qemu-system-x86, mysqld, ceph-osd vb.) bu gecikmeye maruz kaldığını ve gecikmenin işletim sistemi kuyruğunda mı (QUE) yoksa fiziksel diskte/SAN’da mı (LAT) yaşandığını bulmaktır.

# İşletim sistemi kuyruk süresini (-Q) dahil ederek canlı I/O akışını izle ve 10ms üzerini filtrele
sudo biosnoop-bpfcc -Q | awk '$1 == "TIME(s)" || $8 > 10.0'

• QUE(ms) yüksek, LAT(ms) düşükse: Sorun fiziksel diskte veya SAN ünitesinde değildir! Linux çekirdeği I/O zamanlayıcısında, LVM/dm-multipath katmanında veya cgroup I/O limitlerinde darboğaz vardır.
• QUE(ms) düşük, LAT(ms) yüksekse: İstek HBA veya NVMe denetleyicisine anında iletilmiş ancak donanım (Storage Array, FC SAN veya fiziksel SSD) geç yanıt vermiştir.

3. Dosya Sistemi Katmanında Yavaş İşlemleri Yakalamak (ext4slower / xfsslower / zfsslower)
Bazen fiziksel disk çok hızlıdır ancak gecikme dosya sisteminin kendi iç kilitlenmelerinden (Page Cache flush, XFS Allocation Group contention veya ZFS ARC/ZIL senkronizasyonu) kaynaklanır. Blok katmanının bir üstüne, doğrudan VFS/Dosya Sistemi katmanına bakmak için:

# XFS dosya sisteminde 10 milisaniyeden uzun süren tüm okuma/yazma/fsync işlemlerini yakala
sudo xfsslower-bpfcc 10

# Proxmox VE / ZFS ortamında 15 ms üzerindeki ZFS işlemlerini anlık yakala
sudo zfsslower-bpfcc 15

Bu araç size sadece süreci (PID) değil, gecikmeye sebep olan tam dosya adını (örneğin vm-104-disk-0.qcow2 veya ib_logfile0) ve işlemin türünü (R Read, W Write, S Sync) doğrudan verir.
4. Ağ Katmanında Gizli TCP Yeniden Gönderimlerini (tcpretrans) İzlemek
iSCSI, NVMe/TCP, Ceph veya NFS gibi IP tabanlı depolama ağlarında mikrosaniyelik paket kayıpları (TCP Retransmission), üst katmana saniyelik disk gecikmesi olarak yansır. Ağda tcpdump açıp gigabaytlarca pcap dosyası analiz etmek yerine, sadece yeniden gönderilen (retransmit) veya kopan (drop) TCP paketlerini çekirdek seviyesinde yakalayabilirsiniz:

# Sistemdeki tüm TCP Retransmit paketlerini kaynak/hedef IP, Port ve TCP durumuyla canlı listele
sudo tcpretrans-bpfcc -l

Eğer burada Ceph OSD veya Storage IP’leriniz arasında düzenli R> (Retransmit) satırları görüyorsanız, switch portlarınızda mikro-patlama (microburst) kaynaklı buffer taşması veya MTU uyumsuzluğu yaşıyorsunuz demektir.