یک آزمون ذخیره‌سازی مفید، اندازه عملیات، الگوی دسترسی، همزمانی و الزامات دوام را با برنامه تطبیق می‌دهد. شرایط آزمون و توزیع تأخیر را ثبت کنید، سپس نتیجه را با اندازه‌گیری‌های برنامه تأیید کنید.
با یک پرسش ذخیره‌سازی شروع کنید، نه با یک امتیاز
پیش از اجرای یک محک، تصمیم بگیرید چه چیزی را باید بدانید. ممکن است در حال بررسی کندی ثبت‌های پایگاه داده، توان عبوری توزیع فایل یا فرآیند ساخت‌ای باشید که فایل‌های کوچک بسیاری ایجاد می‌کند. این بارهای کاری از دیسک نمی‌خواهند کار یکسانی انجام دهد. یک کپی ترتیبی بزرگ می‌تواند چشمگیر به نظر برسد، در حالی که چیز کمی درباره تأخیر تجربه‌شده توسط سرویسی که خواندن‌های تصادفی کوچک انجام می‌دهد، بگوید.
NVMe برای رسانه‌های غیرفرار و ورودی/خروجی موازی کارآمد طراحی شده است، اما نام پروتکل آن همه بخش‌های یک مسیر ذخیره‌سازی میزبانی‌شده را توصیف نمی‌کند. مجازی‌سازی، سیستم فایل، رقابت منابع و برنامه همچنان مهم هستند. یک فرضیه آزمون بنویسید، مثلاً اینکه آیا تأخیر ذخیره‌سازی یک عملیات خاص را کند می‌کند، نه اینکه بخواهید عددی تولید کنید که ثابت کند کل سرور سریع است.
بار کاری را با عبارات قابل بازتولید توصیف کنید
اندازه عملیات، الگوی ترتیبی یا تصادفی، ترکیب خواندن به نوشتن، تعداد کارها و عمق صف را ثبت کنید. اندازه مجموعه داده و مدت آزمون را نیز شامل کنید. مستندات fio این کنترل‌های بار کاری و موتورهای ورودی/خروجی موجود را توضیح می‌دهد. ممکن است عمق موردنظر توسط هر موتور یا تنظیمی محقق نشود، بنابراین رفتار گزارش‌شده را همانند پیکربندی درخواستی خود بخوانید.
یک نسخه از توضیح آزمون را در کنار نتیجه نگه دارید. سیستم‌عامل، سیستم فایل، گزینه‌های mount، فعالیت سرویس و ظرفیت موجود را یادداشت کنید. اگر پیکربندی‌ها را مقایسه می‌کنید، هر بار یک شرط مرتبط را تغییر دهید. آزمونی با الگوی دسترسی یا همزمانی متفاوت را نمی‌توان منصفانه طوری ارائه کرد که گویی فقط رسانه ذخیره‌سازی تغییر کرده است.
| الگوی برنامه | بُعد آزمون برای توصیف | نتیجه برای بررسی |
|---|---|---|
| تحویل فایل بزرگ | خواندن‌های ترتیبی و کلاینت‌های همزمان | توان عبوری پایدار و استفاده از CPU |
| جستجوی رکورد | خواندن‌های تصادفی کوچک و همزمانی نماینده | توزیع تأخیر و عملیات تکمیل‌شده |
| تراکنش بادوام | الزامات نوشتن و همگام‌سازی | تأخیر مرتبط با ثبت، نه فقط سرعت نوشتن بافرشده |
| ساخت یا استخراج | عملیات مختلط فایل‌های کوچک | مدت کار سرتاسری و انتظارهای ورودی/خروجی |
حافظه نهان را کنترل کنید بدون اینکه تظاهر کنید اهمیتی ندارد
مجموعه داده‌ای که در حافظه جا می‌شود ممکن است پس از اولین پاس عمدتاً رفتار حافظه نهان را اندازه بگیرد. اگر برنامه معمولاً از همان حافظه نهان بهره می‌برد، این می‌تواند مفید باشد، اما نباید آن را عملکرد خام دستگاه برچسب زد. آگاهانه انتخاب کنید که آزمون یک مسیر برنامه گرم، یک مجموعه داده سردتر یا یک حالت ورودی/خروجی با هدف کاهش اثر بافر سیستم‌عامل را بررسی کند.
پشتیبانی از ورودی/خروجی مستقیم و هم‌ترازی به پلتفرم و موتور بستگی دارد. همچنین به‌طور خودکار الزامات دوام برنامه را بیان نمی‌کند یا همه حافظه‌های نهان در پشته را حذف نمی‌کند. حالت انتخاب‌شده را به‌روشنی بیان کنید و از مقایسه یک آزمون بافرشده با یک آزمون بدون بافر به‌گونه‌ای که گویی کار یکسانی را نمایندگی می‌کنند، بپرهیزید. در جایی که به تفسیر کمک می‌کند، بازه‌های گرم‌کردن و اندازه‌گیری را جدا نگه دارید.
دنباله‌های تأخیر را در کنار توان عبوری بخوانید
تأخیر میانگین می‌تواند عملیات کندی را که بر درخواست‌های واقعی اثر می‌گذارد پنهان کند. صدک‌های گزارش‌شده و تعداد نمونه‌های پشت آن‌ها را بررسی کنید. یک صدک بالا مرزی را توصیف می‌کند که کسر اعلام‌شده‌ای از عملیات مشاهده‌شده در آن آزمون زیر آن قرار گرفته است؛ این یک تضمین دائمی سرویس نیست. اجراهای کوتاه یا غیرنماینده شواهد محدودی درباره دوره‌های شلوغ تولید ارائه می‌دهند.
عمق صف بالاتر می‌تواند توان عبوری تکمیل‌شده را بهبود دهد و در همان حال زمان انتظار را افزایش دهد. این بده‌بستان ممکن است برای پردازش دسته‌ای مناسب و برای یک سرویس تعاملی مضر باشد. نتایج را در همزمانی‌ای مقایسه کنید که به برنامه شباهت دارد و همزمان CPU و فشار ورودی/خروجی را پایش کنید. پیش از آنکه آزمون برای بار کاری دیگری که محیط را به اشتراک می‌گذارد اختلال غیرضروری ایجاد کند، متوقف شوید.
آزمون را مجاز و غیرمخرب نگه دارید
از یک پوشه آزمون اختصاصی یا یک حجم یک‌بارمصرف آماده‌شده با فضای آزاد کافی و یک برنامه پاک‌سازی صریح استفاده کنید. هرگز یک محک نوشتن را به سمت یک دستگاه خام تأییدنشده یا مجموعه داده تولیدی نشانه نروید. پیش از شروع، هدف و رفتار نوشتن ابزار را بررسی کنید و با یک اجرای محدود آغاز کنید. ورودی/خروجی مصنوعی می‌تواند ظرفیت مصرف کند و حتی وقتی فایل‌های مفید را بازنویسی نمی‌کند، با سرویس‌ها تداخل داشته باشد.
برای یک ارزیابی شبیه تولید، یک بازه نگهداری توافق کنید و پایش برنامه را حفظ کنید. در صورت امکان از داده‌های ساختگی استفاده کنید. از یک آزمون سرعت، قابلیت اطمینان ذخیره‌سازی را استنتاج نکنید: بررسی‌های یکپارچگی، پشتیبان‌گیری و بازیابی وظایف جداگانه‌ای هستند. دستگاهی که یک محک را کامل می‌کند همچنان به یک راهبرد بازیابی برای حذف، خطاهای نرم‌افزاری یا از دست رفتن ماشین نیاز دارد.
حلقه را با شواهد برنامه ببندید
فرض کنید یک سرویس گزارش بخش زیادی از زمان خود را در انتظار خواندن‌های تصادفی می‌گذراند. تیم یک الگوی خواندن نماینده را آزمایش می‌کند، سپس گزارش واقعی را روی داده‌های قابل مقایسه تکرار می‌کند. اگر گزارش بهبود یابد در حالی که سایر کارهایش پایدار می‌مانند، نتیجه از فرضیه ذخیره‌سازی پشتیبانی می‌کند. اگر این‌گونه نباشد، طراحی پرس‌وجو، حافظه یا یک وابستگی دیگر را بررسی کنید، نه اینکه آزمون‌های مصنوعی گسترده‌تر را تکرار کنید.
Pulse NVMe و پیکربندی‌های اختصاصی انتخاب‌شده، ذخیره‌سازی NVMe را در فهرست SwissOctet فهرست می‌کنند. برچسب‌های آن‌ها مشخصات هستند، نه محک‌های منتشرشده برنامه. از یک روش کنترل‌شده برای ارزیابی محیط تحویل‌شده استفاده کنید و شرایط را همراه با یافته‌ها حفظ کنید. تصمیم زمانی قوی‌تر می‌شود که اندازه‌گیری ذخیره‌سازی و نتیجه قابل مشاهده برای کاربر به یک پرسش پاسخ دهند.
چک‌لیست عملی شما.
- ابتدا پرسش برنامه را تعریف کنید.
- الگو، اندازه بلوک، همزمانی و مدت را ثبت کنید.
- فرض‌های حافظه نهان و حالت ورودی/خروجی را بیان کنید.
- صدک‌های تأخیر را همانند توان عبوری بررسی کنید.
- از یک هدف یک‌بارمصرف تأییدشده و بار اولیه محدود استفاده کنید.
- یافته را با یک آزمون برنامه تأیید کنید.
جزئیاتی که اهمیت دارند.
آیا یک کپی ترتیبی برای مقایسه ذخیره‌سازی پایگاه داده کافی است؟+
معمولاً خیر. دسترسی پایگاه داده ممکن است شامل خواندن‌های تصادفی کوچک، نوشتن‌ها و همگام‌سازی باشد. الگوی مرتبط را مدل کنید و برنامه واقعی را تأیید کنید.
آیا ورودی/خروجی مستقیم، نوشتن‌های بادوام را اثبات می‌کند؟+
خیر. بافر کردن و دوام موضوعات جداگانه‌ای هستند. رفتار همگام‌سازی موردنیاز برنامه را تطبیق دهید.
آیا می‌توانم یک آزمون را به‌عنوان سرعت تضمین‌شده یک طرح منتشر کنم؟+
خیر. شرایط و دامنه آن را منتشر کنید. یک نتیجه اندازه‌گیری‌شده از یک اجرا، تضمین سطح سرویس یا عملکرد آینده نیست.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- fio: مستندات آزمون‌گر انعطاف‌پذیر ورودی/خروجی fio.readthedocs.io
- NVM Express: مرور مشخصات و پرسش‌های متداول nvmexpress.org
- کرنل Linux: اطلاعات توقف فشار docs.kernel.org
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.