وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

انتخاب NVMe برای سرور اختصاصی؛ IOPS و تأخیر را چطور مقایسه کنیم؟

آموزش مقایسه عملکرد NVMe، تفسیر IOPS و p99 و اجرای آزمایش فقط‌خواندنی fio روی فایل نمونه.

انتشار:
توسط تیم فنی نت‌آرام
۶ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله انتخاب NVMe برای سرور اختصاصی؛ IOPS و تأخیر را چطور مقایسه کنیم؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
دو سرور اختصاصی ایران هر دو دیسک NVMe دارند، اما یکی برای پایگاه داده شما پاسخ سریع‌تری می‌دهد. دلیل این است که نام NVMe و یک عدد سرعت ترتیبی، همه داستان را نمی‌گویند. تعداد عملیات کوچک، زمان پاسخ هر درخواست، دوام نوشتن و وضعیت RAID یا شبکه ذخیره‌سازی هم روی تجربه واقعی اثر دارند.
IOPS یعنی تعداد عملیات ورودی و خروجی در ثانیه؛ تأخیر یعنی هر عملیات چقدر منتظر پاسخ می‌ماند. خودرویی را تصور کنید که در یک ساعت بسته‌های زیادی حمل می‌کند، اما ممکن است تحویل بعضی بسته‌ها دیر شود. برای فروشگاه یا پایگاه داده، تأخیر درخواست‌های کند هم مهم است. در ادامه یاد می‌گیریم اعداد را در شرایط یکسان بخوانیم و با آزمایش محدود، انتخاب آگاهانه‌تری انجام دهیم.

۱. ابتدا مشخص کنید برنامه چه نوع کاری انجام می‌دهد

پایگاه داده معمولاً تعداد زیادی خواندن و نوشتن کوچک و پراکنده دارد. انتقال یک فایل ویدیویی بزرگ بیشتر شبیه خواندن یا نوشتن ترتیبی است. در عمل هر دو نوع بار ممکن است وجود داشته باشد. اندازه داده‌ها، تعداد درخواست هم‌زمان، نسبت خواندن به نوشتن و ساعات اوج را یادداشت کنید؛ مقایسه 4KiB تصادفی با 1MiB ترتیبی بدون دانستن این تفاوت گمراه‌کننده است.
اگر سرویس فعال دارید، در لینوکس و با ابزار sysstat می‌توانید چند نمونه از بار فعلی بگیرید:
کد / دستورdate -Is lsblk -o NAME,TYPE,SIZE,MOUNTPOINTS iostat -x 1 5
نام دیسک منطقی یا فایل‌سیستم مرتبط را از خروجی پیدا کنید. در iostat نرخ خواندن و نوشتن، میانگین زمان انتظار await و صف را در چند بازه نگاه کنید. ستون‌ها در نسخه‌های مختلف متفاوت‌اند. این اعداد از نگاه سیستم‌عامل هستند و اگر دیسک پشت RAID، مجازی‌ساز یا شبکه باشد الزاماً رفتار یک NVMe فیزیکی را جدا نشان نمی‌دهند. یک نمونه کوتاه در ساعت خلوت تصویر کامل نیست.

۲. از ارائه‌دهنده چه اطلاعاتی بخواهیم؟

مدل و ظرفیت دیسک، نوع و تعداد درایوها، آرایش RAID، رابط اتصال، سهم منابع مشترک و سیاست جایگزینی دیسک را بپرسید. برای مقایسه نتایج عملکرد، اندازه بلوک، نسبت خواندن و نوشتن، تعداد درخواست هم‌زمان یا queue depth، مدت آزمون و وضعیت گرم یا پر بودن دیسک باید مشخص باشد. رقم تبلیغاتیِ خواندن ترتیبی برای کار واقعی شما تضمین سرعت پایگاه داده نیست.
برای بار نوشتنی، دوام یا endurance و شرایط گارانتی را جدا بررسی کنید. اگر یک سرویس به افزونگی نیاز دارد، تک‌دیسک سریع جایگزین RAID مناسب و بکاپ جداگانه نیست. سرعت NVMe نیز مشکل ظرفیت ناکافی RAM، پرس‌وجوی بد یا تأخیر شبکه را به‌تنهایی حل نمی‌کند.

۳. IOPS و تأخیر صدکی را ساده بخوانیم

فرض کنید یک نتیجه ۱۰ هزار عملیات در ثانیه با بلوک ۴KiB نشان می‌دهد. حجم تقریبی این عملیات برابر ۳۹MiB در ثانیه است، نه هزاران مگابایت؛ اندازه هر درخواست تعیین‌کننده است. اگر نتیجه دوم ۱۰ هزار IOPS با بلوک بزرگ‌تری دارد، حجم عبوری آن متفاوت خواهد بود. این اعداد فرضی‌اند و قول کارایی هیچ سرویسی نیستند.
میانگین تأخیر فقط میانگین را نشان می‌دهد. صدک ۹۹ یا p99 می‌گوید ۹۹ درصد درخواست‌های اندازه‌گیری‌شده در آن بازه در این زمان یا کمتر تمام شده‌اند؛ یک درصد کندتر بوده‌اند. برای سایتی که تعداد زیادی درخواست دارد، همان بخش کند هم روی کاربران اثر می‌گذارد. میانگین و p99 را همراه IOPS، مدت و بار واقعی ببینید؛ p99 یک آزمون کوتاه تضمین رفتار تمام روز نیست.

