تشخیص کندی I/O در لینوکس با iostat و PSI

در همون بازهٔ کندی، با vmstat تصویر حافظه و پردازش‌ها رو هم می‌گیریم. ستون‌های نرخ و CPU در ردیف اول میانگین از زمان بوت هستن؛ برای مقایسهٔ بازهٔ جاری ردیف‌های بعدی رو بخون. وضعیت پردازش و حافظه در همهٔ ردیف‌ها لحظه‌ایه. پردازش‌های blocked، ورود و خروج swap و ستون‌های CPU رو با هم ببین. ستون wa زمان بیکاری CPU در حضور I/O معوقه است، نه درصدی از عمر برنامه که صرف انتظار دیسک شده.

ممکنه یک برنامه منتظر I/O باشه ولی کارهای دیگه CPU رو مشغول نگه دارن و wa پایین بمونه. از طرف دیگه، پس‌گرفتن حافظه و swap هم می‌تونه ترافیک دیسک بسازه، بدون اینکه خواندن پایگاه داده بیشتر شده باشه. این نشونه‌ها کمک می‌کنن علت محتمل رو انتخاب کنیم؛ مجوز تغییر swap، پاک‌کردن cache یا دست‌کاری writeback نیستن.

date -u +%FT%TZ
LC_ALL=C vmstat 1 6

حالا سراغ پردازش‌هایی می‌ریم که هم‌زمان با کندی، خواندن یا نوشتن زیادی دارن. pidstat کمک می‌کنه این نامزدها رو پیدا کنیم. خروجی فقط نام پردازش رو نشون می‌ده، نه آرگومان‌هایی که ممکنه دادهٔ خصوصی داشته باشن. زیادبودن نوشتن یک پردازش هنوز ثابت نمی‌کنه همهٔ کارِ دیسک در همان لحظه از طرف اونه؛ بخشی از نوشتن ممکنه در بافر مونده باشه و بعداً به دیسک برسه، یا چند پردازش از یک فایل‌سیستم استفاده کنن.

صفر یا خالی‌بودن iodelay وقتی حسابداری تأخیر پردازش‌ها فعال نیست نتیجهٔ قطعی نمی‌ده. نیازهای کرنل در FAQ پروژهٔ sysstat توضیح داده شده. برای تکمیل یک ستون، وسط حادثه delay accounting رو فعال نکن و دسترسی procfs رو بازتر نکن؛ محدودیت دید رو با مسئول میزبان روشن و در گزارش نگه دار.

date -u +%FT%TZ
LC_ALL=C pidstat -d -p ALL 1 5

برای example نام واقعی سرویس systemd رو بدون پسوند .service وارد کن. قبل از انتخاب مسیر cgroup، هویت سرویس و ControlGroup رو می‌بینیم. این بخش اختیاری به cgroup v2 و دید خود میزبان نیاز داره؛ گروهی نمی‌سازیم و پردازشی رو جابه‌جا نمی‌کنیم. داخل کانتینر ممکنه مسیر واقعی میزبان دیده نشه.

محل واقعی mount از نوع cgroup2 رو با ControlGroup برگشتی کنار هم بگذار و مسیر کاملِ موجود رو در /sys/fs/cgroup/system.slice/example.service وارد کن. مقدار نمونه نام سرویس کشف‌شده نیست. اگر unit پیدا نشد یا ControlGroup خالی بود، همین بخش رو متوقف کن؛ مسیر حدسی جای نتیجهٔ مشاهده رو نمی‌گیره.

systemctl show 'example.service' -p Id -p LoadState -p ActiveState -p MainPID -p ControlGroup
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS

حالا پوشهٔ کشف‌شدهٔ سرویس رو دو بار می‌خونیم. io.stat بایت و عملیات رو به تفکیک major:minor می‌شماره؛ تغییر هر دستگاه رو در همین فاصله با نقشهٔ lsblk تطبیق بده. io.max سقف تنظیم‌شده رو نشون می‌ده. داشتن سقف ثابت نمی‌کنه سرویس بهش رسیده؛ نبود سقف در این پوشه هم محدودیت والد یا ارائه‌دهندهٔ دیسک رو رد نمی‌کنه.

ممکنه خود میزبان راحت باشه ولی سرویس در محدودهٔ خودش معطل بمونه. اگر لازم بود سیاست والد رو با مسئول سرویس بررسی کن؛ برای بهترشدن عددها io.max، io.weight یا واگذاری controller رو تغییر نمی‌دیم. همهٔ کرنل‌ها و آرایش‌های cgroup همهٔ فایل‌ها رو ندارن؛ نبود رابط رو صفر حساب نکن.

(
set -eu
cg='/sys/fs/cgroup/system.slice/example.service'
test -d "$cg"
test "$(findmnt -n -o FSTYPE --target "$cg")" = cgroup2
for sample in 1 2; do
  date -u +%FT%TZ
  for name in io.pressure io.stat io.max memory.pressure; do
    printf '\n%s\n' "$name"
    if test -r "$cg/$name"; then cat "$cg/$name"; else printf 'unavailable or unreadable\n' >&2; fi
  done
  if test "$sample" = 1; then sleep 5; fi
done
)