Niyə mənim NVMe SSD-dən daha yavaşdır?

Bu yazıda biz I/O altsisteminin bəzi nüanslarını və onların performansa təsirini nəzərdən keçirəcəyik.

Bir neçə həftə əvvəl mən bir sualla qarşılaşdım ki, niyə bir serverdə NVMe digərində SATA-dan daha yavaşdır. Mən serverlərin xüsusiyyətlərinə baxdım və bunun hiyləli sual olduğunu başa düşdüm: NVMe istifadəçi seqmentindən, SSD isə server seqmentindən idi.

Aydındır ki, müxtəlif mühitlərdə müxtəlif seqmentlərdən olan məhsulları müqayisə etmək düzgün deyil, lakin bu, tam texniki cavab deyil. Əsasları öyrənəcəyik, təcrübələr aparacağıq və verilən suala cavab verəcəyik.

fsync nədir və harada istifadə olunur

Sürücülərlə işi sürətləndirmək üçün məlumatlar tamponlanır, yəni buferin məzmununu sürücüyə saxlamaq üçün əlverişli fürsət yaranana qədər uçucu yaddaşda saxlanılır. Fürsət meyarları əməliyyat sistemi və sürücünün xüsusiyyətləri ilə müəyyən edilir. Elektrik kəsilməsi halında buferdəki bütün məlumatlar itiriləcək.

Fayldakı dəyişikliklərin sürücüyə yazıldığını və ara tamponda yatmadığından əmin olmağınız lazım olan bir sıra vəzifələr var. Bu əminliyi POSIX-ə uyğun fsync sistemi çağırışından istifadə etməklə əldə etmək olar. fsync çağırışı buferdən sürücüyə yazmağa məcbur edir.

Qısa C proqramı şəklində süni nümunə ilə buferlərin təsirini nümayiş etdirək.

#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;
}

Şərhlər proqramdakı hərəkətlərin ardıcıllığını yaxşı izah edir. "Həyatın, kainatın və bütün bunların əsas sualının cavabı" mətni əməliyyat sistemi tərəfindən buferlənəcək və "hesablamalar" zamanı Reset düyməsini sıxaraq serveri yenidən işə salsanız, fayl boş olacaq. Bizim nümunəmizdə mətn itkisi problem deyil, ona görə də fsync lazım deyil. Verilənlər bazaları bu optimizmi bölüşmür.

Verilənlər bazaları eyni vaxtda bir çox faylla işləyən mürəkkəb proqramlardır, ona görə də verilənlər bazası daxilində verilənlərin ardıcıllığı bundan asılı olduğundan, yazdıqları məlumatların sürücüdə saxlanacağına əmin olmaq istəyirlər. Məlumat bazaları bütün tamamlanmış əməliyyatları qeyd etmək və hər an elektrik kəsilməsinə hazır olmaq üçün nəzərdə tutulub. Bu davranış sizi fsync-dən daim böyük miqdarda istifadə etməyə məcbur edir.

Fsync-in tez-tez istifadəsinə nə təsir edir

Normal I/O ilə əməliyyat sistemi disk rabitəsini optimallaşdırmağa çalışır, çünki xarici disklər yaddaş iyerarxiyasında ən yavaşdır. Buna görə də, əməliyyat sistemi sürücüyə bir girişdə mümkün qədər çox məlumat yazmağa çalışır.

Gəlin fsync-dən istifadənin təsirini konkret bir nümunə ilə nümayiş etdirək. Test mövzuları olaraq aşağıdakı SSD-lərə sahibik:

• Intel® DC SSD S4500 480 GB, SATA 3.2, 6 Gb/s vasitəsilə qoşulmuş;
• Samsung 970 EVO Plus 500GB, PCIe 3.0 x4 vasitəsilə qoşulmuş, ~31 Gbps.

Testlər Ubuntu 2255 ilə işləyən Intel® Xeon® W-20.04-də aparılır. Diskləri yoxlamaq üçün sysbench 1.0.18 istifadə olunur. Disklərdə ext4 kimi formatlanmış tək bölmə var. Testə hazırlıq 100 GB fayl yaratmaqdır:

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

Çalışan testlər:

# Без 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 nəticələri cədvəldə təqdim olunur.

Sınaq
Intel® S4500
Samsung 970 EVO+

Fsync olmadan oxuyun, MiB/s
5734.89
9028.86

Fsync olmadan yazın, MiB/s
3823.26
6019.24

fsync ilə oxuma, MiB/s
37.76
3.27

fsync ilə qeyd, MiB/s
25.17
2.18

