محتوای آموزشی وبلاگ نت‌آرام
عدد فرکانس CPU روی سرور اختصاصی ایران کمتر از عدد درج‌شده در مشخصات پردازنده دیده می‌شود. آیا پردازنده خراب است؟ نه لزوماً. سیستم در زمان بیکاری می‌تواند برای کاهش مصرف، فرکانس را پایین بیاورد و هنگام بار دوباره افزایش دهد. از سوی دیگر، محدودیت دما، توان، تنظیم firmware یا نوع بار نیز می‌تواند فرکانس زیر بار را محدود کند.
برای تشخیص، یک عدد لحظه‌ای کافی نیست. باید هم‌زمان بار واقعی، فرکانس، دما و زمان پاسخ برنامه را ببینیم و آن را با شرایط سازنده مقایسه کنیم. فرکانس turbo برای همه هسته‌ها در همه زمان‌ها تضمین‌شده نیست. این راهنما برای لینوکس روی سرور فیزیکی است؛ در ماشین مجازی عددهای داخل مهمان ممکن است بازتاب دقیق وضعیت فیزیکی نباشند.
۱. مدل پردازنده و وضعیت بار را مشخص کنید
در ترمینال لینوکس اجرا کنید:
کد / دستورlscpu
uptime
top
مدل، تعداد CPUهای منطقی و معماری را از
lscpu بخوانید. uptime میانگین بار را می‌دهد و top تصویر پردازش‌ها را نشان می‌دهد؛ برای خروج از top کلید q را بزنید. بالا بودن load به‌تنهایی اثبات استفاده کامل CPU نیست، چون انتظارهای دیگر نیز می‌توانند در آن نقش داشته باشند. اگر برنامه فقط یک thread را مشغول می‌کند، میانگین کل CPU ممکن است پایین بماند؛ راهنمای یک هسته پر و میانگین CPU پایین این وضعیت را توضیح می‌دهد.برای مقایسه، زمان پاسخ همان کار واقعی را در ساعت عادی و هنگام کندی ثبت کنید. از اجرای stress test روی سرور عملیاتی بدون پنجره نگه‌داری، ظرفیت خنک‌سازی و هماهنگی خودداری کنید. بار آزمایشی باید شبیه برنامه واقعی و قابل توقف باشد.
۲. درایور و سیاست CPU را بخوانید
اگر بسته سازگار
کد / دستورcpupower از مخزن رسمی توزیع نصب است:sudo cpupower frequency-info
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
خروجی اول ممکن است درایور، محدوده سخت‌افزاری و سیاست فعلی را نشان دهد. دو مسیر دیگر نمونه مربوط به CPU صفر هستند؛ اگر فایل وجود ندارد، ممکن است درایور یا محیط این رابط را ارائه نکند. CPUهای دیگر یا policyهای مشترک را نیز با ابزار متناسب بررسی کنید. نام
powersave در همه درایورها معنی یکسانی ندارد؛ برای نمونه رفتار آن در intel_pstate با governor عمومی هم‌نام یکسان نیست. مستند کرنل درباره intel_pstate تفاوت‌ها را شرح می‌دهد.فرکانس نمایش‌داده‌شده در
/proc/cpuinfo یا ابزارهای عمومی ممکن است لحظه‌ای یا وابسته به روش گزارش درایور باشد. یک مقدار پایین در زمان بیکاری به‌تنهایی مشکل نیست. بسته به سیستم، policy ممکن است بر چند CPU اثر بگذارد؛ پیش از تغییر، گستره آن را بشناسید.۳. زیر بار واقعی و با ابزار پشتیبانی‌شده اندازه بگیرید
روی سرور x86 سازگار که
کد / دستورturbostat مناسب همان کرنل نصب است، در بازه کاری برنامه می‌توانید چند نمونه بگیرید:sudo turbostat --interval 2 --num_iterations 5
این مثال پنج بازه دوثانیه‌ای می‌گیرد. ابزار و برخی ستون‌ها به پردازنده، نسخه و دسترسی سخت‌افزاری وابسته‌اند؛ اگر گزینه یا شمارنده پشتیبانی نشد، راهنمای نسخه نصب‌شده را ببینید. ستون
Bzy_MHz در نسخه‌هایی که آن را دارند فرکانس متوسط هنگام فعال‌بودن CPU را نشان می‌دهد؛ Avg_MHz شامل زمان بیکاری هم می‌شود. مقدار را در همان بازه با بار برنامه مقایسه کنید و از یک نمونه کوتاه نتیجه همیشگی نگیرید.تعداد هسته‌های درگیر روی turbo مؤثر است. اگر نرم‌افزار یک هسته را درگیر می‌کند، نتیجه‌اش با بار هم‌زمان همه هسته‌ها فرق دارد. اگر کار شما عمدتاً منتظر دیسک یا شبکه است، بالا بردن فرکانس ممکن است زمان پاسخ را بهتر نکند.
۴. دما، توان و رخدادهای سخت‌افزاری را بررسی کنید
در صورت نصب بسته معتبر حسگرها،
کد / دستورsensors دماهای قابل گزارش را نشان می‌دهد. در پنل مدیریتی سخت‌افزار نیز وضعیت فن، دمای ورودی، هشدار برق و power cap را بخوانید. نام حسگر و آستانه مجاز به مدل پردازنده و سرور بستگی دارد؛ از یک عدد ثابت عمومی برای همه مدل‌ها استفاده نکنید. با فرمان زیر نیز می‌توانید گزارش کرنل را در همان بازه جست‌وجو کنید:sudo journalctl -k --since '2 hours ago' --no-pager | grep -i -E 'thermal|throttl|power'
پیام مرتبط با دما یا محدودیت توان همراه با کاهش فرکانس زیر بار، نشانه‌ای برای بررسی مسیر خنک‌سازی و تنظیم برق است. نبود پیام الزاماً نبود محدودیت سخت‌افزاری را ثابت نمی‌کند. اگر فن خراب یا دما غیرعادی است، پیش از افزایش توان، مسئول سخت‌افزار باید خنک‌سازی، جریان هوا و گزارش BMC را بررسی کند. غیرفعال‌کردن محافظ حرارتی یا تغییر firmware بدون طرح، راه‌حل امنی نیست.
۵. اگر سیاست لینوکس عامل محدودیت است
ابتدا مقدار governor و تنظیم‌های فعلی را برای هر policy ثبت کنید. اگر درایور و سخت‌افزار اجازه می‌دهند و مدیر سرور تغییر را تأیید کرده، می‌توانید در یک پنجره آزمون governor
کد / دستورperformance را موقتاً انتخاب کنید:sudo cpupower frequency-set --governor performance
sudo cpupower frequency-info
این تغییر می‌تواند مصرف برق و گرما را افزایش دهد و بسته به درایور یا policy بر چند هسته اثر بگذارد. لزوماً فرکانس ثابت یا turbo دائمی ایجاد نمی‌کند و محدودیت دما و توان همچنان اعمال می‌شود. سرویس‌هایی مثل tuned یا تنظیم firmware ممکن است مقدار را عوض کنند یا پس از ریبوت برگردانند. زمان پاسخ کار واقعی، دما و مصرف را قبل و بعد در شرایط مشابه ثبت کنید.
برای بازگشت، همان governor قبلیِ ثبت‌شده را با
cpupower frequency-set --governor نام-قبلی و فقط پس از تأیید نام و policy بازگردانید. اگر policyها مقادیر مختلف داشته‌اند، از روش دقیق همان توزیع برای بازگرداندن هر policy استفاده کنید. تغییر دائمی را فقط بعد از آزمون و از مسیر پیکربندی توصیه‌شده توزیع انجام دهید.۶. نتیجه را با کاربر واقعی بسنجید
اگر فرکانس زیر بار بالا رفت اما زمان کار بهبود نیافت، گلوگاه ممکن است در برنامه، قفل‌ها، حافظه، دیسک یا شبکه باشد. اگر فرکانس هنوز کم است و هشدار سخت‌افزاری یا power cap دیده می‌شود، خروجی سنجش، مدل CPU و زمان رخداد را به مسئول سخت‌افزار بدهید. انتخاب راهکار باید بر اساس عملکرد پایدار و سلامت سرور باشد، نه صرفاً رسیدن یک عدد لحظه‌ای به حداکثر تبلیغ‌شده.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام