SSD nukes sistem performansı üzerinde yoğun yazma etkinliği

Ağır yazma uygulamaları yaptığımda tüm sistemin yavaşladığını fark ettim. Bunu daha fazla test etmek için bunu (nispeten) düşük CPU, yüksek disk etkinliği yapmak için koştu:

john -incremental > file_on_SSD

Bu, sistem diskimdeki bir dosyaya saniyede on binlerce dizeyi pompalar.

Bunu yaparken, fare gecikiyor, TTY'ler yanıt vermiyor, uygulamalar "soluyor" ve genellikle tüm bilgisayar kullanılamaz hale geliyor. Sonunda Control + C yapabildiğimde john, sistem birkaç saniye sonra tam güce geri döner.

Bu aşırı bir örnek ama hızlı kaynaklardan büyük dosyaları kopyalama veya kod dönüştürme gibi biraz daha az yoğun yazılan etkinlikler ile benzer sorunlarım var.

Ana işletim sistemi diskim EXT4 ile oldukça hızlı bir SSD ( OCZ Agility 60GB ). Yazmaya Eğer johnEXT4 mekanik diske 'in çıkış hızı daha yavaş olmasına rağmen, I (w / s 8,000 yapar mekanik saniyede ~ SSD yapar 42.000 kelime) aynı yavaşlamaları yaşamazlar. Verim uygun olabilir. Mekanik diskin sistemle hiçbir ilgisi yoktur. Sadece veri.

Ve 2.6.35-2 çekirdeğini kullanıyorum, ancak muhtemelen o zamandan beri .31 veya başka bir şey kullanırken bu SSD'yi aldığımdan beri bu sorunu fark ettim.

Peki yavaşlamaya ne sebep oluyor? EXT4 sorunu mu? Çekirdek sorunu mu? SSD sorunu mu? Yukarıdakilerin hepsi? Başka bir şey?

Ek bir test yapmam gerektiğini düşünüyorsanız, bana ne yapacağımı söyleyen bir yorum bırakın ve sonucu soruya ekleyeceğim.

Bu bir süredir bilinen bir sorundu. Btrfs gibi SSD ayarlı bir FS kullanmak yardımcı olabilir, ancak işe yaramayabilir.

Sonuçta, bu, IO zamanlayıcı / bellek yönetim sistemlerinde bir hatadır. Son zamanlarda, bu sorunu ele almayı amaçlayan bazı yamalar olmuştur. Bkz Sabit: Linux Masaüstü Duyarlılığı Sorununu?

Bu yamalar sonunda ana çekirdeğe girebilir, ancak şimdilik bu sorunu düzeltmek istiyorsanız kendi çekirdeğinizi derlemeniz gerekecektir.

Linux altında SSD performansını artırmak için kontrol edebileceğiniz birkaç şey var.

1. Bağlama noktasını 'noatime' olarak ayarlayın. Ekstra aktivite güncelleme erişim süreleri çoğu kullanım durumunda genellikle boşa gider. Özellikle tek satırları sürekli olarak bir dosyaya pompalamak durumunda, her erişim için dosya sisteminde birden fazla güncelleme yapmaya zorlarsınız.

2. Asansörü kontrol edin. Çoğu dağıtım için varsayılan asansör, rasgele erişimli eğirme plakaları için ayarlanmıştır. SSD'ler ekstra mantığa ihtiyaç duymaz, bu nedenle asansörün noop olarak ayarlanması, donanımın yazma işlemlerini yönetmesine izin vererek performansı artırabilir.

3. Geri yazma v geri yazma önbelleği. Bu biraz daha ezoterik, ancak hdparmcihaz için kullanılan önbellek yöntemini kontrol edebilirsiniz . Geri yazma önbelleğinin, yazma işlemine kıyasla SSD performansı üzerinde olumlu bir etkisi olabilir.

Dosya önbelleğiniz muhtemelen iş yükünüz için yanlış ayarlanmıştır. Ne yazık ki, Linux çekirdeği bunu otomatik olarak işlemeyecek kadar aptal ve çok fazla RAM'iniz ve yeterince yavaş blok cihazlarınız varsa varsayılanlar oldukça kötü. Ayrıntılar için bkz. Https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ .

Ben değiştirerek çalışıyor öneririm /etc/sysctl.confya

vm.dirty_background_ratio = 3
vm.dirty_ratio = 6

çekirdeğin diğer görevleri daha iyi ele almasını sağlamak için yazma önbelleğinin neden olduğu RAM basıncını büyük ölçüde azaltmak için. Bu, düşük verim için gelişmiş gecikme süresi ticaretinde bulunacaktır.

Başka bir olasılık, önbelleği artırmaktır, ancak işleminiz sürekli olarak yeni veriler yazmaya devam ederse, önbellek dolarsa çok kötü bir gecikme yaşayacaksınız. Denemek isterseniz, böyle bir şey yapabilirsiniz

vm.dirty_background_ratio = 5
vm.dirty_ratio = 80

Not *_ratioayarlar kullanılabilir RAM yüzdesine bakın. Daha iyi kontrol istiyorsanız, *_bytesayarları kullanın . Kişisel olarak iş istasyonum için aşağıdaki yapılandırmayı kullanıyorum:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000

Bu, arka plan yazma önbelleğini 50 MB ile sınırlar ve 200 MB önbellekte ise senkronize yazmaya zorlar.