Linux - gerçek dünya donanım RAID denetleyicisi ayarı (scsi ve cciss)

Yönettiğim Linux sistemlerinin çoğu donanım RAID denetleyicileri (çoğunlukla HP Smart Array ) içerir. Hepsi RHEL veya CentOS kullanıyor.

SAS diskleri (Smart Array, Perc, LSI, vb.) Ve pil destekli veya flash destekli önbellek içeren donanım RAID denetleyicilerini içeren kurulumlarda performansı optimize etmeye yardımcı olan gerçek dünyaya uygun ayarlayıcılar arıyorum. RAID 1 + 0 ve çoklu iş milleri (4+ disk) varsayalım.

Düşük gecikmeli ve finansal işlem uygulamaları için Linux ağ ayarlarını yapmak için önemli miktarda zaman harcıyorum. Ancak bu seçeneklerin çoğu iyi belgelenmiştir (gönderme / alma arabelleklerini değiştirme, TCP pencere ayarlarını değiştirme vb.). Mühendisler depolama tarafında ne yapıyor?

Tarihsel olarak, ben değişiklikler yaptık G / Ç zamanlama asansör geçenlerde için gözle deadlineve noopbenim uygulamalar içinde performansını artırmak için schedulers. RHEL sürümleri ilerledikçe, SCSI ve CCISS blok aygıtları için derlenmiş varsayılan değerlerin de değiştiğini fark ettim. Bunun zaman içinde önerilen depolama altsistemi ayarları üzerinde etkisi oldu. Ancak, net bir öneri gördüğümden beri bir süre geçti. Ve işletim sistemi varsayılanlarının optimal olmadığını da biliyorum. Örneğin, 128kb'lik varsayılan okuma önbelleği, sunucu sınıfı donanımda bir dağıtım için son derece küçük görünüyor.

Aşağıdaki makaleler, önceden okunan önbellek değiştirmenin ve nr_requests değerlerinin blok kuyrukları üzerindeki performans etkisini araştırıyor .

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with -linux-why-tuning-gerçekten önemli konular
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

Örneğin, bunlar bir HP Smart Array RAID denetleyicisi için önerilen değişikliklerdir:

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

Depolama performansını artırmak için başka ne gibi güvenilir bir ayarlama yapılabilir?
Özellikle üretim senaryolarında sysctl ve sysfs seçeneklerini arıyorum.

Düşük gecikme gecikmesine karşı verim ayarlamak zorunda kaldığımda, nr_requests ayarını varsayılandan aşağı indirdim (32'ye kadar). Küçük gruplar halinde olma fikri daha düşük gecikmeye eşittir.

Ayrıca read_ahead_kb için sıralı okuma / yazma işlemleri için bu değerin artırılmasının daha iyi verim sunduğunu, ancak bu seçeneğin gerçekten iş yükünüze ve IO düzeninize bağlı olduğunu buldum. Örneğin, yakın zamanda ayarladığım bir veritabanı sisteminde, bu gecikmeyi, okuma gecikmesini azaltmaya yardımcı olan tek bir db sayfa boyutuyla eşleşecek şekilde değiştirdim. Bu değerin artması ya da azalması benim durumumda performansa zarar verdi.

Diğer seçenekler veya aygıt engelleme kuyrukları için ayarlar gelince:

max_sectors_kb = Bu değeri, donanımın tek bir aktarıma izin verdiği değer ile eşleştireceğim (neyin izin verildiğini görmek için sysfs'deki max_hw_sectors_kb (RO) dosyasının değerini kontrol edin)

nomerges = bu, io isteklerini birleştirmek için arama mantığını devre dışı bırakmanıza veya ayarlamanıza izin verir. (Bunu kapatmak size bazı işlem döngüleri kazandırabilir, ancak bunu sistemlerim için değiştirirken hiçbir fayda görmedim, bu yüzden varsayılan olarak bıraktım)

rq_affinity = Bunu henüz denemedim, ama işte bunun arkasındaki çekirdek dokümanlardaki açıklama.

Bu seçenek '1' ise, blok katmanı, istek tamamlama işlemini ilk başta isteği gönderen cpu "grubuna" geçirir. Bazı iş yükleri için bu, önbellekleme etkileri nedeniyle CPU döngülerinde önemli bir azalma sağlar.
Tamamlama işleminin dağıtımını maksimize etmesi gereken depolama yapılandırmaları için bu seçenek '2' olarak ayarlanmalı, tamamlama işlemi talep eden cpu üzerinde çalışmaya zorlanır ("grup" toplama mantığını atlayarak)

scheduler = son tarihi ve noopu denediğinizi söylediniz. Hem noop hem de son tarihi test ettim, ancak en son bir veritabanı sunucusu için yaptığım test için son teslim tarihini bulduk.

NOOP iyi performans gösterdi, ancak veritabanı sunucumuz için son tarih zamanlayıcısını ayarlayarak daha iyi performans elde ettim.

/ Sys / block / {sd, cciss, dm -} * / queue / iosched / altındaki son tarih zamanlayıcı seçenekleri:

fifo_batch = nr_requests benzeri bir tür, ancak zamanlayıcıya özgü. Başparmak kuralı, daha düşük gecikme süresi için aşağı veya verim için yukarı ayarlamaktır. Okuma ve yazma isteklerinin parti boyutunu kontrol eder.

write_expire = yazma kümeleri için son kullanma zamanını varsayılan olarak 5000 ms'dir. Bir kez daha düşürünce, bu değer yazma gecikme oranınızı düşürür, değer ise verimi artırır.

read_expire = Okuma grupları için sona erme zamanını 500ms varsayılan olarak ayarlar. Burada da aynı kurallar geçerlidir.

front_merges = Bunu kapatma eğilimindeyim ve varsayılan olarak açık. Zamanlayıcının, birleştirme GÇ isteklerini önlemeye çalışırken cpu döngülerini boşa harcama gereğini görmüyorum.

writes_starved = son tarih doğru okumaya yönelik olduğundan, buradaki varsayılan değer, bir yazma partisi işlemden önce 2 okuma grubunu işlemek içindir. İş yüküm için iyi olan 2 varsayılanı buldum.

Her şeyden çok, her şey iş yüküne bağlı.

read_ahead_kbVideo akışında olduğu gibi, zamanından önce bazı dosyalardan çok fazla veri okumak gerçekten yardımcı olabilir. Bazen sana çok zarar verebilir. Evet, varsayılan 128 KB küçük gibi gelebilir, ancak yeterince eşzamanlılık ile büyük gibi ses çıkarmaya başlar! Öte yandan, videoları yalnızca bir formattan diğerine dönüştüren bir video kodlama sunucusu gibi bir sunucuyla, ayarlamak çok iyi bir fikir olabilir.

nr_requests, fazla kullanıldığında, RAID denetleyicinizi kolayca aktarabilir, bu da performansı düşürür.

Gerçek dünyada gecikmeleri izlemelisin . SAN bağlıysanız, bir ile bakmak iostat, sarkullanımına gibi ya da her türlü sen ve ben / Ç istek hizmet süreleri üst noktada olmadığını görmek. Elbette bu, yerel disklerde de yardımcı olur: gecikmeler çok büyükse, G / Ç asansör ayarlarınızı max_requestleri ve diğer ayarları düşürerek ayarlamayı düşünün.

Bilginize read_ahead_kbve blockdev --setrasadece olan farklı birimleri kullanarak aynı ayarını farklı yolları (sektörlerden vs kB):

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

Böylece

blockdev --setra 65536 /dev/cciss/c0d0

Örneğinizde etkisi yoktur.