تشخیص اورسل در سرور مجازی با CPU Steal؛ تست ۵ دقیقه‌ای

هشتمین عدد روی خط cpu در فایل /proc/stat کار تشخیص اورسل سرور مجازی را ساده می‌کند. این عدد همان steal است؛ مدتی که پردازنده مجازی شما آماده اجرا بود و هایپروایزر هسته فیزیکی را به ماشین مجازی دیگری داده بود. وقتی این مقدار چند دقیقه پیوسته بالا بماند، گره کندی بیرون از سرور شماست و با بهینه‌سازی کد باز نمی‌شود.

پرسش	پاسخ کوتاه
عدد کلیدی	فیلد steal؛ هشتمین عدد خط cpu در /proc/stat که در top با نام %st دیده می‌شود
ابزار لازم	دستور top و دستور vmstat از بسته procps-ng؛ روی ایمیج‌های کوچک مثل Alpine باید نصب شوند
مدت نمونه‌برداری	پنج دقیقه نمونه پیوسته، نه یک نگاه لحظه‌ای به خروجی
مرز هشدار	میانگین پیوسته بالای ۱۰ درصد در ساعت‌های پرترافیک
خطای رایج	اشتباه گرفتن steal با iowait یا با سقف سهمیه cgroup خود سرور

فرق یک شکایت و یک گزارش، عدد است. این مقاله همان عدد را می‌سازد و بعد نشان می‌دهد چطور از عامل‌های شبیه به آن جدا می‌شود. در پایان هم جدولی دارید که می‌گوید با هر بازه از آن عدد چه کار کنید.

مقدار steal در سرور مجازی چه چیزی را می‌شمارد؟

مقدار steal سهمی از زمان پردازنده است که ماشین مجازی شما برای اجرا آماده بود، اما هسته فیزیکی در اختیار ماشین دیگری قرار داشت. هسته لینوکس این زمان را از نسخه 2.6.11 به بعد جدا می‌شمارد. طبق مستندات proc_stat(5) جای آن فیلد هشتم خط cpu است؛ ابزارهای سطح کاربر همین عدد را با نام %st یا st نشان می‌دهند.

نوبت‌دهی هسته فیزیکی بین چند ماشین مجازی

هر میزبان تعداد محدودی هسته فیزیکی دارد و هایپروایزر آن‌ها را نوبتی بین ماشین‌های مجازی تقسیم می‌کند. تصور کنید در یک سالن کوچک ده نفر برای یک میکروفن نوبت گرفته‌اند؛ تا میکروفن آزاد نشود، نوبت کسی نمی‌رسد. مقدار steal مدت انتظار برای میکروفن است، نه مدت حرف زدن. بسیاری از ارائه‌دهنده‌ها مجموع پردازنده‌های مجازی فروخته‌شده را بیشتر از هسته‌های فیزیکی می‌گیرند و تا وقتی بار همه ماشین‌ها همزمان بالا نرود، کسی متوجه نمی‌شود. پلن‌هایی هم هستند که هسته اختصاصی می‌دهند و این رقابت را ندارند. برای مرور مفاهیم هایپروایزر، مجازی‌سازی و نقش هایپروایزر را ببینید.

اورسل در این مقاله یعنی پردازنده‌های مجازی فعال روی یک میزبان، از چیزی که هسته‌های فیزیکی بدون انتظار محسوس سرویس می‌دهند بیشتر باشند. چیزی که این تعریف را سنجش‌پذیر می‌کند، همان steal پایدار در یک بازه مشخص است.

فیلد هشتم در فایل /proc/stat

فایل /proc/stat روی خط cpu ده عدد دارد. ترتیب آن‌ها چنین است: user، nice، system، idle، iowait، irq، softirq، steal، guest و guest_nice. هر عدد شمارنده‌ای تجمعی از لحظه بوت است و به‌تنهایی هیچ معنایی ندارد؛ معنی از اختلاف دو نمونه در دو زمان به‌دست می‌آید. همین دو نمونه، پایه عددیِ تشخیص اورسل سرور مجازی است و بقیه ابزارها هم در پشت صحنه کار دیگری نمی‌کنند.

