برای تشخیص کندی دیسک در لینوکس، افزایش زمان پاسخ برنامه را با تأخیر درخواست‌های دیسک، طول صف و پردازش ایجادکننده بار در همان بازه مقایسه کنید. عدد بالای %iowait یا %util به‌تنهایی خرابی دیسک را ثابت نمی‌کند. مسیر عملی این است: دیسک مرتبط را پیدا کنید، چند نمونه با iostat بگیرید، مصرف پردازش‌ها را ببینید و نتیجه را با ساعت کندی سرویس تطبیق دهید.
این راهنما برای مدیر یک VPS یا سرور لینوکس است که فروشگاه، پایگاه داده یا سرویسش کند شده اما علت مشخصی ندارد. فرمان‌های تشخیصی زیر اطلاعات موجود را می‌خوانند؛ فایل آزمایشی حجیم نمی‌سازند و آزمون فشار اجرا نمی‌کنند. اگر ابزار موجود نیست، نصب آن را جداگانه با سیاست نگهداری سرور هماهنگ کنید. نام دیسک‌ها و خروجی نسخه‌های مختلف ممکن است با مثال‌ها متفاوت باشد.
کندی I/O با پربودن دیسک چه تفاوتی دارد؟
ظرفیت، می‌گوید چه مقدار فضا برای داده باقی مانده؛ کارایی، می‌گوید درخواست خواندن یا نوشتن چقدر طول می‌کشد. دیسکی با فضای آزاد زیاد هم می‌تواند زیر بار کند باشد. از طرف دیگر، خطای نبود فضای کافی یا تمام شدن inode مسیر بررسی متفاوتی دارد. کمبود RAM و جابه‌جایی مداوم داده به swap نیز ممکن است بار دیسک ایجاد کند؛ در این حالت افزایش سرعت ذخیره‌سازی، علت اصلی مصرف حافظه را برطرف نمی‌کند.
| نشانه | بررسی اولیه | تصمیم بعدی |
|---|---|---|
| خطای No space left on device | فضا و inode همان فایل‌سیستم | بررسی ظرفیت، نه نتیجه‌گیری از سرعت دیسک |
| کندی هم‌زمان با بکاپ | زمان بکاپ و تغییر تأخیر I/O | بررسی رقابت کارها بر سر ذخیره‌سازی |
| تأخیر برنامه همراه با افزایش صف دیسک | iostat در زمان اختلال | شناسایی پردازش و مسیر داده |
| فعالیت مستمر swap | vmstat و وضعیت حافظه | بررسی فشار حافظه در کنار دیسک |
| کندی فقط یک درخواست وب | زمان پاسخ برنامه و دیتابیس | بررسی کوئری، قفل و وابستگی همان درخواست |
۱. زمان اختلال و مسیر داده را مشخص کنید
پیش از اجرای ابزار، یک رخداد قابل تکرار انتخاب کنید: مثلاً جست‌وجوی محصول یا ثبت گزارش که قبلاً سریع بود. ساعت شروع، مدت پاسخ، تعداد درخواست‌ها و کارهای پس‌زمینه هم‌زمان را ثبت کنید. مقایسه ساعت خلوت با اوج بازدید بدون توجه به تفاوت بار، نتیجه دقیقی نمی‌دهد. بهتر است هم یک بازه عادی و هم بازه اختلال از همان عملیات داشته باشید.
date -Is
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
df -hT /var/lib
df -i /var/lib
مسیر /var/lib نمونه است؛ آن را با مسیر واقعی داده برنامه جایگزین کنید. خروجی lsblk رابطه دستگاه‌ها و محل اتصال را نشان می‌دهد. ممکن است فایل‌سیستم روی LVM، RAID یا دیسک مجازی قرار داشته باشد. ردیف‌های dm-0 و دیسک زیر آن لزوماً دو ذخیره‌ساز مستقل نیستند؛ جمع‌کردن کورکورانه آمارشان می‌تواند یک عملیات را دوبار حساب کند. اگر داده روی NFS یا ذخیره‌سازی شبکه‌ای است، آمار دیسک محلی تمام مسیر را توضیح نمی‌دهد.
۲. چند نمونه کوتاه از وضعیت دیسک بگیرید
iostat -x -y 1 10
این فرمان از مجموعه sysstat، گزارش تفصیلی را با فاصله یک ثانیه در ده نوبت نمایش می‌دهد. گزینه -y گزارش میانگین از زمان راه‌اندازی را حذف می‌کند تا با وضعیت همین لحظه اشتباه نشود. نمونه ده‌ثانیه‌ای فقط یک مشاهده کوتاه است؛ اگر کندی مقطعی است، در بازه وقوع آن تکرارش کنید. اجرای پشت‌سرهم ابزار هنگام آرام بودن سرور، اختلال ساعت قبل را بازسازی نمی‌کند.
| ستون | معنی | نکته تفسیر |
|---|---|---|
| r/s و w/s | تعداد درخواست‌های تکمیل‌شده خواندن و نوشتن در ثانیه، پس از ادغام | تعداد بیشتر بدون دانستن اندازه درخواست و تأخیر، بد نیست |
| r_await و w_await | میانگین زمان صف و خدمت درخواست‌ها به میلی‌ثانیه | آن‌ها را با سابقه همان بار کاری مقایسه کنید |
| aqu-sz | میانگین تعداد درخواست‌های صف | افزایش هم‌زمان با کندی برنامه ارزش بررسی دارد |
| %util | درصد زمانی که دستگاه درگیر درخواست I/O بوده | در SSD و RAID موازی، سقف کارایی را به‌تنهایی نشان نمی‌دهد |
برای این ستون‌ها یک مرز ثابت و مناسب همه سرورها وجود ندارد. همان نرخ عملیات روی NVMe، دیسک مکانیکی یا یک حجم مجازی محدودشده رفتار یکسانی ندارد. میانگین تأخیر هم جهش‌های کوتاه یا کندترین درخواست‌های برنامه را پنهان می‌کند. اگر مانیتورینگ برنامه صدک‌های زمان پاسخ را ثبت می‌کند، آن‌ها را کنار آمار سیستم ببینید.
۳. پردازش ایجادکننده بار را پیدا کنید
pidstat -d 1 10
ستون‌های kB_rd/s و kB_wr/s به شناسایی پردازش‌هایی کمک می‌کنند که خواندن یا نوشتن ایجاد می‌کنند. PID و نام فرمان را با سرویس واقعی تطبیق دهید؛ ممکن است پردازش پرمصرف، بکاپ برنامه‌ریزی‌شده باشد یا پایگاه داده‌ای که درخواست عادی کاربران را انجام می‌دهد. مصرف زیاد، به‌تنهایی مجوز متوقف‌کردن پردازش نیست. ابتدا نقش آن، زمان شروع و ارتباطش با اختلال را روشن کنید.
حسابداری پردازش و دستگاه دقیقاً یک چیز نیستند؛ کش و نوشتن با تأخیر می‌توانند زمان ثبت مصرف را متفاوت کنند. خالی بودن خروجی نیز الزاماً نبود I/O را ثابت نمی‌کند؛ دسترسی حساب، تنظیمات کرنل و کوتاه‌عمر بودن پردازش‌ها اثر دارند. iodelay در این ابزار با clock tick گزارش می‌شود و نباید آن را مستقیم میلی‌ثانیه بخوانید. برای توضیح جزئیات، راهنمای رسمی pidstat را ببینید.
۴. حافظه و فشار انتظار را در کنار دیسک ببینید
vmstat 1 10
cat /proc/pressure/io
در vmstat، گزارش نخستِ بسیاری از شمارنده‌ها میانگین از زمان بوت است؛ برای وضعیت جاری ردیف‌های بعدی را بخوانید. ستون‌های si و so جابه‌جایی با swap را نشان می‌دهند. فعالیت مداوم آن‌ها همراه با کندی می‌تواند شما را به بررسی فشار حافظه هدایت کند. ستون b تعداد پردازش‌های مسدود منتظر I/O را نشان می‌دهد؛ آن را نیز در چند نمونه دنبال کنید.
اگر PSI در محیط در دسترس باشد، فایل /proc/pressure/io سهم زمانی توقف کارها به علت فشار I/O را نشان می‌دهد. سطر some به توقف دست‌کم بخشی از کارها و full به توقف هم‌زمان همه کارهای غیربیکار مربوط است. میانگین‌های ۱۰، ۶۰ و ۳۰۰ ثانیه‌ای، روند کوتاه و بلندتر را روشن می‌کنند. نبودن این فایل در یک محیط، اثبات سلامت دیسک نیست؛ پشتیبانی و تنظیم کرنل را بررسی کنید.
درصد iowait CPU را علامت کمکی بگیرید. مستندات کرنل توضیح می‌دهد که محاسبه این مقدار، به‌ویژه روی چند هسته، محدودیت دارد. پایین بودنش مشکل I/O را رد نمی‌کند و بالا بودنش دستگاه خراب را مشخص نمی‌کند. نتیجه را از هم‌زمانی چند شاهد بگیرید: کندی عملیات واقعی، تغییر تأخیر دستگاه، صف و پردازشی که بار می‌سازد.
مثال آموزشی: چرا پایان بکاپ یک سرنخ است؟
فرض کنید در یک سناریوی ساختگی، گزارش فروش در حالت عادی ۰٫۸ ثانیه طول می‌کشد و w_await حدود ۲ میلی‌ثانیه است. در زمان بکاپ، گزارش به ۴ ثانیه و میانگین انتظار نوشتن به ۲۵ میلی‌ثانیه می‌رسد؛ صف هم بزرگ‌تر می‌شود. بعد از پایان بکاپ هر سه مقدار به نزدیکی حالت عادی برمی‌گردند. این اعداد نتیجه آزمایش آفاق هاست یا آستانه سلامت نیستند؛ فقط روش مقایسه را نشان می‌دهند.
نتیجه قابل دفاع، وجود ارتباط زمانی میان بار بکاپ و اختلال است؛ هنوز خرابی قطعه ثابت نشده است. گام بعدی می‌تواند جداکردن زمان بکاپ و گزارش در یک نوبت هماهنگ‌شده و مقایسه دوباره باشد. اگر با همان بار کاربران مشکل باقی ماند، محدودیت حجم مجازی، خطای ذخیره‌سازی یا نیاز واقعی برنامه باید بررسی شود. تغییر چند تنظیم هم‌زمان، امکان فهمیدن علت بهبود را کم می‌کند.
چه زمانی بررسی را به پشتیبانی ارجاع دهیم؟
در VPS، سیستم مهمان همه لایه‌های میزبان و ذخیره‌سازی را نمی‌بیند. گزارش شامل زمان دقیق با منطقه زمانی، نام دستگاه، نمونه iostat، PID مرتبط و اثر اختلال بر برنامه، برای بررسی میزبان مفیدتر از عبارت «دیسک ضعیف است» خواهد بود. اگر خطای I/O یا قطع دستگاه در گزارش کرنل دیده می‌شود، آن پیام را هم با رعایت محرمانگی ارسال کنید. اطلاعات کاربران و رمزها را وارد تیکت عمومی نکنید.
برای کمک به تشخیص و اصلاح برنامه، محدوده خدمات مدیریت سرور و سایت را بررسی کنید. اگر بعد از اندازه‌گیری به تغییر منابع رسیدید، در مقایسه سرور مجازی ایران یا سرور اختصاصی آلمان، نوع ذخیره‌سازی و شرایط IOPS و توان انتقال قابل ارائه را بپرسید؛ نام SSD یا اختصاصی بودن سرور، جای آزمون بار واقعی را نمی‌گیرد.
معیار پایان عیب‌یابی کندی دیسک
کار زمانی تمام است که عملیات آسیب‌دیده در بار مشابه به زمان پاسخ قابل قبول شما برگردد، خطا تکرار نشود و مشاهده بعدی هم نتیجه را تأیید کند. پیش و پس از اقدام، یک عملیات و یک بازه قابل مقایسه داشته باشید. پایین آمدن یک عدد در داشبورد، در حالی که کاربر هنوز منتظر می‌ماند، پایان مسئله نیست. نتیجه و تغییر انجام‌شده را ثبت کنید تا در رخداد بعدی نقطه مقایسه داشته باشید.
پرسش‌های رایج
آیا %util برابر ۱۰۰ یعنی باید دیسک عوض شود؟
خیر. برای ذخیره‌سازی موازی مثل SSD و RAID، این عدد به‌تنهایی ظرفیت نهایی را مشخص نمی‌کند. تأخیر، صف، بار برنامه و سابقه همان دستگاه را کنار هم بررسی کنید.
آیا تست نوشتن فایل بزرگ روی سرور فعال لازم است؟
برای شروع تشخیص لازم نیست. چنین آزمونی خودش بار ایجاد می‌کند و می‌تواند سرویس را کندتر کند. ابتدا از مشاهده بار واقعی استفاده کنید؛ آزمون ظرفیت مستقل به محیط و زمان هماهنگ‌شده نیاز دارد.
چرا دیسک NVMe با فضای آزاد هنوز کند است؟
فضای آزاد نشان‌دهنده زمان پاسخ نیست. الگوی درخواست، محدودیت پلن، رقابت کارها و لایه مجازی‌سازی می‌توانند مؤثر باشند. باید همان مسیر و همان ساعت اختلال اندازه‌گیری شود.
اگر ابزارها عادی‌اند ولی سایت کند است چه کنیم؟
بررسی را به برنامه، قفل و کوئری دیتابیس، CPU و وابستگی شبکه گسترش دهید. همچنین مطمئن شوید نمونه‌برداری واقعاً در زمان کندی بوده؛ مشاهده عادی پس از رخداد، علت قبلی را رد نمی‌کند.
منابع فنی
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.