WIUNIX ACADEMY
تشخیص کندی I/O در لینوکس با iostat و PSI
وقتی دیسک شلوغه یا برنامه منتظر میمونه، مسیر داده، صف دستگاه و فشار پردازشها رو کنار هم بررسی کن تا تصمیم بعدی بر پایهٔ شواهد باشه؛ بدون بارسازی یا تغییر تنظیم کرنل.
محیطت رو انتخاب کنآموزش متناسب با محیط تو
کجا اجرا میکنی؟
سیستمعامل و نسخهٔ سرورت رو انتخاب کن تا مراحل، دستورها و راهحلهای همون محیط رو ببینی.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه رو با مشخصات سرورت عوض کن تا متن و دستورها با هم تغییر کنن. رمز، کلید خصوصی و توکن اینجا وارد نکن. مقدارها فقط توی همین زبانه میمونن و به سرور یا لینک اشتراکگذاری فرستاده نمیشن. قبل از اجرا، DNS، گواهیها و تنظیمات دسترسی شبکه رو روی سرورت بررسی کن.
اگر آیپی، دامنه یا پورتهای نمونه با سرورت فرق دارن، بخش تنظیمات پایین رو باز کن. مقدارها رو عوض کن و «اعمال در آموزش» رو بزن؛ بعد دستورهای تازه رو کپی کن.
تنظیم مقادیر برای محیط من4 مقدار قابلتغییر
از اینجا شروع کن
آخر این آموزش چی خواهیم داشت؟
وقتی دیسک شلوغه یا برنامه منتظر میمونه، مسیر داده، صف دستگاه و فشار پردازشها رو کنار هم بررسی کن تا تصمیم بعدی بر پایهٔ شواهد باشه؛ بدون بارسازی یا تغییر تنظیم کرنل.
سیستمعاملها و نسخههای پوششدادهشده
مسیرهای Ubuntu 26.10 و نسخههای LTS 26.04/24.04، Debian 13/12، RHEL/Rocky/AlmaLinux 10/9 و Arch/Manjaro غلتان در ۲۰۲۶-۱۱-۰۵ با مستندات بررسی شدن. اسم بستهها و روش آمادهسازی فرق داره؛ وجود PSI و cgroup v2 رو روی کرنل واقعی بررسی میکنیم. این شواهد اجرای عملی روی همهٔ سیستمها نیست.
قبل از شروع
- دسترسی مجاز به میزبان درگیر، زمان رخداد و یک عملیات مشخص برنامه برای سنجش تأخیر یا خطا.
- ابزارهای sysstat، procps یا procps-ng و util-linux؛ نصبِ لازم فقط در محدودهٔ مجاز نگهداری.
- برای شاخهٔ اختیاری سرویس، systemd و cgroup v2 موجود با دسترسی خواندن؛ برای دادهٔ شبکهای، شواهد سمت سرور هم لازمه.
- خروجی تشخیص ممکنه نام پردازش و مسیر داخلی داشته باشه؛ فقط در محل خصوصیِ مصوب نگهش دار.
کندی برنامه واقعاً از دیسکه؟
وقتی یک درخواست یا کار طول میکشه، اول زمان و اثرش رو روی برنامه مشخص میکنیم. دیسک شلوغ لزوماً گلوگاه نیست؛ از طرف دیگه، کمبودن مصرف CPU هم سالمبودن مسیر ذخیرهسازی رو ثابت نمیکنه. قرار است زمان انتظار برنامه رو به انتظار پردازشها و فعالیت دستگاه مرتبط کنیم، بدون اینکه بار آزمایشی بسازیم یا تنظیمی رو تغییر بدیم.
این مسیر برای میزبان لینوکس با systemd و ذخیرهسازی محلیِ مبتنی بر block device نوشته شده. اگر داده روی NFS، فایلسیستم توزیعشده، لایهٔ کانتینر یا دیسک ابری قرار داره، اول همون لایه رو پیدا کن. آمار میزبان بهتنهایی صف سمت سرور یا سهمیه و اعتبار باقیموندهٔ دیسک ابری رو نشون نمیده.
بازهٔ رخداد، تأخیر یا خطای برنامه و یک بازهٔ عادی برای مقایسه لازم داریم. برای await، طول صف یا PSI یک عدد سالمِ همگانی وجود نداره؛ دنبال تغییری میگردیم که همزمان با افت عملکرد همین برنامه اتفاق افتاده باشه.
قدم بعدی
اول میزبان و ابزارها رو مشخص کنیم
از شل مجاز خود میزبان شروع کن، نه یک کانتینر اتفاقی؛ ممکنه کانتینر mountها، PIDها و cgroupهای متفاوتی ببینه. نسخهٔ واقعی توزیع و کرنل رو با محیط انتخابشده مقایسه کن. ابزارهای iostat و pidstat در بستهٔ sysstat هستن؛ بستهٔ vmstat در خانوادهٔ DEB اسمش procps است و در خانوادهٔ RPM و Arch به اسم procps-ng عرضه میشه.
بررسی پایین چیزی نصب نمیکنه. اگر ابزاری کم بود، با روش مصوب نصب بسته روی همین میزبان آمادهاش کن. پنل اختیاری بعدی بستهها رو تغییر میده و روی میزبان درگیر حادثه لازم نیست کورکورانه اجراش کنی. برای نمونهبرداری کوتاه، نیازی به فعالکردن سرویس یا تایمر جمعآوری sar نداریم.
در Ubuntu از مخزن رسمی همین نسخه استفاده کن؛ نسخههای 26.04 و 24.04 مسیرهای LTS هستن و 26.10 مسیر عادی با دورهٔ پشتیبانی کوتاهتر است.
ترمینال مجاز روی همان میزبان لینوکس درگیر
cat /etc/os-release
uname -r
ps -p 1 -o comm=
dpkg-query -W sysstat procps util-linux coreutils systemd
command -v iostat pidstat vmstat findmnt lsblk systemctl date
iostat -V
pidstat -Vنسخهٔ سیستم و ابزارها مشخص است. برای بخش اختیاری unit و cgroup، پردازش شمارهٔ ۱ باید systemd باشه. نبود ابزار یعنی مسیر هنوز آماده نیست، نه اینکه فشار صفره.
قدم بعدی
اگر ابزارها نیستن، در زمان مناسب نصبشون کن
اگر ابزارها از قبل موجودن، از این پنل رد شو. روی محیط آزمایش یا در زمان مصوب نگهداری، تغییرهای پیشنهادی مدیر بسته رو ببین و فقط از مخزن رسمیِ فعال همین توزیع نصب کن. نصب ممکنه unitهای خود بسته رو هم راهاندازی کنه؛ نتیجه رو بررسی کن و صرفاً برای این آموزش جمعآوری تاریخچه رو فعال نکن.
از اینجا به بعد داده میخونیم، ولی همین مشاهده هم هزینه داره؛ تعداد نمونهها رو محدود و خروجیها رو خصوصی نگه دار. AppArmor، SELinux و محدودیتهای procfs و cgroup سر جاشون میمونن. اگر مجوز کافی نداری، با مسئول میزبان حلش کن؛ حفاظت سیستم رو برای دیدن یک عدد خاموش نمیکنیم.
ترمینال مجاز روی همان میزبان لینوکس درگیر
sudo apt-get update
sudo apt-get install sysstat procps util-linux coreutils
command -v iostat pidstat vmstat findmnt lsblkبعد از بررسی و انجام نصب، فرمانهای لازم پیدا میشن؛ خودمان سرویس جمعآوری آمار رو فعال نکردیم.
قدم بعدی
مسیر داده به کدوم ذخیرهساز میرسه؟
مقدار /var/lib رو روی یک پوشهٔ واقعیِ دادهٔ برنامه بگذار. findmnt فایلسیستم اون مسیر رو در همین فضای mount نشون میده؛ بعد با lsblk درخت دستگاهها و شناسهٔ major:minor رو میبینیم. اگر مسیر از LVM، mapper یا RAID میگذره، لایههای پایینترش رو هم دنبال کن؛ اولین نام nvme الزاماً دیسک این برنامه نیست.
آمار هر لایه رو جدا نگه دار. ممکنه یک درخواست هم روی volume منطقی و هم روی دیسک زیرش دیده بشه؛ جمعکردن این عددها کار یکسان رو دو بار حساب میکنه. اگر منبع network filesystem یا overlay بود، انتساب مستقیم به دیسک محلی رو متوقف کن و مسیر واقعی داده رو با مسئول همون لایه پیدا کن.
ترمینال مجاز روی همان میزبان لینوکس درگیر
test -d '/var/lib' || exit 1
findmnt --target '/var/lib' -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -o NAME,KNAME,MAJ:MIN,TYPE,SIZE,FSTYPE,MOUNTPOINTSمسیر، فایلسیستم و لایههای دستگاه مشخصن؛ اگر داده از شبکه یا overlay میاد، همون محدودیت ثبت شده.
قدم بعدی
ببینیم پردازشها چقدر منتظر میمونن
PSI زمان معطلشدن پردازشها رو میسنجه، نه مدت شلوغی دیسک. در I/O، مقدار some یعنی دستکم یک پردازش منتظر بوده؛ full یعنی همهٔ پردازشهای غیربیکارِ همون محدوده همزمان معطل بودن. avg10، avg60 و avg300 روند درصدی این بازهها هستن و total زمان تجمعی انتظار رو به میکروثانیه نگه میداره. full جزئی از some است؛ این دو رو با هم جمع نکن.
فشار I/O و حافظه رو دو بار همراه زمان UTC میخونیم. یک جهش کوتاه ممکنه total رو زیاد کنه ولی در میانگین طولانی چندان دیده نشه. اگر فشار حافظه و swap هم بالا رفته، شاید بخشی از انتظار I/O از همونجا اومده باشه؛ با مشاهدههای بعدی تفکیکش میکنیم. نبود فایل pressure یعنی این کرنل یا محدوده PSI رو در اختیارمون نمیگذاره، نه اینکه فشاری وجود نداره.
ترمینال مجاز روی همان میزبان لینوکس درگیر
date -u +%FT%TZ
for resource in io memory; do
printf '\n%s pressure\n' "$resource"
if test -r "/proc/pressure/$resource"; then
cat "/proc/pressure/$resource"
else
printf 'PSI unavailable or unreadable in this scope\n' >&2
fi
done
sleep 5
date -u +%FT%TZ
for resource in io memory; do
if test -r "/proc/pressure/$resource"; then cat "/proc/pressure/$resource"; fi
doneدو نمونه با زمان مشخص داریم؛ رشد زمان تجمعی انتظار معلوم میشه و نبود رابط هم پنهان نمیمونه.
قدم بعدی
تأخیر، حجم کار و صف رو کنار هم بخون
نمونه رو وقتی برنامه کند شده بگیر و با بار عادیِ مشابه مقایسه کن. گزینهٔ -y گزارش میانگین از زمان روشنشدن سیستم رو حذف میکنه. دستگاههای مرتبط رو از نقشهٔ قبلی انتخاب کن: r_await و w_await زمان صف و رسیدگی رو با هم دارن، aqu-sz میانگین درخواستهای در حال انتظار یا رسیدگی است و حجم و تعداد عملیات شکل بار رو نشون میدن.
بالابودن %util یعنی در بیشتر اون بازه درخواست فعالی وجود داشته؛ برای NVMe موازی، RAID یا دیسک مجازی نمیشه اون رو درصد قطعیِ ظرفیت حساب کرد. حجم انتقال کم با await رو به رشد میتونه از درخواستهای ریز و همگام، محدودیت پشتصحنه یا خطا بیاد. حجم انتقال زیاد با تأخیر عادیِ برنامه هم ممکنه فقط کار مفید باشه. از تفریق این میانگینها زمان سرویس اختراع نکن.
ترمینال مجاز روی همان میزبان لینوکس درگیر
date -u +%FT%TZ
LC_ALL=C iostat -d -x -m -y 1 5پنج گزارش بازهای داریم تا با اثر روی برنامه و PSI مقایسه کنیم؛ نام ستونها و لایهٔ دستگاه رو نگه میداریم، نه یک آستانهٔ همگانی.