NVMe'm neden SSD'mden daha yavaş?

Bu makalede G/Ç alt sisteminin bazı nüanslarına ve bunların performans üzerindeki etkilerine bakacağız.

Birkaç hafta önce neden bir sunucudaki NVMe'nin diğer sunucudaki SATA'dan daha yavaş olduğu sorusuyla karşılaştım. Sunucu özelliklerine baktım ve bunun zor bir soru olduğunu fark ettim: NVMe kullanıcı segmentinden, SSD ise sunucu segmentindendi.

Açıkçası, farklı ortamlardaki farklı segmentlerdeki ürünleri karşılaştırmak adil değil, ancak bu tam bir teknik cevap değil. Temelleri inceleyelim, deneyler yapalım ve sorulan soruya cevap verelim.

Fsync nedir ve nerede kullanılır?

Sürücülerle çalışmayı hızlandırmak için veriler ara belleğe alınır, yani arabellek içeriğini sürücüye kaydetmek için uygun bir fırsat ortaya çıkana kadar geçici bellekte saklanır. Bir “fırsat”ın kriterleri işletim sistemi ve sürücünün özelliklerine göre belirlenir. Elektrik kesintisi durumunda arabellekteki tüm veriler kaybolacaktır.

Bir dosyada yapılan değişikliklerin ara ara belleğe değil sürücüye yazıldığından emin olmanız gereken bir dizi görev vardır. Bu güvence POSIX uyumlu fsync sistem çağrısı kullanılarak elde edilebilir. Fsync'in çağrılması, arabellekten sürücüye yazmaya zorlar.

Tamponların etkisini C dilinde kısa bir program şeklinde yapay bir örnekle gösterelim.

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /* Открываем файл answer.txt на запись, если его нет -- создаём */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /* Записываем первый набор данных */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /* Делаем вид, что проводим вычисления в течение 10 секунд */
    sleep(10);
    /* Записываем результат вычислений */
    write(fd, "42n", 3); 

    return 0;
}

Yorumlar programdaki eylemlerin sırasını iyi açıklıyor. "Hayatın, Evrenin ve tüm bunların ana sorusunun cevabı" metni işletim sistemi tarafından arabelleğe alınacak ve "hesaplamalar" sırasında Sıfırla düğmesine basarak sunucuyu yeniden başlatırsanız dosya boş olacaktır. Örneğimizde metin kaybı bir sorun olmadığından fsync'e gerek yoktur. Veritabanları bu iyimserliği paylaşmıyor.

Veritabanları birçok dosyayla aynı anda çalışan karmaşık programlardır, bu nedenle veritabanı içindeki verilerin tutarlılığı buna bağlı olduğundan yazdıkları verilerin sürücüye kaydedileceğinden emin olmak isterler. Veritabanları, tamamlanan tüm işlemleri kaydedecek ve her an güç kaybına hazır olacak şekilde tasarlanmıştır. Bu davranış, fsync'in sürekli olarak büyük miktarlarda kullanılmasını gerektirir.

Fsync'in sık kullanımının etkisi nedir?

Normal G/Ç sırasında, harici sürücüler bellek hiyerarşisindeki en yavaş sürücüler olduğundan işletim sistemi disklerle iletişimi optimize etmeye çalışır. Bu nedenle işletim sistemi, sürücüye tek erişimde mümkün olduğu kadar çok veri yazmaya çalışır.

Belirli bir örnekle fsync kullanmanın etkisini gösterelim. Test sürüşü olarak aşağıdaki SSD'lere sahibiz:

• Intel® DC SSD S4500 480 GB, SATA 3.2, 6 Gbit/s aracılığıyla bağlanır;
• Samsung 970 EVO Plus 500 GB, PCIe 3.0 x4, ~31 Gbit/s ile bağlandı.

Testler, Ubuntu 2255 çalıştıran Intel® Xeon® W-20.04 üzerinde gerçekleştirilir. Sysbench 1.0.18 diskleri test etmek için kullanılır. Disklerde ext4 olarak biçimlendirilmiş bir bölüm oluşturuldu. Teste hazırlanmak 100 GB'lık dosyalar oluşturmayı içerir:

sysbench --test=fileio --file-total-size=100G prepare

Testlerin yürütülmesi:

# Без fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

# С fsync после каждой записи
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

Test sonuçları tabloda sunulmaktadır.

Test
Intel® S4500
Samsung 970EVO+

Fsync olmadan okuma, MiB/s
5734.89
9028.86

Fsync olmadan kayıt, MiB/s
3823.26
6019.24

Fsync, MiB/s ile okuma
37.76
3.27

