किन मेरो NVMe SSD भन्दा ढिलो छ?

यस लेखमा, हामी I / O उपप्रणालीका केही सूक्ष्मताहरू र प्रदर्शनमा तिनीहरूको प्रभावलाई हेर्नेछौं।

केहि हप्ता अघि म एउटा प्रश्नमा दगुरेँ किन एक सर्भरमा NVMe अर्कोमा SATA भन्दा ढिलो छ। मैले सर्भरका विशेषताहरू हेरेँ र महसुस गरें कि यो एक चाल प्रश्न हो: NVMe प्रयोगकर्ता खण्डबाट थियो, र SSD सर्भर खण्डबाट थियो।

जाहिर छ, बिभिन्न परिवेशमा बिभिन्न खण्डका उत्पादनहरू तुलना गर्नु सही होइन, तर यो एक विस्तृत प्राविधिक उत्तर होइन। हामी आधारभूत कुराहरू अध्ययन गर्नेछौं, प्रयोगहरू सञ्चालन गर्नेछौं र सोधिएको प्रश्नको जवाफ दिनेछौं।

fsync के हो र यो कहाँ प्रयोग गरिन्छ

ड्राइभको साथ कामको गति बढाउनको लागि, डाटा बफर गरिएको छ, त्यो हो, वाष्पशील मेमोरीमा भण्डारण गरिएको छ जबसम्म ड्राइभमा बफरको सामग्रीहरू बचत गर्न एक सुविधाजनक अवसरले आफैलाई प्रस्तुत गर्दैन। अवसर मापदण्ड अपरेटिङ सिस्टम र ड्राइभ विशेषताहरु द्वारा निर्धारण गरिन्छ। पावर विफलताको घटनामा, बफरमा सबै डाटा हराउनेछ।

त्यहाँ धेरै कार्यहरू छन् जसमा यो निश्चित हुन आवश्यक छ कि फाइलमा परिवर्तनहरू ड्राइभमा लेखिएको छ, र मध्यवर्ती बफरमा होइन। यो आश्वासन POSIX-compliant fsync प्रणाली कल प्रयोग गरेर प्राप्त गर्न सकिन्छ। fsync कलले बफरबाट ड्राइभमा लेख्न बाध्य पार्छ।

छोटो C कार्यक्रमको रूपमा कृत्रिम उदाहरणको साथ बफरहरूको प्रभाव प्रदर्शन गरौं।

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

टिप्पणीहरूले कार्यक्रममा कार्यहरूको क्रम राम्रोसँग व्याख्या गर्दछ। पाठ "जीवनको मुख्य प्रश्नको जवाफ, ब्रह्माण्ड र ती सबै" अपरेटिङ सिस्टम द्वारा बफर गरिनेछ, र यदि तपाईंले "गणना" को समयमा रिसेट बटन थिचेर सर्भर पुन: सुरु गर्नुभयो भने, फाइल खाली हुनेछ। हाम्रो उदाहरणमा, पाठ हराउने समस्या होइन, त्यसैले fsync आवश्यक छैन। डाटाबेसहरूले यो आशावाद साझा गर्दैनन्।

डाटाबेसहरू जटिल प्रोग्रामहरू हुन् जसले एकै समयमा धेरै फाइलहरूसँग काम गर्दछ, त्यसैले तिनीहरू निश्चित हुन चाहन्छन् कि उनीहरूले लेखेका डाटा ड्राइभमा भण्डार गरिनेछ, किनकि डाटाबेस भित्र डाटाको स्थिरता यसमा निर्भर गर्दछ। डाटाबेसहरू सबै सम्पन्न लेनदेनहरू रेकर्ड गर्न र कुनै पनि समयमा पावर आउटेजको लागि तयार हुन डिजाइन गरिएको हो। यो व्यवहारले तपाईलाई fsync लगातार ठूलो मात्रामा प्रयोग गर्न बाध्य बनाउँछ।

fsync को बारम्बार प्रयोगलाई कुन कुराले असर गर्छ

