تصویر کلی
PSI در Linux میزان زمانی را گزارش می‌کند که taskها به‌خاطر contention روی CPU، memory یا IO پیشرفت نمی‌کنند.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
شاخص‌های some و full تصویر متفاوتی از فشار می‌دهند و می‌توان threshold trigger برای واکنش ساخت.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
PSI را باید کنار utilization و latency دید؛ مصرف ۱۰۰٪ همیشه معادل pressure شدید نیست و pressure می‌تواند قبل از crash قابل مشاهده باشد.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی Linux Kernel نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
مصرف منبع با انتظار برای منبع تفاوت دارد
یک پردازنده می‌تواند بیشتر زمان مشغول باشد و در عین حال برنامه‌ها بدون انتظار غیرعادی کار کنند. در مقابل، تعداد زیادی کار آماده ممکن است پشت ظرفیت محدود منتظر بمانند. PSI به اثر کمبود منبع بر پیشرفت کار توجه می‌کند و از این جهت مکمل درصد مصرف است. برای تفسیر درست، باید بدانیم چه کسی منتظر چه منبعی بوده و این انتظار چه اثری بر سرویس داشته است. درصد مصرف بالا به تنهایی حکم افزایش ظرفیت نیست؛ گاهی استفاده مؤثر از سخت‌افزار است و گاهی همراه با صف و تأخیر نامطلوب می‌شود.
برای نمونه، یک کار دسته‌ای شبانه می‌تواند تمام CPU آزاد را استفاده کند، بدون اینکه سرویس تعاملی آسیب ببیند. اگر همان کار با درخواست‌های روزانه رقابت کند، زمان انتظار سرویس ممکن است بالا برود. مقایسه فشار و تأخیر در این دو بازه کمک می‌کند سیاست منابع را دقیق‌تر انتخاب کنید. هدف الزاماً پایین نگه داشتن همه اعداد نیست؛ هدف حفظ کیفیت کار مهم است. بنابراین پیش از تعیین هشدار، اولویت بارها و زمان پاسخ قابل قبول هرکدام را روشن کنید.
some و full را با دامنه اندازه‌گیری بخوانیم
در گزارش فشار، some نشان‌دهنده دوره‌هایی است که دست‌کم بخشی از کارها به دلیل منبع متوقف‌اند. full در حوزه‌هایی که معنا و پشتیبانی دارد، وضعیت شدیدتری را درباره توقف همه کارهای غیر بیکار همان دامنه نشان می‌دهد. این دو عدد نباید بدون توجه به دامنه سیستم یا گروه کنترل تفسیر شوند. در یک میزبان بزرگ ممکن است برنامه‌ای کوچک به شدت تحت فشار باشد، در حالی که عدد کل میزبان آن را کم‌رنگ نشان دهد. مشاهده گروه کنترل مرتبط، تصویر نزدیک‌تری از تجربه همان برنامه می‌دهد.
همچنین معنای بعضی خروجی‌ها به نسخه هسته و سطح مشاهده وابسته است. به ویژه درباره full برای CPU نباید فرض یکسانی برای همه نسخه‌ها و دامنه‌ها داشت. وجود فایل و فیلد را در سیستم واقعی بررسی کنید و مستندات همان هسته را مرجع قرار دهید. اگر ابزار جمع‌آوری فیلدی را ندارد، صفر نمایش دادن آن می‌تواند نبود پشتیبانی را با نبود فشار اشتباه کند. در مدل داده پایش، مقدار ناموجود و مقدار صفر باید قابل تفکیک باشند تا هشدارها بر فرض نادرست بنا نشوند.
میانگین‌های زمانی و شمارنده تجمعی
پنجره‌های کوتاه و بلند به پرسش‌های متفاوت پاسخ می‌دهند. پنجره کوتاه برای دیدن جهش ناگهانی مفید است، اما ممکن است نوسان زیادی داشته باشد. پنجره بلند روند پایدار را نشان می‌دهد ولی شروع حادثه را دیرتر منعکس می‌کند. شمارنده تجمعی زمان توقف نیز امکان محاسبه تغییر در یک بازه مشخص را می‌دهد. هنگام ساخت نمودار، واحد و بازه نمونه‌برداری را دقیق ثبت کنید. مقایسه مقدار تجمعی دو میزبان با عمر اجرای متفاوت، بدون تبدیل به نرخ، نتیجه معناداری درباره فشار جاری نمی‌دهد.
اگر جمع‌آورنده دوباره راه‌اندازی شود یا گروه کنترل تازه ساخته شود، شمارنده ممکن است از نقطه تازه شروع شود. منطق محاسبه باید این بازنشانی را بشناسد و اختلاف منفی را به فشار عجیب تبدیل نکند. در آزمایش پایش، خود سرویس جمع‌آوری و برنامه هدف را جدا بازراه‌اندازی کنید و شکل نمودار را ببینید. این آزمون کوچک از هشدارهای کاذب بعد از انتشار جلوگیری می‌کند. نموداری که فقط در حالت بدون تغییر درست است، برای عملیات روزمره کافی نیست.
فشار حافظه پیش از رخداد OOM
کمبود حافظه می‌تواند زمان برنامه را در بازیابی صفحه، انتظار و فعالیت‌های مرتبط مصرف کند، پیش از آنکه فرایندی توسط OOM کشته شود. مشاهده فشار حافظه کمک می‌کند این دوره کندی را ببینیم. با این حال، PSI به تنهایی نمی‌گوید کدام شیء برنامه حافظه را گرفته یا آیا نشت وجود دارد. باید مصرف حافظه، محدودیت گروه کنترل، رفتار swap و معیارهای برنامه را کنار آن قرار دهید. افزایش فشار یک علامت برای بررسی است و تشخیص نهایی نیاز به داده‌های تکمیلی دارد.
برای تمرین امن، روی محیط جدا با محدودیت منابع مشخص، اندازه مجموعه داده یک کار آزمایشی را مرحله‌ای افزایش دهید. زمان پاسخ، مصرف حافظه و فشار را ثبت کنید و پیش از خطر برای میزبان متوقف شوید. هدف مشاهده گذار از کار عادی به رقابت منابع است. نتیجه را به همه سرورها تعمیم ندهید؛ نوع دیسک، swap، الگوی دسترسی و محدودیت‌های هسته اثر دارند. ارزش تمرین در شناخت ترتیب نشانه‌هاست: آیا ابتدا تأخیر زیاد شد، آیا فشار هم‌زمان بالا رفت و آیا هشدار پیش از شکست قابل اقدام بود؟
فشار IO و علت‌های متفاوت آن
فشار IO می‌تواند با ذخیره‌ساز کند، صف طولانی، کار پشتیبان‌گیری یا رقابت چند بار کاری همراه شود. اما عدد فشار نام دیسک خراب را به ما نمی‌دهد. برای محدود کردن مسئله، زمان انتظار دستگاه، نرخ عملیات، حجم خواندن و نوشتن و گروه کنترل برنامه را بررسی کنید. اگر فقط یک برنامه مشکل دارد، شاید الگوی دسترسی یا محدودیت خودش علت باشد. اگر چند برنامه هم‌زمان متاثرند، مسیر مشترک ذخیره‌سازی یا بار میزبان احتمال بیشتری پیدا می‌کند.
یک آزمایش مفید، اجرای کار خواندن کنترل‌شده در کنار سرویس آزمایشی است. بار را به آرامی تغییر دهید و ببینید کدام معیار زودتر کیفیت سرویس را توضیح می‌دهد. سپس همان آزمایش را بدون کار رقیب انجام دهید. از این مقایسه می‌توان برای زمان‌بندی پشتیبان‌گیری یا محدود کردن کارهای کم‌اولویت استفاده کرد. قرار نیست هر جهش IO باعث خرید سخت‌افزار شود؛ گاهی جداسازی زمان اجرا یا تنظیم هم‌زمانی برنامه، فشار را با هزینه کمتر کاهش می‌دهد. انتخاب راه‌حل باید از علت مشاهده‌شده بیاید.
هشدار باید به اقدام مشخص وصل باشد
آستانه ثابت برای همه میزبان‌ها معمولاً مناسب نیست. میزبان پردازش دسته‌ای ممکن است فشار کوتاه را تحمل کند، در حالی که سرویس تعاملی حساس‌تر است. هشدار را با مدت تداوم، دامنه برنامه و اثر بر زمان پاسخ ترکیب کنید. متن هشدار باید بگوید کدام منبع و کدام گروه متاثر است و مشاهده بعدی چیست. پیام کلی «فشار بالا» بدون مسیر بررسی، اپراتور را به تغییر حدسی منابع سوق می‌دهد و به مرور اعتماد به پایش را کم می‌کند.
برای واکنش خودکار، از اقدام کوچک و قابل محدودسازی شروع کنید. مثلاً کاهش هم‌زمانی یک کار کم‌اولویت می‌تواند منطقی‌تر از کشتن فوری فرایند باشد. اگر هر جهش باعث مقیاس یا توقف شود، حلقه واکنش ممکن است نوسان ایجاد کند. فاصله تصمیم‌ها، حداقل مدت مشاهده و سقف اقدام را تعریف کنید. در آزمایش، هم افزایش فشار و هم برگشت به حالت عادی را ببینید. سامانه خودکار باید بداند چه زمانی ظرفیت یا هم‌زمانی را برگرداند، نه اینکه پس از اولین هشدار همیشه در حالت محدود باقی بماند.
محدودیت نتیجه و گزارش یک حادثه
PSI ابزار نسبت دادن زمان توقف به رقابت منبع است، نه اثبات علت تجاری یا نقص کد. اگر زمان پاسخ بالا رفته ولی فشار میزبان پایین است، شبکه، سامانه بیرونی، قفل برنامه یا صف داخلی را بررسی کنید. نبود فشار هم اطلاعات مفیدی است و می‌تواند دامنه جست‌وجو را کوچک کند. در گزارش حادثه، نمودار فشار را با زمان انتشار، تغییر بار و معیار کاربر هم‌زمان کنید. رابطه زمانی قوی به ساخت فرضیه کمک می‌کند، ولی برای اثبات علت بهتر است یک تغییر کنترل‌شده و قابل بازگشت نتیجه را تأیید کند.
داده‌ای که باید پیش از راه‌اندازی مجدد نگه داشت
اگر فشار ناگهان بالا رفت، پیش از بازراه‌اندازی نمونه، زمان، دامنه گروه کنترل، تعداد کارهای فعال و وضعیت محدودیت منابع را ثبت کنید. راه‌اندازی مجدد ممکن است صف یا حافظه موقت را پاک کند و نشانه از بین برود، بدون اینکه علت رفع شده باشد. مقایسه رخدادهای تکراری با همین داده‌ها نشان می‌دهد آیا مسئله به اندازه مجموعه داده، کار زمان‌بندی‌شده یا تغییر محدودیت مربوط است. این ثبت کوتاه به تیم کمک می‌کند رفع موقت نشانه را با حل پایدار مشکل یکی نگیرد.
