શા માટે મારું 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
સેમસંગ 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
સેમસંગ 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 સિસ્ટમ કૉલ તેના બફરમાંથી મુખ્ય સ્ટોરેજ પર ડેટા લખવા માટે ડ્રાઇવને આદેશ મોકલે છે, પરંતુ આદેશ યોગ્ય રીતે ચલાવવામાં આવ્યો છે તે ચકાસવાની કોઈ રીત નથી.

SSD શ્રેષ્ઠ પરિણામો દર્શાવે છે, તેથી બે ધારણાઓ કરી શકાય છે:

• ડિસ્ક સમાન લોડ માટે રચાયેલ છે;
• ડિસ્ક "બ્લફ્સ" કરે છે અને આદેશને અવગણે છે.

જો તમે પાવર લોસ ટેસ્ટ કરાવો છો તો ડ્રાઈવનું અપ્રમાણિક વર્તન જોઈ શકાય છે. તમે આને સ્ક્રિપ્ટ વડે ચકાસી શકો છો 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