همین تست را پیش از تصمیم نهایی روی سرور تازه هم می‌شود گرفت؛ سرور مجازی ایرانی وب‌داده امکان تست ساعتی رایگان سرور دارد.

تست پنج‌دقیقه‌ای با top، vmstat و دو نمونه از /proc/stat

تست پنج‌دقیقه‌ای یعنی به‌جای یک نگاه لحظه‌ای، مقدار steal را در یک بازه پیوسته بسنجید. سه راه موازی دارید: ستون %st در top، ستون st در vmstat و محاسبه مستقیم از دو نمونه /proc/stat. هر سه یک شمارنده را می‌خوانند، اما کارشان یکی نیست: دو روش اول الگو را نشان می‌دهند و روش سوم میانگین همان بازه را می‌دهد.

خواندن ستون st در خروجی top

top -b -n 2 -d 5 | grep '%Cpu'

دستور top با سوئیچ -b در حالت دسته‌ای و بدون ورودی کیبورد اجرا می‌شود؛ سوئیچ -n هم تعداد فریم‌ها را محدود می‌کند. راهنمای رسمی top(1) مقدار st را «زمان دزدیده‌شده از این ماشین مجازی توسط هایپروایزر» تعریف می‌کند. در خروجی بالا دو فریم با فاصله پنج ثانیه گرفته می‌شود و فریم دوم ملاک است، چون بازه مشخصی دارد. خط خروجی چنین شکلی دارد و عددِ چسبیده به st همان چیزی است که دنبالش هستید:

%Cpu(s): 12.4 us,  2.1 sy,  0.0 ni, 78.3 id,  0.6 wa,  0.0 hi,  0.1 si,  6.5 st

این عدد یک نمونه پنج‌ثانیه‌ای است، پس برای ادعای پایدار بودن مشکل کافی نیست؛ کار top همین نگاه سریع است و میانگین پنج‌دقیقه‌ای را از روش سوم می‌گیرید. کلید 1 هم در نمایش تعاملی خط خلاصه را به یک خط برای هر پردازنده باز می‌کند.

اجرای vmstat با بازه و تعداد مشخص

vmstat 5 61

در بخش CPU خروجی vmstat ستونی به نام st هست که «زمان دزدیده‌شده از ماشین مجازی» را می‌شمارد. ستون را از نام سرستون پیدا کنید، نه از جای آن: مستندات vmstat(8) شش ستون us، sy، id، wa، st و gu را به همین ترتیب فهرست می‌کند. پس روی نسخه‌های تازه procps-ng ستون آخر gu است و کسی که «ستون آخر» را بخواند عدد اشتباه برمی‌دارد.

همان مستندات می‌گوید اولین گزارش، میانگین از آخرین راه‌اندازی مجدد است؛ پس خط اول را دور بیندازید. دستور بالا ۶۱ گزارش می‌گیرد تا بعد از حذف خط اول، دقیقاً ۶۰ بازه پنج‌ثانیه‌ای و در مجموع ۳۰۰ ثانیه باقی بماند. ابزار mpstat از بسته sysstat هم با سوئیچ -P ALL همین مقدار را برای هر پردازنده جدا گزارش می‌کند.

محاسبه درصد دقیق از دو نمونه خام

sample() { awk '/^cpu /{print $2+$3+$4+$5+$6+$7+$8+$9, $9}' /proc/stat; }
set -- $(sample); T1=$1; S1=$2
sleep 300
set -- $(sample); T2=$1; S2=$2
awk -v s1=$S1 -v s2=$S2 -v t1=$T1 -v t2=$T2 \
    'BEGIN{printf "steal: %.2f %%\n", (s2-s1)*100/(t2-t1)}'

