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

برای تشخیص اورسل سرور مجازی، اگر ماشین در ساعت‌های شلوغ کند می‌شود، پیش از تغییر کد یا ارتقای پلن باید مشخص کنید پردازنده واقعاً مشغول اجرای برنامه شماست یا ماشین برای دریافت زمان CPU منتظر مانده است. شاخص CPU Steal این انتظار را نشان می‌دهد. با نمونه‌برداری پیوسته از این مقدار می‌توانید تشخیص دهید آیا رقابت روی پردازنده میزبان در افت عملکرد نقش دارد یا باید سراغ دیسک، بار برنامه و محدودیت‌های دیگر بروید.

CPU Steal چیست و چه ارتباطی با اورسل دارد؟

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

این وضعیت را می‌توان با انتظار چند نفر برای استفاده از یک منبع مشترک مقایسه کرد. هر ماشین مجازی می‌تواند چند vCPU داشته باشد، اما در زمان شلوغی همه آن‌ها باید برای زمان پردازنده رقابت کنند. اگر مجموع تقاضا از ظرفیت قابل ارائه میزبان فراتر برود، تأخیر انتظار بیشتر می‌شود.

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

فیلد steal در فایل /proc/stat کجاست؟

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

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

چرا نمونه لحظه‌ای کافی نیست؟

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

آزمون پنج‌دقیقه‌ای با top و vmstat

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

در vmstat ستون st نیز زمان steal را نشان می‌دهد. خروجی این ابزار معمولاً یک ردیف نخست دارد که میانگین از زمان راه‌اندازی سیستم را منعکس می‌کند؛ برای بررسی بازه‌های بعدی باید آن ردیف را کنار بگذارید. هنگام خواندن خروجی، برچسب ستون‌ها را بررسی کنید و بر اساس جایگاه ثابت حدس نزنید؛ در نسخه‌های جدید ممکن است ستون‌های دیگری مانند gu نیز در انتهای گزارش وجود داشته باشند.

برای نمونه‌برداری پنج‌دقیقه‌ای، می‌توانید گزارش‌ها را با فاصله پنج ثانیه و تعداد مشخص اجرا کنید تا پس از کنار گذاشتن ردیف اولیه، ۶۰ بازه پنج‌ثانیه‌ای باقی بماند. ابزار mpstat از بسته sysstat نیز امکان مشاهده وضعیت پردازنده‌ها را به تفکیک فراهم می‌کند. نسخه ابزار و دستور اجراشده را همراه خروجی ذخیره کنید.

محاسبه درصد دقیق از دو نمونه /proc/stat

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

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

تشخیص Steal از مصرف CPU، انتظار دیسک و محدودیت cgroup

هر کندی پردازنده مجازی به معنی اورسل نیست. دست‌کم سه وضعیت دیگر ممکن است نتیجه مشابهی در تجربه کاربر ایجاد کنند: مصرف بالای پردازنده توسط فرایندهای خودتان، انتظار برای ورودی و خروجی ذخیره‌ساز و محدودیت سهمیه CPU در cgroup. برای تشخیص درست باید این شاخص‌ها را کنار هم بخوانید.

بار واقعی برنامه در us و sy

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

انتظار ذخیره‌ساز در wa

ستون wa به زمان انتظار برای عملیات ورودی و خروجی بلوکی مربوط است؛ مانند دیسک محلی یا ذخیره‌ساز شبکه‌ای که به شکل بلوکی در اختیار سیستم قرار گرفته است. این ستون تأخیر پاسخ یک سرویس اینترنتی یا سوکت شبکه را نشان نمی‌دهد. اگر wa بالا و st پایین باشد، مسئله را در لایه ذخیره‌سازی و الگوی خواندن و نوشتن دنبال کنید.

سهمیه پردازنده در cgroup

در لینوکس، cgroup می‌تواند برای گروهی از فرایندها سقف مصرف CPU تعیین کند. در cgroup v2 فایل cpu.max مقدار سهمیه و دوره زمانی را نشان می‌دهد و فایل cpu.stat شمارنده‌هایی مانند nr_throttled و throttled_usec دارد. افزایش nr_throttled در یک بازه می‌تواند نشان دهد گروه فرایندها به سقف سهمیه خود رسیده است.

