मेरा NVMe SSD से धीमा क्यों है?

इस लेख में, हम I/O सबसिस्टम की कुछ बारीकियों और प्रदर्शन पर उनके प्रभाव को देखेंगे।

कुछ हफ़्ते पहले मेरे सामने यह सवाल आया कि एक सर्वर पर NVMe दूसरे सर्वर पर SATA की तुलना में धीमा क्यों है। मैंने सर्वरों की विशेषताओं को देखा और महसूस किया कि यह एक ट्रिकी प्रश्न था: एनवीएमई उपयोगकर्ता खंड से था, और एसएसडी सर्वर खंड से था।

जाहिर है, अलग-अलग परिवेश में अलग-अलग खंडों के उत्पादों की तुलना करना सही नहीं है, लेकिन यह कोई संपूर्ण तकनीकी उत्तर नहीं है। हम बुनियादी बातों का अध्ययन करेंगे, प्रयोग करेंगे और पूछे गए प्रश्न का उत्तर देंगे।

fsync क्या है और इसका उपयोग कहाँ किया जाता है

ड्राइव के साथ काम को तेज़ करने के लिए, डेटा को बफ़र किया जाता है, यानी, अस्थिर मेमोरी में संग्रहीत किया जाता है जब तक कि बफ़र की सामग्री को ड्राइव में सहेजने का सुविधाजनक अवसर न मिल जाए। अवसर मानदंड ऑपरेटिंग सिस्टम और ड्राइव विशेषताओं द्वारा निर्धारित किए जाते हैं। बिजली गुल होने की स्थिति में, बफ़र का सारा डेटा नष्ट हो जाएगा।

ऐसे कई कार्य हैं जिनमें आपको यह सुनिश्चित करने की आवश्यकता है कि फ़ाइल में परिवर्तन ड्राइव पर लिखे गए हैं, और मध्यवर्ती बफर में नहीं हैं। यह आश्वासन POSIX-संगत fsync सिस्टम कॉल का उपयोग करके प्राप्त किया जा सकता है। Fsync कॉल बफ़र से ड्राइव पर लिखने के लिए बाध्य करता है।

आइए एक संक्षिप्त सी प्रोग्राम के रूप में एक कृत्रिम उदाहरण के साथ बफ़र्स के प्रभाव को प्रदर्शित करें।

#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 के माध्यम से कनेक्टेड;
• सैमसंग 970 ईवीओ प्लस 500 जीबी, पीसीआईई 3.0 x4, ~31 जीबीपीएस के माध्यम से कनेक्टेड।

परीक्षण Ubuntu 2255 पर चलने वाले Intel® Xeon® W-20.04 पर आयोजित किए जाते हैं। डिस्क का परीक्षण करने के लिए sysbench 1.0.18 का उपयोग किया जाता है। डिस्क में ext4 के रूप में स्वरूपित एक एकल विभाजन है। परीक्षण की तैयारी के लिए 100 जीबी फ़ाइलें बनाना है:

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

परीक्षण के परिणाम तालिका में प्रस्तुत किए गए हैं।

परीक्षण
इंटेल® S4500
सैमसंग 970 ईवीओ+

बिना 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 गीगाबाइट से अधिक शून्य पर किया गया। चूंकि डेटा बहुत समान और पूर्वानुमानित है, इसलिए विभिन्न ओएस अनुकूलन चलन में आते हैं, और वे निष्पादन में काफी तेजी लाते हैं।

यदि आप sysbench के सभी परिणामों पर सवाल उठाते हैं, तो आप फियो का उपयोग कर सकते हैं।

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

परीक्षण
इंटेल® S4500
सैमसंग 970 ईवीओ+

बिना 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 सिस्टम कॉल अपने बफ़र से मुख्य स्टोरेज में डेटा लिखने के लिए ड्राइव को एक कमांड भेजता है, लेकिन इसमें कमांड के सही निष्पादन को नियंत्रित करने का कोई तरीका नहीं है।

चूँकि SSD बेहतर प्रदर्शन करता है, इसलिए दो धारणाएँ बनाई जा सकती हैं:

• डिस्क को समान योजना के लोड के लिए डिज़ाइन किया गया है;
• डिस्क "धोखा" देती है और आदेश को अनदेखा कर देती है।

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

इस स्क्रिप्ट के लिए दो भौतिक मशीनों की आवश्यकता है - "सर्वर" और "क्लाइंट"। क्लाइंट परीक्षण के तहत ड्राइव पर थोड़ी मात्रा में डेटा लिखता है, fsync को कॉल करता है, और जो लिखा गया था उसके बारे में सर्वर को जानकारी भेजता है।

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

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

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

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

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

हमारे S4500 में बिजली हानि की कोई त्रुटि नहीं दिखी, जिसका अर्थ है कि यह बहुत सारी fsync कॉल के साथ लोड के लिए तैयार है।

निष्कर्ष

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

IaaS प्रदाता से किराये पर लेते समय आप सर्वर घटकों का परीक्षण कैसे करते हैं?
हम टिप्पणियों में आपकी प्रतीक्षा कर रहे हैं।

स्रोत: www.habr.com