Makalenin çevirisi kursun başlamasının arifesinde hazırlanmıştır. .
Zaman zaman Gluster'ın çekirdek özelleştirmesine ilişkin tavsiyeleri ve bunun gerekli olup olmadığı konusunda bazı sorular ortaya çıkıyor.
Bu ihtiyaç nadiren ortaya çıkar. Çekirdek çoğu iş yükü altında çok iyi performans gösterir. Bir dezavantajı olmasına rağmen. Tarihsel olarak, Linux çekirdeği, fırsat verildiğinde, performansı artırmanın birincil yolu olarak önbelleğe alma da dahil olmak üzere, çok fazla bellek tüketir.
Çoğu durumda bu harika çalışır ancak ağır yük altında sorunlara neden olabilir.
Yüksek yük altında yavaşlamaya başlayan CAD, EDA ve benzeri gibi çok fazla bellek tüketen sistemlerle çalışma konusunda geniş deneyime sahibiz. Bazen Gluster'da sorunlarla karşılaştık. Kullanılan belleği ve disk bekleme süresini bir günden fazla dikkatle izledikten sonra, aşırı disk yükü, büyük iowait, çekirdek hataları (çekirdek hataları), donmalar vb. ile karşılaştık.
Bu makale, çeşitli durumlarda gerçekleştirilen birçok parametre ayarlama deneyinin sonucudur. Bu parametreler sayesinde yalnızca genel olarak yanıt verme hızı iyileşmedi, aynı zamanda kümenin işleyişi de önemli ölçüde stabilize edildi.
Belleği yapılandırmak söz konusu olduğunda bakılacak ilk yer, kafanızı karıştırabilecek çok sayıda seçeneğe sahip olan sanal bellek alt sistemidir (VM).
vm.takas
Parametre vm.swappiness çekirdeğin RAM'e kıyasla ne kadar takas kullandığını belirler. Ayrıca kaynak kodunda “eşlenen hafızayı çalma eğilimi” olarak da tanımlanıyor. Yüksek takas değeri, çekirdeğin eşlenen sayfaları değiştirmeye daha yatkın olacağı anlamına gelir. Düşük takas değeri bunun tersi anlamına gelir: çekirdek, sayfaları bellekten daha az değiştirir. Başka bir deyişle değer ne kadar yüksek olursa vm.swappiness, sistem takası ne kadar çok kullanırsa.
Büyük veri blokları RAM'e yüklendiğinden ve boşaltıldığından, takasın yoğun kullanımı istenmeyen bir durumdur. Birçok kişi takas değerinin yüksek olması gerektiğini savunuyor ancak benim tecrübelerime göre bunu "0" olarak ayarlamak daha iyi performansla sonuçlanıyor.
Daha fazlasını buradan okuyabilirsiniz -
Ancak yine de bu ayarların dikkatle ve yalnızca belirli uygulamayı test ettikten sonra kullanılması gerekir. Yüksek yüklü akış uygulamaları için bu parametrenin "0" olarak ayarlanması gerekir. "0" olarak değiştirildiğinde sistemin yanıt verme hızı artar.
vm.vfs_cache_press
Bu ayar, dizin nesnelerini ve düğümleri (diş ve inode) önbelleğe almak için çekirdek tarafından tüketilen belleği kontrol eder.
Varsayılan değer olan 100 ile çekirdek, dentry ve inode önbelleklerini, sayfa önbelleği ve takas önbelleğine adil bir şekilde boşaltmaya çalışacaktır. vfs_cache_basıncının azaltılması, çekirdeğin dentry ve inode önbelleklerini korumasına neden olur. Değer "0" olduğunda çekirdek, bellek baskısı nedeniyle dentry ve inode önbelleğini hiçbir zaman temizlemez ve bu, kolayca bellek yetersiz hatasına yol açabilir. Vfs_cache_basıncını 100'ün üzerine çıkarmak, çekirdeğin dentry ve inode sayfa çıkışlarına öncelik vermesine neden olur.
GlusterFS kullanırken, büyük miktarda veriye ve çok sayıda küçük dosyaya sahip birçok kullanıcı, inode/dentry önbelleğe alma nedeniyle sunucudaki önemli miktarda RAM'i kolaylıkla kullanabilir; bu, çekirdeğin bir sistemdeki veri yapılarını işlemesi gerektiğinden performansın düşmesine neden olabilir. 40 GB belleğe sahip. Bu parametrenin 100'den büyük bir değere ayarlanması, birçok kullanıcının daha adil önbelleğe alma ve gelişmiş çekirdek yanıt verme hızı elde etmesine yardımcı oldu.
vm.dirty_background_ratio ve vm.dirty_ratio
İlk parametre (vm.dirty_background_ratio) kirli sayfaların diske arka planda temizlenmesinin başlatılmasının gerekli olduğu kirli sayfaların bulunduğu bellek yüzdesini belirler. Bu yüzdeye ulaşılıncaya kadar sayfalar diske aktarılmaz. Sıfırlama başladığında, çalışan işlemleri kesintiye uğratmadan arka planda çalışır.
İkinci parametre (vm.dirty_ratio) zorunlu flaş başlamadan önce kirli sayfaların kaplayabileceği hafıza yüzdesini belirler. Bu eşiğe ulaşıldığında, tüm işlemler eşzamanlı hale gelir (bloke edilir) ve talep ettikleri G/Ç işlemi gerçekten tamamlanana ve veriler diske aktarılana kadar çalışmaya devam etmelerine izin verilmez. Yüksek G/Ç yükünde bu bir soruna neden olur çünkü veri önbelleğe alma yoktur ve G/Ç yapan tüm işlemler G/Ç beklerken engellenir. Bu, çok sayıda işlemin askıda kalmasına, yüksek yüke, sistem kararsızlığına ve düşük performansa neden olur.
Bu parametrelerin değerlerinin düşürülmesi, verilerin diske daha sık atılmasına ve RAM'de saklanmamasına neden olur. Bu, 45-90 GB sayfa önbelleklerinin diske boşaltılmasının normal olduğu bellek ağırlıklı sistemlerde yardımcı olabilir, bu da ön uç uygulamalar için büyük gecikmelere neden olarak genel yanıt verme ve etkileşimi azaltır.
"1" > /proc/sys/vm/pagecache
Sayfa önbelleği, dosyalardan ve yürütülebilir programlardan verileri depolayan bir önbellektir; yani bunlar, dosyaların veya blok aygıtların gerçek içeriğine sahip sayfalardır. Bu önbellek, disk okuma sayısını azaltmak için kullanılır. "1" değeri, önbelleğin RAM'in %1'ini kullandığı ve diskten RAM'den daha fazla okuma yapılacağı anlamına gelir. Bu ayarı değiştirmenize gerek yok ancak sayfa önbelleğini kontrol etme konusunda paranoyanız varsa bunu kullanabilirsiniz.
"son tarih" > /sys/block/sdc/queue/scheduler
G/Ç zamanlayıcısı, Linux çekirdeğinin okuma ve yazma kuyruklarını yöneten bir bileşenidir. Teorik olarak, akıllı bir RAID denetleyicisi için "noop" kullanmak daha iyidir, çünkü Linux diskin fiziksel geometrisi hakkında hiçbir şey bilmez, dolayısıyla disk geometrisini iyi bilen denetleyicinin isteği şu şekilde işlemesine izin vermek daha verimli olur: olabildiğince çabuk. Ancak görünen o ki "son teslim tarihi" performansı artırıyor. Zamanlayıcılar hakkında daha fazla bilgiyi Linux çekirdek kaynak kodunun belgelerinde bulabilirsiniz: linux/Documentation/block/*osched.txt. Ayrıca karma işlemler (çok sayıda yazma) sırasında okuma veriminde de bir artış gözlemledim.
"256" > /sys/block/sdc/queue/nr_requests
Zamanlayıcıya gönderilmeden önce ara bellekteki G/Ç isteklerinin sayısı. Bazı denetleyicilerin dahili kuyruk boyutu (kuyruk_derinliği), G/Ç zamanlayıcının nr_request sayısından daha büyüktür, dolayısıyla G/Ç zamanlayıcının istekleri doğru şekilde önceliklendirme ve birleştirme şansı çok azdır. Son tarih ve CFQ planlayıcıları için, nr_requests'in denetleyicinin dahili kuyruğundan 2 kat daha büyük olması daha iyidir. Sorguları birleştirmek ve yeniden sıralamak, zamanlayıcının ağır yük altında daha duyarlı olmasına yardımcı olur.
echo "16" > /proc/sys/vm/sayfa kümesi
Sayfa kümesi parametresi, bir kerede takasa yazılan sayfaların sayısını kontrol eder. Yukarıdaki örnekte değer, 16 KB'lik RAID şerit boyutuyla eşleşecek şekilde "64" olarak ayarlanmıştır. Takas = 0 olduğunda bu mantıklı değildir, ancak takası 10 veya 20'ye ayarlarsanız RAID şerit boyutu 64 KB olduğunda bu değeri kullanmak size yardımcı olacaktır.
blokdev --setra 4096 /dev/<geliştirici adı> (-sdb, hdc veya dev_mapper)
Birçok RAID denetleyicisi için varsayılan blok aygıtı ayarları genellikle çok kötü performansla sonuçlanır. Yukarıdaki seçeneğin eklenmesi 4096*512 bayt sektörler için ileri okumayı yapılandırır. En azından akış işlemleri için, çekirdeğin G/Ç'yi hazırlamak için kullandığı süre boyunca çip üzerindeki disk önbelleğinin ileri okuma yoluyla doldurulmasıyla hız artırılır. Önbellek bir sonraki okuma sırasında istenecek verileri tutabilir. Çok fazla ileri okuma, potansiyel olarak faydalı disk süresini tüketiyorsa veya verileri önbelleğin dışına yüklüyorsa, büyük dosyalar için rastgele G/Ç'yi sonlandırabilir.
Aşağıda dosya sistemi düzeyinde birkaç öneri daha bulunmaktadır. Ancak henüz test edilmediler. Dosya sisteminizin şerit boyutunu ve dizideki disk sayısını bildiğinden emin olun. Örneğin, bu altı diskten oluşan 5K şerit boyutuna sahip bir raid64 dizisidir (aslında beştir, çünkü bir disk eşlik için kullanılır). Bu öneriler teorik varsayımlara dayanmaktadır ve RAID uzmanları tarafından çeşitli bloglardan/makalelerden toplanmıştır.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Daha büyük dosyalar için yukarıdaki şerit boyutlarını artırmayı düşünebilirsiniz.
UYARI! Yukarıda açıklanan her şey bazı uygulama türleri için son derece özneldir. Bu makale, ilgili uygulamaları kullanıcı tarafından ilk kez test etmeden herhangi bir iyileştirmeyi garanti etmez. Yalnızca genel sistem yanıt verme yeteneğinin iyileştirilmesi gerekiyorsa veya mevcut sorunları çözüyorsa kullanılmalıdır.
Ek materyaller:
Devamını oku
Kaynak: habr.com