چرا یک هسته CPU سرور پر است اما میانگین پردازنده پایین مانده؟

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

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

فرض کنید چهار CPU منطقی در دسترس برنامه است. اگر یک کار در تمام یک بازه تقریباً معادل ظرفیت یکی از آن‌ها را مصرف کند و بقیه بیکار باشند، میانگین ساده کل ممکن است نزدیک ۲۵ درصد باشد. «CPU منطقی» لزوماً برابر با یک هسته فیزیکی مستقل نیست؛ در ماشین مجازی ممکن است vCPU ببینید و روی سرور فیزیکی نیز فناوری‌هایی مثل SMT در نمایش اثر دارند.

رشته بخشی از اجرای برنامه است. یک کار ترتیبیِ تک‌رشته‌ای در هر لحظه معمولاً نمی‌تواند هم‌زمان روی چند CPU اجرا شود، هرچند سیستم‌عامل ممکن است آن را در طول زمان میان CPUها جابه‌جا کند. برنامه چندرشته‌ای هم ممکن است یک مرحله یا رشته گلوگاه داشته باشد. بنابراین از یک نمودار کلی یا یک نمونه کوتاه نتیجه قطعی نگیرید.

این فرمان تعداد واحدهای پردازشی در دسترس همان فرایند را گزارش می‌کند. محدودیت affinity، محیط کانتینر یا تنظیم سیستم می‌تواند عدد را تحت تأثیر قرار دهد؛ آن را بدون بررسی معادل تعداد هسته فیزیکی میزبان ندانید.

در صفحه top کلید 1 را بزنید تا در نسخه‌های رایج خط‌های جداگانه CPU نمایش داده شوند. چند نوبت به‌روزرسانی صبر کنید و ببینید آیا یک CPU در زمان کندی پیوسته بسیار مشغول است یا مصرف بین آن‌ها پخش می‌شود. با q خارج شوید. رابط و شیوه نمایش درصد در نسخه‌ها متفاوت است و کلید I در برخی نسخه‌ها بین مقیاس‌های نمایش تغییر می‌دهد؛ راهنمای top جزئیات نسخه خود را توضیح می‌دهد.

اگر ابزار mpstat از بسته sysstat نصب است، این دستور پنج نمونه یک‌ثانیه‌ای می‌گیرد:

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

در top فهرست پردازش‌ها را بر اساس CPU ببینید و PID برنامه مشکوک را یادداشت کنید. برای نمونه، اگر PID واقعی 1234 بود:

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

TID شناسه رشته و PSR شماره CPU گزارش‌شده است. درصد ps معمولاً میانگین عمر پردازش یا رشته را بازتاب می‌دهد و با درصد نمونه‌ای top یکسان نیست. یک رشته پرمصرف به‌تنهایی ثابت نمی‌کند همان رشته علت کندی کاربر است؛ زمان پاسخ، نوع کار و گزارش خود برنامه را کنار آن بگذارید.

برای شناخت پردازش بدون تغییر آن:

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

اگر ابزار taskset نصب است، محدودیت CPU رشته اصلی را فقط بخوانید:

خروجی ممکن است فهرستی مانند 0-3 نشان دهد. این یعنی آن رشته اجازه زمان‌بندی روی آن CPUها را دارد، نه اینکه خود برنامه حتماً کارش را موازی انجام می‌دهد. رشته‌های دیگر ممکن است affinity متفاوت داشته باشند. اگر فهرست فقط یک CPU است، منشأ محدودیت را در تنظیم سرویس، کانتینر یا برنامه پیدا کنید؛ تغییر مستقیم affinity یک پردازش زنده ممکن است پس از راه‌اندازی مجدد از بین برود یا با سیاست برنامه تداخل داشته باشد.

محدودیت زمان CPU در cgroup نیز می‌تواند با وجود CPU آزاد، سرویس را معطل کند. اگر مشکل به سقف گروه مربوط باشد، راهنمای تشخیص CPUQuota و throttling خواندن cpu.max، شمارنده و سهم والد را آموزش می‌دهد. affinity و quota یکی نیستند: اولی محل‌های مجاز اجرا و دومی سهم زمانی را محدود می‌کند.

همه کارها قابلیت تقسیم ندارند. اما اگر گلوگاه یک فشرده‌سازی معمول gzip است و فایل مستقل و ظرفیت کافی دارید، ابزار pigz می‌تواند بخش فشرده‌سازی را با چند رشته انجام دهد. ابتدا وجود آن را ببینید:

اگر مسیری چاپ نشد، ابزار نصب نیست؛ در صورت تأیید مدیر سیستم آن را از مخزن معتبر توزیع نصب کنید. فرض کنیم فایل ورودی /srv/reports/export.csv و پوشه خروجی /srv/backups وجود دارند و فایل خروجی هم‌نام هنوز وجود ندارد. این نمونه با دو رشته اجرا می‌شود:

-p 2 تعداد رشته‌های کاری در این مثال، -c نوشتن خروجی به جریان استاندارد و set -C جلوگیری از بازنویسی فایل موجود توسط این redirection است. مسیرها و تعداد رشته را با شرایط خود جایگزین کنید. قبل از اجرا فضای مقصد، دسترسی و حساسیت داده را بررسی کنید. اگر عملیات شکست خورد ممکن است فایل خروجی ناقص باقی بماند؛ فقط پس از شناسایی همان فایل آزمایشی و اطمینان از بی‌نیازی، آن را پاک کنید.

پس از تکمیل، سلامت ساختار فایل فشرده را بسنجید:

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

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

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

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