מדוע ה-NVMe שלי איטי יותר מ-SSD?

במאמר זה, נבחן כמה מהניואנסים של תת-מערכת ה-I/O והשפעתם על הביצועים.

לפני שבועיים נתקלתי בשאלה מדוע NVMe בשרת אחד איטי יותר מ-SATA בשרת אחר. הסתכלתי על המאפיינים של השרתים והבנתי שזו שאלת טריק: NVMe היה מקטע המשתמש, ו-SSD היה מקטע השרתים.

ברור שלא נכון להשוות בין מוצרים ממגזרים שונים בסביבות שונות, אבל זו לא תשובה טכנית ממצה. נלמד את היסודות, נערוך ניסויים וניתן תשובה לשאלה שנשאלה.

מהו fsync והיכן משתמשים בו

כדי להאיץ את העבודה עם כוננים, הנתונים מאוחסנים, כלומר מאוחסנים בזיכרון הפכפך עד שתתקיים הזדמנות נוחה לשמור את תוכן המאגר בכונן. קריטריוני ההזדמנות נקבעים על פי מערכת ההפעלה ומאפייני הכונן. במקרה של הפסקת חשמל, כל הנתונים במאגר יאבדו.

ישנן מספר משימות שבהן צריך להיות בטוח שהשינויים בקובץ נכתבים לכונן, ואינם טמונים במאגר ביניים. ניתן לקבל הבטחה זו באמצעות קריאת מערכת fsync תואמת POSIX. קריאת 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;
}

הערות מסבירות היטב את רצף הפעולות בתוכנית. הטקסט "התשובה לשאלה העיקרית של החיים, היקום וכל זה" יוחזק על ידי מערכת ההפעלה, ואם תפעיל מחדש את השרת על ידי לחיצה על כפתור ה-Reset במהלך "חישובים", הקובץ יהיה ריק. בדוגמה שלנו, אובדן טקסט אינו בעיה, ולכן אין צורך ב-fsync. מאגרי מידע אינם שותפים לאופטימיות הזו.

מסדי נתונים הם תוכנות מורכבות שעובדות עם קבצים רבים בו זמנית, ולכן הם רוצים להיות בטוחים שהנתונים שהם כותבים יאוחסנו בכונן, שכן עקביות הנתונים בתוך מסד הנתונים תלויה בכך. מאגרי המידע מיועדים לתעד את כל העסקאות שהושלמו ולהיות מוכנים להפסקת חשמל בכל רגע. התנהגות זו מחייבת אותך להשתמש ב-fsync כל הזמן בכמויות גדולות.

מה משפיע על השימוש התכוף ב-fsync

עם קלט/פלט רגיל, מערכת ההפעלה מנסה לייעל את תקשורת הדיסקים, שכן כוננים חיצוניים הם האיטיים ביותר בהיררכיית הזיכרון. לכן, מערכת ההפעלה מנסה לכתוב כמה שיותר נתונים בגישה אחת לכונן.

בואו נדגים את ההשפעה של שימוש ב-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.

הבדיקות מתבצעות על Intel® Xeon® W-2255 עם אובונטו 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. מדוע מקטע שרת 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
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

המגמה לירידה בביצועים ב-NVMe בעת שימוש ב-fsync נראית בבירור. אתה יכול לעבור לשאלה השנייה.

אופטימיזציה או בלוף

קודם אמרנו שהנתונים מאוחסנים במאגר, אבל לא ציינו באיזה מהם, כי זה לא היה חשוב. גם כעת לא נעמיק במורכבות של מערכות הפעלה ונפרט שני סוגים כלליים של מאגרים:

• תכנית;
• חוּמרָה.

מאגר התוכנה מתייחס למאגרים שנמצאים במערכת ההפעלה, ומאגר החומרה מתייחס לזיכרון הנדיף של בקר הדיסק. קריאת המערכת fsync שולחת פקודה לכונן לכתוב נתונים מהמאגר שלו לאחסון הראשי, אך אין לה דרך לשלוט בביצוע הנכון של הפקודה.

מכיוון שה-SSD מתפקד טוב יותר, ניתן להניח שתי הנחות:

• הדיסק מיועד לעומס של תוכנית דומה;
• הדיסק "מבלף" ומתעלם מהפקודה.

ניתן להבחין בהתנהגות לא ישרה של הכונן אם אתה מבצע בדיקה עם הפסקת חשמל. אתה יכול לבדוק את זה עם סקריפט. 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, כלומר SSD עם ממשק PCIe, מהיר יותר מ-SATA SSD "קלאסי". עם זאת, כפי שהבנו היום, בתנאים ספציפיים ועם משימות מסוימות זה לא יכול להיות המקרה.

כיצד בודקים רכיבי שרת כאשר שוכרים מספק IaaS?
מחכים לכם בתגובות.

מקור: www.habr.com