Müştəri seqmentindən olan NVMe-nin əməliyyat sisteminin özü disklərlə necə işləməyə qərar verdiyi zaman inamla liderlik etdiyini və fsync istifadə edildikdə itirdiyini görmək asandır. Bu iki sual doğurur:

1. Niyə oxuma sürəti fsync olmadan testdəki linkin fiziki bant genişliyini aşır?
2. Nə üçün bir server seqmenti SSD çoxlu sayda fsync sorğularını idarə etməkdə daha yaxşıdır?

Birinci sualın cavabı sadədir: sysbench sıfır dolu fayllar yaradır. Beləliklə, sınaq 100 giqabayt sıfırdan çox aparıldı. Məlumatlar çox vahid və proqnozlaşdırıla bilən olduğundan, müxtəlif OS optimallaşdırmaları işə düşür və onlar icranı əhəmiyyətli dərəcədə sürətləndirir.

Əgər sysbench-in bütün nəticələrini sorğulasanız, o zaman fio-dan istifadə edə bilərsiniz.

# Без 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

Sınaq
Intel® S4500
Samsung 970 EVO+

Fsync olmadan oxuyun, MiB/s
45.5
178

Fsync olmadan yazın, MiB/s
30.4
119

fsync ilə oxuma, MiB/s
32.6
20.9

fsync ilə qeyd, MiB/s
21.7
13.9

Fsync istifadə edərkən NVMe-də performansın azalması tendensiyası aydın görünür. İkinci suala keçə bilərsiniz.

Optimallaşdırma və ya blef

Əvvəllər məlumatların buferdə saxlandığını demişdik, lakin vacib olmadığı üçün hansında olduğunu dəqiqləşdirməmişik. İndi də biz əməliyyat sistemlərinin incəliklərini araşdırmayacağıq və iki ümumi bufer növünü ayırmayacağıq:

• proqram;
• aparat.

Proqram təminatı buferi əməliyyat sistemində olan buferlərə, hardware buferi isə disk nəzarətçisinin uçucu yaddaşına aiddir. fsync sistem çağırışı sürücüyə məlumatların buferindən əsas yaddaşa yazılması əmri göndərir, lakin onun əmrin düzgün icrasına nəzarət etmək imkanı yoxdur.

SSD daha yaxşı işlədiyi üçün iki fərziyyə irəli sürmək olar:

• disk oxşar planın yükü üçün nəzərdə tutulmuşdur;
• disk "blöf" edir və əmrə məhəl qoymur.

Elektrik kəsilməsi ilə bir sınaq keçirsəniz, sürücünün vicdansız davranışı fərq edilə bilər. Bunu skriptlə yoxlaya bilərsiniz. diskchecker.plbu idi quruldu 2005 il.

Bu skript iki fiziki maşın tələb edir - "server" və "müştəri". Müştəri sınaq altında olan sürücüyə az miqdarda məlumat yazır, fsync-ə zəng edir və yazılanlar haqqında server məlumatını göndərir.

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

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

Skripti işə saldıqdan sonra "müştəri" enerjisini kəsmək və bir neçə dəqiqə gücü qaytarmamaq lazımdır. Test mövzusunu elektrik enerjisindən ayırmaq vacibdir və yalnız sərt bir söndürmə həyata keçirmir. Bir müddət sonra server qoşula və OS-yə yüklənə bilər. OS-ni yüklədikdən sonra yenidən başlamalısınız diskchecker.pl, lakin arqumentlə yoxlamaq.

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

Yoxlamanın sonunda səhvlərin sayını görəcəksiniz. Əgər onlar 0-dırsa, disk testdən keçdi. Disk üçün uğurlu olan halların birləşməsini istisna etmək üçün təcrübə bir neçə dəfə təkrarlana bilər.

Bizim S4500 güc itkisi xətası göstərmədi, bu o deməkdir ki, o, çoxlu fsync zəngləri olan yüklərə hazırdır.

Nəticə

Diskləri və ya bütün hazır konfiqurasiyaları seçərkən, həll edilməli olan vəzifələrin xüsusiyyətlərini yadda saxlamalısınız. İlk baxışdan NVMe-nin, yəni PCIe interfeysli SSD-nin “klassik” SATA SSD-dən daha sürətli olduğu aydın görünür. Ancaq bu gün başa düşdüyümüz kimi, konkret şəraitdə və müəyyən vəzifələrdə bu belə olmaya bilər.

IaaS provayderindən icarəyə götürərkən server komponentlərini necə sınayırsınız?
Sizi şərhlərdə gözləyirik.

Mənbə: www.habr.com