این چند خط دو نمونه به فاصله ۳۰۰ ثانیه می‌گیرد، مجموع هشت فیلد اول را کل زمان پردازنده می‌گیرد و سهم steal را از اختلاف دو نمونه به‌دست می‌آورد. خروجی یک عدد است با یک بازه زمانی روشن و همین عدد سندِ تشخیص اورسل سرور مجازی است که عین آن به تیکت پیوست می‌شود. دو فیلد guest و guest_nice در مخرج نیامده‌اند، چون زمان اجرای ماشین مجازی‌ای را می‌شمارند که خودِ این سیستم میزبانش باشد.

دستور sleep 300 ترمینال را پنج دقیقه نگه می‌دارد؛ روی اتصال SSH ناپایدار، این چند خط را داخل screen یا tmux اجرا کنید.

تفکیک steal از بار واقعی سرور، انتظار دیسک و سهمیه cgroup

کندی سرور همیشه از رقابت روی میزبان نمی‌آید. سه حالت شبیه هم هستند: بار واقعی فرایندهای خودتان، انتظار ورودی و خروجی دیسک که در iowait می‌نشیند، و سقف سهمیه گروه فرایندها. هر سه را با همان خروجی vmstat و یک فایل در cgroup از هم جدا می‌کنید.

بار فرایندهای خودتان در ستون‌های us و sy

مستندات vmstat ستون us را زمان اجرای کد غیرهسته و ستون sy را زمان اجرای کد هسته تعریف می‌کند. اگر مجموع این دو بالا باشد و st نزدیک صفر بماند، پردازنده در اختیار شما بوده؛ جای رسیدگی فهرست فرایندها و کوئری‌های سنگین است، نه تیکت.

انتظار ورودی و خروجی دیسک در ستون wa

مستندات vmstat ستون wa را زمان انتظار برای ورودی و خروجی تعریف می‌کند و منظور، ورودی و خروجی بلوکی است: دیسک محلی یا ذخیره‌ساز شبکه‌ای مثل NFS و iSCSI. تأخیر یک سوکت شبکه یا کندی پاسخ یک سرویس بیرونی در این ستون شمرده نمی‌شود، پس برای مشکل شبکه سراغ wa نروید. مقدار بالای wa با st پایین یعنی مشکل در لایه ذخیره‌سازی است، نه در پردازنده.

سقف سهمیه cgroup و فیلد nr_throttled

# مسیر cgroup خود پروسه؛ در cgroup v2 همیشه با 0:: شروع می‌شود
cat /proc/self/cgroup
CG="/sys/fs/cgroup$(awk -F: '$1==0{print $3}' /proc/self/cgroup)"
cat "$CG/cpu.max" 2>/dev/null || echo 'cpu.max: none in this cgroup'
grep -E 'nr_throttled|throttled_usec' "$CG/cpu.stat" 2>/dev/null

سازوکار بازه و سهمیه در زمان‌بند لینوکس کار می‌کند: هر گروه فرایند در هر دوره فقط به اندازه سهمیه‌اش پردازنده می‌گیرد و بعد تا دوره بعد متوقف می‌شود. مستندات زمان‌بند هسته این توقف را throttling می‌نامد. شمارنده nr_throttled تعداد دفعات آن را نگه می‌دارد. در راهنمای cgroup v2 هم فایل cpu.max با قالب $MAX $PERIOD و پیش‌فرض max 100000 معرفی شده است؛ فیلدهای nr_throttled و throttled_usec هم در cpu.stat گزارش می‌شوند. مسیر را هم باید درست انتخاب کنید: طبق همان راهنما، سطر cgroup v2 در فایل /proc/$PID/cgroup همیشه قالب 0::$PATH دارد و دستور بالا همین مسیر را می‌سازد.

