የእኔ NVMe ከኤስኤስዲ ቀርፋፋ የሆነው ለምንድነው?

በዚህ ጽሑፍ ውስጥ የ I / O ንዑስ ስርዓትን እና በአፈፃፀም ላይ ያላቸውን ተፅእኖ አንዳንድ ልዩነቶችን እንመለከታለን።

ከጥቂት ሳምንታት በፊት NVMe በአንድ አገልጋይ ላይ ለምን በሌላ ከSATA ቀርፋፋ የሆነ ጥያቄ አጋጠመኝ። የአገልጋዮቹን ባህሪያት ተመለከትኩ እና ይህ ብልሃተኛ ጥያቄ መሆኑን ተገነዘብኩ፡ NVMe ከተጠቃሚው ክፍል ነበር፣ እና ኤስኤስዲ ከአገልጋዩ ክፍል ነው።

በግልጽ ለማየት እንደሚቻለው በተለያዩ አከባቢዎች ውስጥ ከተለያዩ ክፍሎች የተውጣጡ ምርቶችን ማወዳደር ትክክል አይደለም, ነገር ግን ይህ የተሟላ ቴክኒካዊ መልስ አይደለም. መሰረታዊ ነገሮችን እናጠናለን, ሙከራዎችን እናደርጋለን እና ለቀረበው ጥያቄ መልስ እንሰጣለን.

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 የመጠቀምን ተፅእኖ በተወሰነ ምሳሌ እናሳይ። እንደ የሙከራ ርዕሰ ጉዳይ የሚከተሉት ኤስኤስዲዎች አሉን

• Intel® DC SSD S4500 480 ጂቢ፣ በ SATA 3.2፣ 6 Gb/s የተገናኘ;
• ሳምሰንግ 970 EVO Plus 500GB፣ በ PCIe 3.0 x4፣ ~31Gbps የተገናኘ።

ሙከራዎች የሚካሄዱት ኡቡንቱ 2255 በሚያሄድ ኢንቴል® 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

የፈተና ውጤቶቹ በሰንጠረዥ ውስጥ ቀርበዋል.

ሙከራ
Intel® 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. ለምንድነው የአገልጋይ ክፍል SSD ብዙ ቁጥር ያላቸውን የfsync ጥያቄዎችን በማስተናገድ የተሻለ የሆነው?

ለመጀመሪያው ጥያቄ መልሱ ቀላል ነው-sysbench በዜሮ የተሞሉ ፋይሎችን ያመነጫል. ስለዚህም ፈተናው የተካሄደው ከ100 ጊጋባይት በላይ ዜሮዎች ነው። ውሂቡ በጣም ተመሳሳይ እና ሊተነበይ የሚችል ስለሆነ የተለያዩ የስርዓተ ክወና ማሻሻያዎች ወደ ጨዋታ ይመጣሉ, እና አፈፃፀሙን በከፍተኛ ሁኔታ ያፋጥነዋል.

ሁሉንም የ 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 ኢቮ +

ያለ 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 በይነገጽ ጋር ከ"ክላሲክ" SATA SSD ፈጣን እንደሆነ ግልጽ ይመስላል። ሆኖም ግን, ዛሬ እንደተረዳነው, በተወሰኑ ሁኔታዎች እና በተወሰኑ ተግባራት ይህ ላይሆን ይችላል.

ከ IaaS አቅራቢ ሲከራዩ የአገልጋይ ክፍሎችን እንዴት ይሞክራሉ?
በአስተያየቶቹ ውስጥ እርስዎን እየጠበቅን ነው.

ምንጭ: hab.com