جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
به اشتراک بگذارید
جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
باوری رایج میان خریداران سرور می‌گوید برچسب NVMe یعنی دیسک سریع. برای سنجیدن این باور اول باید دانست IOPS چیست: شمار عملیات خواندن یا نوشتنی که دیسک در یک ثانیه تمام می‌کند.
| عدد | تعریف | واحد | چه چیزی رویش اثر دارد |
|---|---|---|---|
| تعداد عملیات (IOPS) | عملیات تمام‌شده در هر ثانیه | عملیات در ثانیه | اندازه بلوک، الگوی تصادفی یا ترتیبی، عمق صف |
| پهنای باند (Throughput) | داده جابه‌جاشده در هر ثانیه | بایت در ثانیه، مثلاً MiB/s | حاصل‌ضرب IOPS در اندازه بلوک |
| تأخیر (Latency) | زمان تکمیل یک عملیات | میکروثانیه یا میلی‌ثانیه | عمق صف، بار ماشین‌های دیگر میزبان |
💡 چهار مشخصه‌ای که کنار هر عدد IOPS لازم است
عدد IOPS یعنی عملیات تمام‌شده در هر ثانیه.
✅ اندازه بلوک، نسبت خواندن و نوشتن، عمق صف و تأخیر را کنارش بخواهید.
✅ وگرنه با یک دستور fio عدد خودتان را بسازید.
پنج باور زیر را صفحه فروش پلن‌ها یا پست‌های انجمن‌ها القا می‌کنند. از هر کدام فقط بخشی می‌ماند که مستندات رسمی یا آزمونی با تاریخ و مشخصات ماشین تأییدش می‌کند.
📌 پنج باور و آنچه از آن‌ها ماند
◀️ سه عددی که جای هم نمی‌نشینند
◀️ برچسب NVMe و عدد دیتاشیت
◀️ نیاز واقعی دیتابیس
◀️ عوامل افت روی سرور مجازی
تعریف IOPS، Throughput و Latency؛ سه عدد که جای هم نمی‌نشینند
پرسش IOPS چیست با یک عدد جواب نمی‌گیرد و سه عدد می‌خواهد: شمار عملیات در ثانیه (IOPS)، حجم داده در ثانیه (Throughput) و زمان تکمیل هر عملیات (Latency). اندازه بلوک دو عدد اول را به هم وصل می‌کند و عمق صف، اولی را به سومی.
در سالن مرسولات اداره پست، نامه‌هایی که هر دقیقه مرتب می‌شود IOPS است، کیسه‌هایی که هر ساعت بیرون می‌رود Throughput و مدتی که یک نامه منتظر می‌ماند Latency. سالنی که با کارت‌پستال تند است، با بسته سنگین کند می‌شود. این سالن فقط یک بخش اداره است؛ سنجش کل سرور در راهنمای بنچمارک سرور مجازی آمده است.
رابطه IOPS با مگابایت بر ثانیه
باور: دیسکی که مگابایت بر ثانیه بالاتری دارد، IOPS بالاتری هم دارد.
آنچه مستندات می‌گوید: نمونه خروجی رسمی در مستندات fio برای یک کار نوشتن، میانگین ۸۸٫۹۸ عملیات و ۶۲۲٫۸۷ کیبی‌بایت در ثانیه را نشان می‌دهد.
تقسیم این دو عدد ۷ کیبی‌بایت می‌دهد، برابر حاصل 30.4MiB تقسیم بر ۴۴۵۰ عملیات. پس پهنای باند برابر IOPS ضرب در اندازه بلوک است.
عمق صف و هزینه‌ای که روی تأخیر می‌گذارد
باور: هرچه IOPS بالاتر باشد، جواب هر درخواست زودتر می‌رسد.
آنچه مستندات می‌گوید: در fio، گزینه iodepth تعداد عملیاتی است که همزمان روی فایل در جریان‌اند؛ پیش‌فرض ۱.
در آزمون نویسنده: اجراها در ۱۳ آبان ۱۴۰۵ روی یک ماشین مجازی آزمایشی انجام شد: ۲ vCPU، ۷ گیگابایت RAM، لینوکس 6.18، دیسک virtio با ext4، fio 3.36، فایل ۲ گیگابایتی، direct=1 و ۲۰ ثانیه. میزبانش سخت‌افزار نامعلومی دارد و پلن وب‌داده نیست. خواندن تصادفی 4k با عمق صف ۱ کمترین عدد ۲۲ هزار IOPS با تأخیر ۳۷ میکروثانیه داد و با عمق صف ۳۲، ۵۷ هزار با ۵۴۴ میکروثانیه. IOPS دو و نیم برابر شد و هر عملیات پانزده برابر کندتر.
باور رایج: دیسک NVMe یعنی IOPS بالا
برچسب NVMe نام رابط و پروتکل است. عددی را تضمین نمی‌کند. دانستن اینکه IOPS چیست بدون شرایط آزمون نیمه‌کاره می‌ماند؛ دیتاشیت این شرایط را در پانویس آورده و روی سرور مجازی تکرار نمی‌شوند.
شرایطی که پشت عدد دیتاشیت نوشته شده
باور: عدد میلیونی دیتاشیت همان سرعتی است که دیسک همیشه دارد.
آنچه مستندات می‌گوید: دیتاشیت Kingston DC3000ME برای مدل ۳٫۸۴ ترابایتی ۲٬۷۰۰٬۰۰۰ IOPS خواندن تصادفی 4k می‌نویسد؛ طبق پانویسش با روش SNIA PTS Enterprise v1.1، کش نوشتن روشن و fio با عمق صف ۱۲۸.
تأخیر همان دیتاشیت (صدک ۹۹ خواندن زیر ۷۰ میکروثانیه) از آزمون دیگری با عمق صف ۱ آمده و صفحه تأخیرِ عمق صف ۱۲۸ را نمی‌گوید؛ بهترین IOPS و بهترین تأخیر از دو آزمون جدا هستند. دلیل فنی صف‌های زیاد NVMe را مطلب تفاوت پروتکل NVMe با AHCI توضیح می‌دهد.
⚠️ مقایسه بدون bs و iodepth بی‌معناست
چهار پرسش بپرسید: اندازه بلوک؟ عمق صف؟ خواندن یا نوشتن؟ تأخیرِ همان آزمون؟
عددی که این پاسخ‌ها را ندارد، با عدد fio شما یا پلن دیگر مقایسه‌پذیر نیست.
سهم سرور مجازی از دیسک میزبان
باور: سرور مجازی روی NVMe همان عدد دیتاشیت را می‌گیرد.
آنچه مستندات می‌گوید: دیتاشیت عدد هر ظرفیت را برای یک درایو، با روش SNIA و کش نوشتن روشن، گزارش می‌کند.
روی ماشین آزمایشی: دیسک فقط با نام vda و درایور virtio دیده می‌شد، بدون مدل درایو زیرین. پس عدد واقعی را فقط آزمون روی خود سرور با گزینه‌های ثابت می‌دهد.
🔸 پنج گزینه fio که عدد را عوض می‌کنند
گزینه direct=1: ورودی و خروجی بدون بافر؛ پیش‌فرض خاموش و بدون آن کش وارد عدد می‌شود.
گزینه bs: اندازه بلوک؛ پیش‌فرض 4096 بایت.
گزینه iodepth: عملیات در جریان؛ روی موتورهای همگام بی‌اثر.
گزینه ioengine=libaio: موتور ناهمگام لینوکس.
گزینه rw=randread: خواندن تصادفی؛ بدون rw، fio خواندن ترتیبی اجرا می‌کند.
مستندات fio بسته آن را در مخزن‌های Debian، Ubuntu و Fedora/EPEL معرفی می‌کند؛ خط اول زیر روی Ubuntu 24.04 آزمایش شد. آزمون را در پوشه‌ای روی دیسک موردنظر، یک بار با iodepth=32 و یک بار با iodepth=1 اجرا کنید:
sudo apt install fio sysstat
fio --name=rand4k --filename=fio-test.file --size=2G --direct=1 --ioengine=libaio --rw=randread --bs=4k --iodepth=32 --runtime=20 --time_based --group_reporting
rm fio-test.fileاز خروجی IOPS در خط read، عدد 99.00th در clat percentiles و خط IO depths را بردارید.
| باور | آنچه مستندات می‌گوید |
|---|---|
| برچسب NVMe یعنی IOPS بالا | عدد میلیونی با عمق صف ۱۲۸ و کش روشن است |
| عدد IOPS بالاتر یعنی جواب سریع‌تر | تأخیر فقط در عمق صف ۱ اعلام شده |
| عدد IOPS و MB/s جای هم می‌نشینند | پهنای باند ÷ IOPS = اندازه بلوک |
| سرور مجازی عدد دیتاشیت را می‌گیرد | دیتاشیت یک درایو تنها را می‌سنجد |
| عمق صفی که نوشتید همان است که اجرا شد | موتور همگام آن را به ۱ می‌رساند |
دیتابیس واقعاً چه مقدار IOPS لازم دارد؟
مستندات MySQL 8.4 و PostgreSQL 18 هیچ حداقل IOPS اعلام نمی‌کنند. تعریف اینکه IOPS چیست برای دیتابیس فرقی نمی‌کند؛ ترکیب خواندن و نوشتن و عمق صف خود دیتابیس فرق می‌کند و آن را فقط اندازه‌گیری بار واقعی نشان می‌دهد.
توان دیسک در تنظیم‌های MySQL و PostgreSQL
باور: دیتابیس برای کار درست، حداقل چند هزار IOPS لازم دارد.
آنچه مستندات می‌گوید: راهنمای پیکربندی ظرفیت I/O در InnoDB می‌گوید innodb_io_capacity تقریباً برابر IOPS سیستم تنظیم شود؛ پیش‌فرض ۱۰۰۰۰ است و بالاتر از ۲۰۰۰۰ توصیه نمی‌شود، مگر مطمئن باشید کمتر کافی نیست. در PostgreSQL 18، effective_io_concurrency با پیش‌فرض ۱۶ شمار عملیات همزمان مورد انتظار است و مستندات PostgreSQL هشدار می‌دهد مقدار بی‌دلیل بالا ممکن است تأخیر همه کوئری‌ها را بیشتر کند.
سنجش بار واقعی با iostat
در ساعت شلوغ، این فرمان سه گزارش تفصیلی با فاصله ۵ ثانیه می‌دهد، بدون گزارش آمار از زمان بوت:
iostat -xy 5 3در صفحه راهنمای iostat، r/s و w/s همان IOPS خواندن و نوشتن‌اند، rkB/s و wkB/s پهنای باند، r_await و w_await زمان پاسخ به میلی‌ثانیه و aqu-sz طول میانگین صف. ستون %util برای SSDهای امروزی حد کارایی را نشان نمی‌دهد.
قاعده تصمیم (پیشنهاد ما؛ مستندات قاعده‌ای ندارند): اوج r/s به‌اضافه w/s را با کمترین عدد fio در عمق صفی نزدیک aqu-sz همان ساعت مقایسه کنید. اگر به بیش از نیمی از آن برسد یا w_await در اوج بالا برود، دیسک گلوگاه بعدی است؛ وگرنه کندی از جای دیگری است.
💡 دو حساب سرانگشتی برای خواندن خروجی‌ها
پهنای باند = IOPS × اندازه بلوک؛ iostat در اجرایی جداگانه با عمق صف ۳۲ نشان داد ۷۶٬۶۱۷٫۲ × ۴ = ۳۰۶٬۴۶۸٫۸ کیبی‌بایت در ثانیه.
تعداد IOPS ≈ عمق صف ÷ تأخیر میانگین؛ ۳۲ ÷ ۵۴۴ میکروثانیه حدود ۵۹ هزار می‌شود، نزدیک ۵۷ هزارِ کندترین اجرا.
چه چیزهایی IOPS سرور مجازی را پایین می‌آورد
دیتاشیت وقتی می‌گوید IOPS چیست، از یک آزمون واحد حرف می‌زند؛ روی سرور مجازی دو عامل عدد را پایین می‌آورند: بار ماشین‌های دیگر میزبان، و برنامه‌ای که درخواست‌ها را تک‌تک می‌فرستد.
نوسان میزبان و یک آزمون تنها
باور: یک بار اجرای fio تکلیف دیسک را روشن می‌کند.
آنچه مستندات می‌گوید: مستندات fio تعداد تکرار تعیین نمی‌کند؛ فقط می‌خواهد خط IO depths را نگاه کنید تا عمق صف واقعی همان باشد که خواسته‌اید.
تکرار روی همان ماشین: یک فرمان یکسان با چند دقیقه فاصله ۸۲، ۵۷ و ۸۷ هزار IOPS داد و صدک ۹۹ تأخیر در اجرای کندتر ۴۴۸۹ میکروثانیه بود، در برابر حدود ۵۵۰. کسی که فقط اجرای دوم را دیده بود، این دیسک را رد می‌کرد. آزمون را در چند نوبت تکرار کنید و کمترین عدد را هم بنویسید.
برنامه‌ای که درخواست‌ها را تک‌تک می‌فرستد
باور: اگر دیسک در عمق صف ۳۲ سریع است، برنامه من هم همان عدد را می‌گیرد.
آنچه مستندات می‌گوید: بالا بردن iodepth از ۱ روی موتورهای همگام اثری ندارد و psync، موتور پیش‌فرض fio جز در ویندوز، همگام است.
با psync: همان آزمون عمق صف ۳۲ با psync پیام محدود شدن عمق به ۱ را داد و IOPS بین ۲۸ تا ۳۸ هزار ماند. این وضعیت برنامه‌ای است که بعد از هر درخواست منتظر پاسخ دیسک می‌ماند.
سه عدد و چند سوءتفاهم؛ هر کدام در دو سه جمله:
عدد IOPS بالا مهم‌تر است یا تأخیر پایین؟
برای دیتابیس و سایت، تأخیر در عمق صف کم به تجربه کاربر نزدیک‌تر است. هر دو را از یک آزمون بخواهید.
فرق IOPS تصادفی با ترتیبی در چیست؟
در rw=randread هر عملیات از نقطه دیگری از فایل می‌خواند و در rw=read پشت سر هم. دیتاشیت Kingston اولی را با IOPS و دومی را با MB/s گزارش کرده است.
میانگین تأخیر را ملاک بگیرم یا صدک ۹۹؟
صدک ۹۹. در نمونه خروجی رسمی fio، میانگین تأخیر تکمیل ۴۰۱۹ میکروثانیه است، میانه ۴۱۶ و صدک ۹۹ برابر ۴۳۷۷۹.
آیا عدد خواندن تصادفی برای نوشتن هم صدق می‌کند؟
خیر. در همان دیتاشیت، نوشتن تصادفی 4k مدل ۳٫۸۴ ترابایتی ۳۰۰ هزار IOPS است و خواندن ۲٫۷ میلیون؛ randwrite را جدا بسنجید.
چرا با iodepth=32 عدد تغییری نکرد؟
احتمالاً psync فعال است یا libaio بدون direct=1 اجرا شده، که طبق مستندات fio لینوکس شاید با آن صف نسازد. در خط IO depths باید 32 نزدیک صد درصد باشد.
آیا تست fio به داده‌های سرور آسیب می‌زند؟
اگر filename یک فایل معمولی باشد، fio فقط همان را می‌نویسد؛ آزمون نوشتن روی دستگاه خام مثل /dev/vda داده را از بین می‌برد.
مقدار innodb_io_capacity را چند بگذارم؟
راهنمای MySQL 8.4 می‌گوید تقریباً برابر IOPS سیستم، تا حد ممکن پایین اما نه آن‌قدر که کارهای پس‌زمینه عقب بمانند. عدد fio سرور خودتان را مبنا بگیرید.
جمع‌بندی؛ روی سرور شما IOPS چیست عدد IOPS بدون اندازه بلوک، عمق صف و تأخیر با عدد دیگری مقایسه نمی‌شود. پهنای باند حاصل‌ضرب آن در اندازه بلوک است و عمق صف بالاتر، IOPS را به بهای تأخیر بیشتر می‌خرد. دیتاشیت NVMe عدد میلیونی را با عمق صف ۱۲۸ می‌دهد و تأخیر را در آزمونی دیگر، و برای سرور مجازی هیچ‌کدام تضمین نمی‌شود. fio را با direct=1 چند بار روی سرور آزمایشی اجرا کنید، کمترین عدد را نگه دارید و اوج بار دیتابیس را با iostat کنارش بگذارید.
🚀 از دیسک تا کل سرور
یک دستور YABS دیسک را کنار پردازنده و شبکه می‌سنجد؛ مقاله بنچمارک عدد تعیین‌کننده هر نوع بار را در یک جدول تصمیم می‌گذارد.
روی سرور خودتان fio با بلوک 4k چه عددی داد و iodepth را چند گذاشتید؟ صدک ۹۹ همان اجرا را هم کنارش بگذارید؛ IOPS بدون تأخیر را باور نمی‌کنیم.
- مستندات fio: fio.readthedocs.io
- دیتاشیت Kingston DC3000ME (PDF): kingston.com
- راهنمای MySQL 8.4، ظرفیت I/O در InnoDB: dev.mysql.com
- مستندات PostgreSQL 18، مصرف منابع: postgresql.org
- صفحه راهنمای iostat(1): man7.org