فایل cpu.max فقط روی cgroupهای غیرریشه هست؛ راهنمای cgroup v2 می‌گوید ریشه از کنترل منابع مستثناست. پس cat /sys/fs/cgroup/cpu.max روی ریشه خطای «چنین فایل یا پوشه‌ای نیست» می‌دهد و این خطا به‌تنهایی معنایی ندارد. اگر مسیر پروسه شما ریشه بود، سهمیه‌ای از این نوع روی کار شما نیست و این احتمال کنار می‌رود. در cgroup v1 معادل‌ها cpu.cfs_quota_us و cpu.cfs_period_us هستند.

از داخل مهمان فقط cgroupهای همان مهمان دیده می‌شوند. سقفی که میزبان روی کل ماشین مجازی شما گذاشته باشد در این فایل‌ها نمی‌آید و اثرش در همان مقدار steal ظاهر می‌شود. برای مقایسه درست، nr_throttled را دو بار با فاصله همان پنج دقیقه بخوانید و اختلاف دو عدد را نگاه کنید؛ یک‌بار خواندن یک شمارنده تجمعی چیزی نمی‌گوید. اگر اختلاف صفر بود و st بالا ماند، سقف خودتان مقصر نیست. همین تفکیک است که تشخیص اورسل سرور مجازی را از یک حدس جدا می‌کند.

نشانه در خروجی	عدد شاخص	علت محتمل
کندی با بار سبک فرایندها	مقدار st بالا، us و sy پایین	رقابت روی هسته‌های فیزیکی میزبان
کندی با بار سنگین فرایندها	مقدار us یا sy بالا، st نزدیک صفر	بار واقعی خود سرور
توقف‌های کوتاه و دوره‌ای	شمارنده nr_throttled صعودی، st پایین	سقف سهمیه cgroup
تأخیر پاسخ پایگاه داده	مقدار wa بالا	فشار روی دیسک یا شبکه ذخیره‌سازی

آستانه‌ها، اقدام عملی و گزارشی که ارائه‌دهنده جدی می‌گیرد

عدد خام تا وقتی به بازه زمانی و بار کاری گره نخورد تصمیم‌ساز نیست. آستانه عملی ما این است: میانگین پنج‌دقیقه‌ای زیر ۲ درصد طبیعی، بازه ۲ تا ۱۰ درصد زیر نظر، و مقدار پیوسته بالای ۱۰ درصد در ساعت پرترافیک یک مسئله.

این مرزها داوری تحریریه ما برای کار روزمره است، نه عددی از مستندات رسمی. تنها مرزی که منبع بیرونی دارد همان ۱۰ درصد است: راهنمای Site24x7 زیر ۱۰ درصد را بی‌اهمیت و بالای آن را نشانه کندی محتمل ماشین مجازی می‌داند.

عدد تنها بی‌معنی است. ۳ درصد steal روی سرور آزمایشیِ کم‌بار به چشم نمی‌آید، ولی همان ۳ درصد روی سروری که در ساعت اوج تمام هسته‌هایش درگیر است، تأخیر محسوس می‌سازد. برای همین تشخیص اورسل سرور مجازی همیشه یک مقایسه است: عدد امروز در برابر خط مبنای همان سرور. یک بار در ساعت خلوت و یک بار در ساعت اوج نمونه بگیرید.

میانگین steal در پنج دقیقه	تفسیر (داوری تحریریه)	اقدام
زیر ۲ درصد	رقابت معمول روی میزبان مشترک	کاری لازم نیست؛ همین عدد را به‌عنوان خط مبنا ذخیره کنید
۲ تا ۱۰ درصد	فشار دوره‌ای روی هسته‌های میزبان	نمونه‌برداری را به ساعت اوج ببرید و با خط مبنا مقایسه کنید
۱۰ تا ۳۰ درصد پیوسته	رقابت جدی روی هسته‌های میزبان	گزارش را به پشتیبانی بدهید و جابه‌جایی به میزبان دیگر را بخواهید
بالای ۳۰ درصد	فشار سنگین روی هسته‌های میزبان	مهلت روشنی بگذارید، مثلاً ۴۸ ساعت؛ اگر پاسخ فنی نگرفتید سرویس را عوض کنید