برای بررسی باید مسیر cgroup فرایند موردنظر را پیدا کنید؛ در نسخه دوم معمولاً مسیر در سطر مربوط به cgroup در فایل /proc/PID/cgroup درج می‌شود. فایل cpu.max در گروه ریشه الزاماً وجود ندارد، زیرا کنترل منابع برای ریشه به شکل متفاوتی اعمال می‌شود. در cgroup v1 نام فایل‌های مرتبط با سهمیه معمولاً cpu.cfs_quota_us و cpu.cfs_period_us است.

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

آستانه‌های عملی و زمان اقدام

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

حتی درصد کم نیز در یک سرویس حساس به تأخیر می‌تواند اثرگذار باشد، در حالی که همان مقدار روی یک ماشین کم‌بار شاید محسوس نباشد. یک بار در ساعت خلوت و یک بار در ساعت اوج اندازه بگیرید. اگر عدد در ساعت شلوغ به‌صورت مداوم افزایش می‌یابد و هم‌زمان زمان پاسخ برنامه بدتر می‌شود، شواهد قوی‌تری برای بررسی میزبان خواهید داشت.

چه گزارشی برای پشتیبانی آماده کنیم؟

گزارش دقیق به تیم پشتیبانی کمک می‌کند همان بازه را در سامانه مانیتورینگ میزبان بررسی کند. به جای ارسال یک تصویر از top یا نوشتن «سرور کند است»، اطلاعات قابل بازتولید ارائه دهید.

• تاریخ و ساعت دقیق شروع و پایان نمونه‌برداری، همراه با منطقه زمانی.
• دو خط خام cpu از /proc/stat و درصد محاسبه‌شده در بازه.
• خروجی vmstat یا top با ستون‌های us، sy، wa و st.
• مقدار load average در همان زمان.
• اختلاف شمارنده nr_throttled در cgroup مربوط به فرایند، در صورت وجود.
• نمونه‌ای از اثر روی سرویس، مانند زمان پاسخ یک درخواست مشخص.

این داده‌ها کمک می‌کنند میان فشار برنامه، انتظار دیسک، محدودیت سهمیه و رقابت روی میزبان تفاوت بگذارید. اگر شواهد نشان می‌دهد مشکل از زمان‌بندی پردازنده میزبان است، درخواست بررسی یا انتقال ماشین به میزبان دیگر را با همین گزارش مطرح کنید.

چه کارهایی می‌توانید برای کاهش اثر کندی انجام دهید؟

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

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

پرسش‌های متداول درباره CPU Steal

مقدار st در top از کجا می‌آید؟

این شاخص از فیلد steal در خط cpu فایل /proc/stat محاسبه می‌شود. ابزار top تغییر شمارنده را در بازه نمونه‌برداری به درصد زمان پردازنده تبدیل می‌کند.

اگر مقدار steal صفر باشد، یعنی سرور هیچ مشکلی ندارد؟

خیر. صفر بودن steal فقط نشان می‌دهد در بازه موردنظر انتظار ثبت‌شده‌ای برای CPU وجود نداشته است. دیسک، حافظه، شبکه و بار نرم‌افزار باید جداگانه بررسی شوند.

تفاوت اورکامیت و اورسل چیست؟

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

چه مدت باید نمونه‌برداری کرد؟

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

چرا ردیف اول vmstat با ردیف‌های بعدی فرق دارد؟

ردیف نخست در بسیاری از نسخه‌ها میانگین از زمان بوت را گزارش می‌کند، نه یک بازه پنج‌ثانیه‌ای. برای محاسبه بازه‌ای، آن را کنار بگذارید و ردیف‌های بعدی را بررسی کنید.

آیا کم کردن vCPU مقدار steal را کم می‌کند؟

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

جمع‌بندی؛ کندی را به عدد و بازه زمانی تبدیل کنید