सामान्य I/O सँग, अपरेटिङ सिस्टमले डिस्क संचारलाई अप्टिमाइज गर्ने प्रयास गर्छ, किनभने बाह्य ड्राइभहरू मेमोरी पदानुक्रममा सबैभन्दा ढिलो हुन्छन्। त्यसकारण, अपरेटिङ सिस्टमले ड्राइभमा एक पहुँचमा सकेसम्म धेरै डाटा लेख्न प्रयास गर्दछ।

एउटा विशेष उदाहरणको साथ fsync को प्रयोगको प्रभाव प्रदर्शन गरौं। हामीसँग निम्न SSD हरू परीक्षण विषयहरू छन्:

• Intel® DC SSD S4500 480 GB, SATA 3.2, 6 Gb/s मार्फत जोडिएको;
• Samsung 970 EVO Plus 500GB, PCIe 3.0 x4, ~ 31 Gbps मार्फत जोडिएको।

परीक्षणहरू Ubuntu 2255 चलिरहेको Intel® Xeon® W-20.04 मा सञ्चालन गरिन्छ। डिस्क परीक्षण गर्न, sysbench 1.0.18 प्रयोग गरिन्छ। डिस्कहरूमा ext4 को रूपमा ढाँचा गरिएको एकल विभाजन छ। परीक्षणको लागि तयारी 100 GB फाइलहरू सिर्जना गर्न हो:

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

चलिरहेको परीक्षणहरू:

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

परीक्षणको नतिजा तालिकामा प्रस्तुत गरिएको छ।

टेस्ट गर्नुहोस्
Intel® S4500
Samsung 970 EVO+

fsync बिना पढ्नुहोस्, MiB/s
5734.89
9028.86

Fsync, MiB/s बिना लेख्नुहोस्
3823.26
6019.24

Fsync, MiB/s को साथ पढ्दै
37.76
3.27

Fsync, MiB/s संग रेकर्डिङ
25.17
2.18

यो हेर्न सजिलो छ कि क्लाइन्ट खण्डबाट NVMe ले आत्मविश्वासका साथ नेतृत्व गर्दछ जब अपरेटिङ सिस्टमले डिस्कसँग कसरी काम गर्ने निर्णय गर्छ, र fsync प्रयोग गर्दा हराउँछ। यसले दुईवटा प्रश्न खडा गर्छ:

1. किन पढ्ने गति fsync बिना परीक्षणमा लिङ्कको भौतिक ब्यान्डविथ भन्दा बढी हुन्छ?
2. ठूलो संख्यामा fsync अनुरोधहरू ह्यान्डल गर्न सर्भर खण्ड SSD किन राम्रो छ?

पहिलो प्रश्नको जवाफ सरल छ: sysbench ले शून्य-भरिएका फाइलहरू उत्पन्न गर्दछ। यसरी, परीक्षण शून्य को 100 गीगाबाइट भन्दा बढी गरिएको थियो। डेटा धेरै समान र अनुमानित भएकोले, विभिन्न OS अप्टिमाइजेसनहरू खेलमा आउँछन्, र तिनीहरूले महत्त्वपूर्ण रूपमा कार्यान्वयनलाई गति दिन्छ।

यदि तपाइँ sysbench को सबै परिणामहरू प्रश्न गर्नुहुन्छ भने, तपाइँ fio प्रयोग गर्न सक्नुहुन्छ।

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

टेस्ट गर्नुहोस्
Intel® S4500
Samsung 970 EVO+

fsync बिना पढ्नुहोस्, MiB/s
45.5
178

Fsync, MiB/s बिना लेख्नुहोस्
30.4
119

Fsync, MiB/s को साथ पढ्दै
32.6
20.9

Fsync, MiB/s संग रेकर्डिङ
21.7
13.9

Fsync प्रयोग गर्दा NVMe मा प्रदर्शन घट्ने प्रवृत्ति स्पष्ट रूपमा देखिन्छ। तपाईं दोस्रो प्रश्नमा जान सक्नुहुन्छ।

अनुकूलन वा ब्लफ