Fsync, MiB/s ile kayıt
25.17
2.18

İşletim sisteminin disklerle nasıl çalışacağına kendisi karar verdiğinde istemci segmentindeki NVMe'nin güvenle lider olduğunu ve fsync kullanıldığında kaybettiğini görmek kolaydır. Bu iki soruyu gündeme getiriyor:

1. Fsync olmadan yapılan testte okuma hızı neden kanalın fiziksel bant genişliğini aşıyor?
2. Neden bir sunucu segmenti SSD'si çok sayıda fsync isteğini işlemede daha iyidir?

İlk sorunun cevabı basit: sysbench sıfırlarla dolu dosyalar oluşturur. Böylece test 100 gigabayt sıfırın üzerinde gerçekleştirildi. Veriler oldukça tekdüze ve öngörülebilir olduğundan, çeşitli işletim sistemi optimizasyonları devreye giriyor ve yürütmeyi önemli ölçüde hızlandırıyor.

Tüm sysbench sonuçlarını sorguluyorsanız fio'yu kullanabilirsiniz.

# Без fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

# С fsync после каждой записи
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

Test
Intel® S4500
Samsung 970EVO+

Fsync olmadan okuma, MiB/s
45.5
178

Fsync olmadan kayıt, MiB/s
30.4
119

Fsync, MiB/s ile okuma
32.6
20.9

Fsync, MiB/s ile kayıt
21.7
13.9

Fsync kullanıldığında NVMe performansının düşme eğilimi açıkça görülüyor. İkinci sorunun cevabına geçebilirsiniz.

Optimizasyon veya blöf

Daha önce verinin tamponda saklandığını söylemiştik ama hangisi olduğunu belirtmedik çünkü bu önemli değildi. Şimdi bile işletim sistemlerinin inceliklerine dalmayacağız ve iki genel tampon tipini vurgulayacağız:

• programı;
• donanım.

Yazılım arabelleği, işletim sisteminde bulunan arabellekleri ifade eder ve donanım arabelleği, disk denetleyicisinin geçici belleğini ifade eder. fsync sistem çağrısı, verileri arabelleğinden ana depolama birimine yazmak için sürücüye bir komut gönderir, ancak komutun doğru şekilde yürütüldüğünü doğrulamanın bir yolu yoktur.

SSD en iyi sonuçları gösterdiğinden iki varsayım yapılabilir:

• disk benzer bir yük için tasarlanmıştır;
• disk “blöf yapar” ve komutu yok sayar.

Güç kaybı testi yaparsanız sürücünün hatalı davranışı fark edilebilir. Bunu bir komut dosyasıyla kontrol edebilirsiniz diskchecker.pl, который был tarafından oluşturuldu 2005 yılda.

Bu komut dosyası iki fiziksel makine gerektirir - bir "sunucu" ve bir "istemci". İstemci, test edilen diske az miktarda veri yazar, fsync'i çağırır ve yazılanlarla ilgili bilgileri sunucuya gönderir.

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Komut dosyasını çalıştırdıktan sonra, "istemciye" giden gücü kapatmanız ve birkaç dakika boyunca gücü geri vermemeniz gerekir. Test edilen kişinin elektrikle olan bağlantısını kesmek ve sadece sert bir kapatma yapmak değil, önemlidir. Bir süre sonra sunucu bağlanabilir ve işletim sistemine yüklenebilir. İşletim sistemini yükledikten sonra yeniden başlatmanız gerekir diskchecker.pl, ama bir argümanla doğrulamak.

./diskchecker.pl -s <server[:port]> verify <file>

Kontrolün sonunda hata sayısını göreceksiniz. 0 varsa disk testi geçmiştir. Disk için şanslı bir tesadüfü dışlamak için deney birkaç kez tekrarlanabilir.

S4500'ümüz güç kesildiğinde hiçbir hata göstermedi; bu, çok sayıda fsync çağrısı içeren iş yüklerine hazır olduğu anlamına gelir.

Sonuç

Diskleri veya hazır konfigürasyonların tamamını seçerken çözülmesi gereken sorunların özelliklerini hatırlamanız gerekir. İlk bakışta NVMe yani PCIe arayüzüne sahip bir SSD'nin "klasik" SATA SSD'den daha hızlı olduğu aşikar görünüyor. Ancak bugün öğrendiğimiz gibi, belirli koşullarda ve belirli görevlerde durum böyle olmayabilir.

Bir IaaS sağlayıcısından kiralarken sunucu bileşenlerini nasıl test edersiniz?
Yorumlara bekliyoruz.

Kaynak: habr.com