چک‌لیست گزارش برای تیم پشتیبانی

1. بازه زمانی دقیق با ساعت و تاریخ، تا طرف مقابل بتواند لاگ همان بازه را ببیند.
2. خروجی خام دو نمونه /proc/stat و درصد محاسبه‌شده، به‌جای عکس صفحه.
3. مقدار میانگین بار سیستم در همان بازه، از خروجی uptime یا cat /proc/loadavg، تا نشان دهید بار خودتان سبک بوده است.
4. اختلاف دو خواندن nr_throttled در همان بازه، تا احتمال سقف سهمیه خودتان منتفی شود.
5. اثر کاربری قابل اندازه‌گیری؛ مثلاً زمان پاسخ یک درخواست مشخص، نه جمله «سرور کند است».

کارهایی که خودتان می‌توانید امتحان کنید

جابه‌جایی کارهای سنگین زمان‌بندی‌شده مثل بکاپ و ایندکس‌گیری به ساعت خلوت، فشار همزمان را کم می‌کند و اثرش را با همان تست می‌بینید. اگر الگوی بار شما دائماً پرمصرف است، سراغ پلن‌هایی با هسته اختصاصی بروید؛ راهنمای انتخاب CPU سرور معیارهای این انتخاب را باز کرده است.

توصیه رایجِ «تعداد پردازنده مجازی را کم کنید» را با احتیاط بردارید. سازوکارش به زمان‌بند هایپروایزر میزبان بستگی دارد و برای زمان‌بند لینوکس سندی نداریم که آن را تضمین کند. اگر امتحانش می‌کنید، عدد قبل و بعد را با همان تست پنج‌دقیقه‌ای بسنجید و حواستان باشد که کاهش منابع در بعضی پنل‌ها برگشت‌پذیر نیست.

پرسش‌هایی که کاربران پیش از سنجش منابع می‌پرسند

جمع‌بندی؛ تشخیص اورسل سرور مجازی یک عدد و یک بازه زمانی است
کندی سرور حس می‌شود، ولی پیگیری‌اش به عدد نیاز دارد. مسیر کوتاه این است: ابزار top یا vmstat را با بازه و تعداد مشخص اجرا کنید، خط اول را دور بیندازید. برای خروجی قابل پیوست، درصد را از اختلاف دو نمونه /proc/stat حساب کنید. عدد به‌دست‌آمده را با خط مبنای خودتان بسنجید؛ زیر ۲ درصد را طبیعی بگیرید و بالای ۱۰ درصد پیوسته در ساعت اوج را مسئله بدانید. پیش از فرستادن تیکت، دو احتمال دیگر را رد کنید: بار واقعی فرایندهای خودتان که در us و sy دیده می‌شود، و سقف سهمیه cgroup. برای دومی، اختلاف دو خواندن nr_throttled را در مسیر درست خودش ببینید. بعد از این غربال، گزارشی دارید که بحث سلیقه‌ای را منتفی می‌کند: بازه زمانی، خروجی خام، درصد محاسبه‌شده و اثر کاربری. همین چهار قلم کافی است تا پشتیبانی ماشین شما را جابه‌جا کند یا دلیلی فنی برای رد درخواست بیاورد؛ و اگر پاسخی نگرفتید، معیاری دارید که سرویس بعدی را با آن بسنجید.

اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.

• مستندات proc_stat(5) درباره فیلدهای خط cpu
• راهنمای رسمی vmstat(8) و تعریف ستون st
• راهنمای رسمی top(1) و بخش وضعیت پردازنده
• مستندات هسته لینوکس درباره سهمیه و throttling زمان‌بند
• راهنمای cgroup v2 و فایل‌های cpu.max و cpu.stat