पहिले हामीले डेटा बफरमा भण्डारण गरिएको छ भनेर भन्यौं, तर कुनमा निर्दिष्ट गरेन, किनकि यो महत्त्वपूर्ण थिएन। अहिले पनि हामी अपरेटिङ सिस्टमका जटिलताहरू र दुई सामान्य प्रकारका बफरहरू एकल गर्ने छैनौं:

• कार्यक्रम;
• हार्डवेयर।

सफ्टवेयर बफरले अपरेटिङ सिस्टममा रहेका बफरहरूलाई जनाउँछ, र हार्डवेयर बफरले डिस्क नियन्त्रकको अस्थिर मेमोरीलाई जनाउँछ। fsync प्रणाली कलले यसको बफरबाट मुख्य भण्डारणमा डाटा लेख्नको लागि ड्राइभमा आदेश पठाउँछ, तर यो आदेशको सही कार्यान्वयन नियन्त्रण गर्ने कुनै तरिका छैन।

एसएसडीले राम्रो प्रदर्शन गर्ने हुनाले, दुई धारणाहरू बनाउन सकिन्छ:

• डिस्क समान योजनाको लोडको लागि डिजाइन गरिएको छ;
• डिस्कले "ब्लफ" गर्छ र आदेशलाई बेवास्ता गर्छ।

यदि तपाइँ पावर विफलता संग परीक्षण गर्नुहुन्छ भने ड्राइभको बेईमान व्यवहार देख्न सकिन्छ। तपाइँ यसलाई स्क्रिप्टको साथ जाँच गर्न सक्नुहुन्छ। diskchecker.pl, त्यो थियो सिर्जना गरियो 2005 वर्षमा।

यो स्क्रिप्टलाई दुई भौतिक मेसिनहरू चाहिन्छ - "सर्भर" र "क्लायन्ट"। क्लाइन्टले परीक्षण अन्तर्गत ड्राइभमा थोरै मात्रामा डाटा लेख्छ, fsync कल गर्छ, र के लेखिएको थियो भन्ने बारे सर्भर जानकारी पठाउँदछ।

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

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

स्क्रिप्ट चलाउन पछि, "ग्राहक" लाई डि-एनर्जाइज गर्न आवश्यक छ र धेरै मिनेटको लागि शक्ति फिर्ता नगर्नुहोस्। यो बिजुलीबाट परीक्षण विषय विच्छेदन गर्न महत्त्वपूर्ण छ, र कडा शटडाउन मात्र होइन। केहि समय पछि, सर्भर जडान र OS मा लोड गर्न सकिन्छ। OS बुट गरेपछि, तपाईंले फेरि सुरु गर्न आवश्यक छ diskchecker.plतर तर्क संग प्रमाणित गर्नुहोस्.

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

जाँचको अन्त्यमा, तपाईंले त्रुटिहरूको संख्या देख्नुहुनेछ। यदि तिनीहरू 0 छन् भने, डिस्कले परीक्षण पास गर्यो। डिस्कको लागि सफल परिस्थितिहरूको संयोजन बहिष्कार गर्न, प्रयोग धेरै पटक दोहोर्याउन सकिन्छ।

हाम्रो S4500 ले पावर हानि त्रुटिहरू देखाएको छैन, जसको मतलब यो धेरै fsync कलहरूको साथ लोडको लागि तयार छ।

निष्कर्षमा

डिस्क वा सम्पूर्ण तयार कन्फिगरेसनहरू छनौट गर्दा, तपाईंले समाधान गर्न आवश्यक कार्यहरूको विशिष्टताहरूलाई ध्यानमा राख्नु पर्छ। पहिलो नजरमा, यो स्पष्ट देखिन्छ कि NVMe, त्यो हो, PCIe इन्टरफेसको साथ एक SSD, "क्लासिक" SATA SSD भन्दा छिटो छ। यद्यपि, हामीले आज बुझेका छौं, विशेष परिस्थितिहरूमा र निश्चित कार्यहरूमा यो मामला नहुन सक्छ।

IaaS प्रदायकबाट भाडामा लिँदा तपाइँ कसरी सर्भर घटकहरू परीक्षण गर्नुहुन्छ?
हामी तपाईलाई कमेन्टमा पर्खिरहेका छौं।

स्रोत: www.habr.com