माझे NVMe SSD पेक्षा कमी का आहे?

या लेखात आपण I/O उपप्रणालीच्या काही बारकावे आणि कार्यक्षमतेवर त्यांचा प्रभाव पाहू.

काही आठवड्यांपूर्वी मला एका सर्व्हरवरील NVMe दुसर्‍यावरील SATA पेक्षा कमी का होते या प्रश्नाचा सामना करावा लागला. मी सर्व्हरची वैशिष्ट्ये पाहिली आणि लक्षात आले की हा एक अवघड प्रश्न आहे: NVMe वापरकर्ता विभागातील होता आणि SSD सर्व्हर विभागातील होता.

अर्थात, वेगवेगळ्या वातावरणातील वेगवेगळ्या विभागातील उत्पादनांची तुलना करणे योग्य नाही, परंतु हे संपूर्ण तांत्रिक उत्तर नाही. चला मूलभूत गोष्टींचा अभ्यास करू, प्रयोग करू आणि विचारलेल्या प्रश्नाचे उत्तर देऊ.

fsync म्हणजे काय आणि ते कुठे वापरले जाते?

ड्राइव्हसह कार्य गतिमान करण्यासाठी, डेटा बफर केला जातो, म्हणजेच, ड्राइव्हवर बफरची सामग्री जतन करण्याची सोयीस्कर संधी येईपर्यंत अस्थिर मेमरीमध्ये संग्रहित केली जाते. "संधी" साठी निकष ऑपरेटिंग सिस्टम आणि ड्राइव्हच्या वैशिष्ट्यांद्वारे निर्धारित केले जातात. पॉवर अयशस्वी झाल्यास, बफरमधील सर्व डेटा गमावला जाईल.

अशी अनेक कार्ये आहेत ज्यात तुम्हाला खात्री असणे आवश्यक आहे की फाइलमधील बदल ड्राइव्हवर लिहिलेले आहेत आणि इंटरमीडिएट बफरमध्ये नाहीत. हे आश्वासन POSIX-अनुरूप 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 वापरण्याचा प्रभाव दाखवू. आमच्याकडे चाचणी ड्राइव्ह म्हणून खालील SSDs आहेत:

• Intel® DC SSD S4500 480 GB, SATA 3.2, 6 Gbit/s द्वारे जोडलेले;
• Samsung 970 EVO Plus 500GB, PCIe 3.0 x4, ~31 Gbit/s द्वारे कनेक्ट केलेले.

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>

स्क्रिप्ट चालवल्यानंतर, आपण "क्लायंट" ला पॉवर बंद करणे आवश्यक आहे आणि काही मिनिटांसाठी पॉवर परत करू नका. विजेपासून चाचणी घेतलेल्या व्यक्तीला डिस्कनेक्ट करणे महत्वाचे आहे, आणि फक्त हार्ड शटडाउन करू नका. काही काळानंतर, सर्व्हर कनेक्ट केला जाऊ शकतो आणि ओएसमध्ये लोड केला जाऊ शकतो. ओएस लोड केल्यानंतर तुम्हाला ते पुन्हा सुरू करावे लागेल diskchecker.pl, पण वादासह सत्यापित करा.

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

तपासणीच्या शेवटी तुम्हाला त्रुटींची संख्या दिसेल. 0 असल्यास, डिस्कने चाचणी उत्तीर्ण केली आहे. डिस्कसाठी भाग्यवान योगायोग वगळण्यासाठी, प्रयोग अनेक वेळा पुनरावृत्ती होऊ शकतो.

जेव्हा वीज गेली तेव्हा आमच्या S4500 ने कोणतीही त्रुटी दाखवली नाही, याचा अर्थ ते भरपूर fsync कॉलसह वर्कलोडसाठी तयार आहे.

निष्कर्ष

डिस्क्स किंवा संपूर्ण रेडीमेड कॉन्फिगरेशन निवडताना, आपण ज्या समस्यांचे निराकरण करणे आवश्यक आहे त्यांचे तपशील लक्षात ठेवावे. पहिल्या दृष्टीक्षेपात, हे स्पष्ट दिसते की NVMe, म्हणजे, PCIe इंटरफेससह एक SSD, "क्लासिक" SATA SSD पेक्षा वेगवान आहे. तथापि, आज आपण शिकलो आहोत, विशिष्ट परिस्थितीत आणि विशिष्ट कार्यांसह असे होऊ शकत नाही.

IaaS प्रदात्याकडून भाड्याने घेताना तुम्ही सर्व्हर घटकांची चाचणी कशी करता?
आम्ही टिप्पण्यांमध्ये तुमची वाट पाहत आहोत.

स्त्रोत: www.habr.com