CPU Steal شاخصی برای سنجش زمانی است که ماشین مجازی آماده اجرا بوده اما به پردازنده میزبان دسترسی نگرفته است. برای بررسی، یک نمونه لحظه‌ای را ملاک قرار ندهید؛ در یک بازه پنج‌دقیقه‌ای از top، vmstat یا دو نمونه /proc/stat استفاده کنید. سپس مقدار st را کنار us، sy، wa و شمارنده‌های cgroup قرار دهید تا مصرف واقعی برنامه، انتظار دیسک و محدودیت سهمیه از رقابت میزبان جدا شوند. گزارشی شامل زمان دقیق، داده خام و اثر قابل اندازه‌گیری روی سرویس آماده کنید. چنین گزارشی مبنای فنی بهتری برای پیگیری با پشتیبانی یا مقایسه پلن بعدی خواهد بود.

نمونه‌برداری را به یک روال قابل تکرار تبدیل کنید

برای آنکه بتوانید وضعیت یک سرور را در روزهای مختلف مقایسه کنید، روش نمونه‌برداری را ثابت نگه دارید. بازه پنج‌دقیقه‌ای، فاصله نمونه‌ها و ابزار مورد استفاده را تغییر ندهید. اگر یک بار از top و بار دیگر از vmstat استفاده می‌کنید، نام ستون‌ها و تفاوت بازه گزارش را در نظر بگیرید و خروجی‌ها را بدون همسان‌سازی مستقیم کنار هم نگذارید.

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

ثبت خط مبنای سرور

خط مبنا یعنی مقدار معمول شاخص‌ها در شرایطی که سرویس درست کار می‌کند. اگر برای چند روز مقدار steal، load average، مصرف CPU و زمان پاسخ برنامه را ثبت کنید، بعداً می‌توانید بفهمید افزایش ناگهانی از چه زمانی شروع شده است. مقایسه با خط مبنای خود سرور، از مقایسه با یک عدد عمومی دقیق‌تر است.

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

تفسیر هم‌زمان شاخص‌ها

Steal را جدا از سایر ستون‌ها نخوانید. اگر us و sy بالا هستند، پردازنده در حال اجرای کارهای داخل ماشین است. اگر wa بالا باشد، سیستم برای عملیات ورودی و خروجی منتظر مانده است. اگر st بالا باشد، ماشین برای دریافت زمان پردازنده از میزبان منتظر است. چند شاخص کنار هم، مسیر بررسی را روشن‌تر می‌کنند.

این جدول مسیر تشخیص اولیه را نشان می‌دهد و جای بررسی دقیق لاگ‌ها را نمی‌گیرد. ممکن است بیش از یک عامل هم‌زمان وجود داشته باشد؛ برای نمونه، بار سنگین برنامه می‌تواند همراه با محدودیت cgroup یا انتظار دیسک دیده شود.

چطور یک تیکت فنی قابل پیگیری بنویسیم؟

در گزارش، به جای توصیف کلی کندی، یک رخداد قابل بازتولید ارائه کنید. زمان دقیق، IP یا شناسه ماشین، دستور اجراشده، خروجی خام و اثر روی سرویس را کنار هم بگذارید. اگر مقدار steal در چند بازه بالا بوده، همه نمونه‌ها را پیوست کنید تا تیم فنی بتواند آن را با نمودارهای میزبان تطبیق دهد.

از ارسال فقط تصویر خروجی خودداری کنید؛ متن خام امکان جست‌وجو و مقایسه را فراهم می‌کند. اگر فایل‌های گزارش طولانی‌اند، بخش مربوط به خط cpu، ستون‌های vmstat و مقادیر cgroup را جدا کنید، اما فایل اصلی را نیز نگه دارید. همچنین مشخص کنید آیا در همان زمان بکاپ یا پردازش سنگینی در حال اجرا بوده است.

چه زمانی تغییر پلن منطقی است؟

اگر مصرف CPU داخل ماشین بالاست و برنامه واقعاً از هسته‌های موجود استفاده می‌کند، ارتقای منابع یا بهینه‌سازی نرم‌افزار می‌تواند مفید باشد. اگر st در ساعت اوج بالا می‌رود اما بار داخلی پایین است، افزودن vCPU به همان میزبان ممکن است انتظار را برطرف نکند. در چنین شرایطی باید وضعیت میزبان و شیوه تخصیص منابع را با ارائه‌دهنده بررسی کنید.

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

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