۴. یک آزمایش فقط‌خواندنی و محدود آماده کنید

آزمایش دیسک حتی اگر نوشتنی نباشد می‌تواند سرویس زنده را کند کند. آن را در سرور آزمایشی یا پنجره نگه‌داری انجام دهید و از پیش با مسئول سرویس هماهنگ کنید. از یک فایل واقعی و غیرمحرمانه که از قبل روی فایل‌سیستم مورد آزمایش وجود دارد و حداقل یک GiB داده واقعی دارد استفاده کنید؛ فایل sparse یا از پیش تخصیص‌یافته بدون داده واقعی ممکن است نتیجه گمراه‌کننده بدهد. فایل پایگاه داده فعال یا دستگاه خام را هدف نگیرید.
برای نمونه فرض می‌کنیم فایل آزمایشی شما /mnt/bench/read-sample.bin است. نام و مسیر واقعی را جایگزین کنید و قبل از اجرا مطمئن شوید فایل متعلق به آزمون است:
کد / دستورfindmnt -T /mnt/bench/read-sample.bin stat -c '%n %s bytes' /mnt/bench/read-sample.bin fio --version
دستور اول مشخص می‌کند فایل روی کدام mount است، دومی اندازه را به بایت نشان می‌دهد و سومی نسخه ابزار Flexible I/O Tester را می‌خواند. اگر ابزار نصب نیست، بسته رسمی fio را از مخزن معتبر توزیع نصب کنید. بعضی برنامه‌های نامرتبط هم نام fio دارند؛ خروجی نسخه و راهنمای همان ابزار را بررسی کنید. نتیجه آزمایش یک فایل روی RAID یا فایل‌سیستم، نتیجه کل آن مسیر است نه مشخصات تضمینی یک دیسک تکی.

۵. خواندن تصادفی را در دو سطح صف بسنجید

در همان محیط آزمایش، مسیر نمونه را با فایل موجود خود جایگزین کنید:
کد / دستورfio --readonly --name=read-q1 --filename=/mnt/bench/read-sample.bin --rw=randread --bs=4k --size=1G --ioengine=libaio --direct=1 --iodepth=1 --time_based --runtime=30 --group_reporting
گزینه --readonly محافظ اضافه در برابر کار نوشتنی و trim است، randread خواندن تصادفی، bs=4k اندازه هر درخواست و iodepth=1 یک درخواست در صف را مشخص می‌کند. آزمون ۳۰ ثانیه اجرا می‌شود و direct=1 تلاش می‌کند کش معمول فایل سیستم را دور بزند؛ پشتیبانی آن به سیستم‌فایل و تنظیم محیط وابسته است. خطای عدم پشتیبانی یا نرسیدن به depth در خروجی را جدی بگیرید. راهنمای ابزار fio معنی دقیق گزینه‌ها را توضیح می‌دهد.
پس از پایان و زمانی که سیستم به وضعیت عادی برگشت، در صورت مجازبودن همین آزمون را با صف بیشتر اجرا کنید:
کد / دستورfio --readonly --name=read-q16 --filename=/mnt/bench/read-sample.bin --rw=randread --bs=4k --size=1G --ioengine=libaio --direct=1 --iodepth=16 --time_based --runtime=30 --group_reporting
در خروجی بخش read، مقدار IOPS و clat percentiles را برای هر دو اجرا یادداشت کنید. وقتی صف بیشتر می‌شود ممکن است تعداد عملیات بالا برود اما تأخیر هر درخواست هم افزایش یابد. توزیع عمق صف در خروجی نشان می‌دهد آیا عمق مورد درخواست واقعاً حاصل شده است یا نه. اگر فایل یا مسیر اشتباه است، آزمون را متوقف کنید؛ گزینه فقط‌خواندنی مجوز فشارآوردن به سرویس زنده نیست.

۶. نتیجه را برای تصمیم خود به کار ببرید

دو سرور را با اندازه فایل، block size، عمق صف، مدت، بار هم‌زمان و چیدمان ذخیره‌سازی یکسان مقایسه کنید. شرایط محیط را کنار عدد بنویسید. یک نتیجه خواندن ۳۰ ثانیه‌ای، سرعت نوشتن پایدار یا دوام دیسک را نشان نمی‌دهد. برای بررسی نوشتن، فقط در محیط خالی و اختصاصی با فایل یا دیسک تست مشخص، نسخه پشتیبان و دستور طراحی‌شده برای همان هدف اقدام کنید؛ دستورهای نوشتن تصادفی روی مسیر ناشناخته ممکن است داده را از بین ببرند.
اگر IOPS خوب است ولی سایت کند می‌ماند، p99، تعداد اتصال‌ها، RAM، زمان پرس‌وجو و شبکه را نیز بررسی کنید. اگر تأخیر هم‌زمان با عملیات کنترلر بالا می‌رود، راهنمای کندی هنگام Patrol Read به تفکیک آن کمک می‌کند. انتخاب خوب سروری است که در بار نزدیک به نیاز شما و با ظرفیت، افزونگی و پشتیبانی مناسب پاسخ قابل قبول بدهد، نه صرفاً بزرگ‌ترین عدد روی کاغذ.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام