محتوای آموزشی وبلاگ نت‌آرام
نمودار RAM تقریباً پر است؛ آیا باید پلن سرور مجازی را ارتقا داد؟ به‌تنهایی نمی‌توان از این نمودار نتیجه گرفت. مسئلهٔ مهم این است که برنامه به خاطر فشار حافظه منتظر می‌ماند، از محدودیت حساب عبور می‌کند یا صرفاً از حافظه برای کش استفاده شده است.
در این راهنما، یک بررسی کم‌هزینه و فقط خواندنی انجام می‌دهیم. هدف یافتن ارتباط بین کندی کاربر و کمبود منبع است؛ نه ساختن یک عدد جادویی برای خرید RAM.
PSI چه چیزی را نشان می‌دهد؟
در لینوکسِ دارای پشتیبانی PSI، فایل‌های مسیر کد / دستور
/proc/pressure/ سهم زمان انتظار ناشی از فشار CPU، حافظه و I/O را گزارش می‌کنند. در خروجی، some انتظار حداقل بخشی از کارها و full انتظار هم‌زمان همهٔ کارهای غیر‌بیکار را توصیف می‌کند؛ تفسیر CPU در سطح کل سیستم استثنا دارد.اعداد
avg10، avg60 و avg300 درصد زمان در پنجره‌های اخیر هستند. این اعداد درصد RAM مصرف‌شده یا تعداد درخواست‌های ناموفق نیستند. مستندات رسمی PSI در کرنل لینوکسنمونهبرداری کوتاه هنگام کندی
در ترمینال لینوکس، دستورهای زیر فقط وضعیت را می‌خوانند. اگر فایل PSI وجود نداشت یا مجوز کافی نبود، خروجی را «ناموجود» ثبت کنید؛ نبودن داده به معنی نبودن فشار نیست.
کد / دستورdate -Is
free -m
cat /proc/pressure/memory
cat /proc/pressure/io
cat /proc/pressure/cpu
vmstat 1 10
ردیف نخست
vmstat خلاصه‌ای از گذشته است و با نمونه‌های یک‌ثانیه‌ای بعدی یکسان تفسیر نمی‌شود. زمان خروجی را کنار یک رخداد واقعی مانند بازکردن صفحهٔ مدیریت یا پاسخ API بنویسید. یک بار در حالت عادی و یک بار در زمان بروز مشکل نمونه بگیرید.این بررسی بنچمارک نیست و بار مصنوعی ایجاد نمی‌کند. اگر کندی کوتاه و پراکنده است، نمونهٔ ده‌ثانیه‌ای ممکن است آن را نگیرد؛ دادهٔ پایش تاریخی لازم می‌شود.
نمونهٔ فرضی: RAM کم یا کار هم‌زمان زیاد؟
فرض کنیم دو نمونه داریم. در زمان عادی، درخواست جست‌وجو سریع است و فشار حافظه ناچیز. هنگام تولید گزارش شبانه، فشار حافظه بالا می‌رود، فعالیت Swap بیشتر می‌شود و همان جست‌وجو کند می‌شود.
این هم‌زمانی یک سرنخ است، نه اثبات علت. آزمایش بعدی می‌تواند جابه‌جایی زمان گزارش در محیط کنترل‌شده باشد. اگر با ثابت‌ماندن ترافیک و نسخهٔ برنامه، مشکل برطرف شد، جداسازی یا محدودکردن کار پس‌زمینه ارزش بررسی دارد. اگر حتی بدون گزارش، فشار و تأخیر تکرار شوند، افزایش حافظه یکی از گزینه‌هاست.
در مقابل، اگر فشار I/O بالا می‌رود ولی فشار حافظه پایین است، صرفاً خرید RAM بیشتر ممکن است مسئله را حل نکند. سرعت ذخیره‌سازی، نوع عملیات و انتظار دیتابیس را هم باید بررسی کرد.
محدودیت داخل کانتینر را فراموش نکنید
گاهی میزبان حافظهٔ آزاد دارد ولی برنامه در یک گروه محدود اجرا می‌شود. در cgroup v2، فایل‌هایی مانند
memory.max، memory.current و memory.events به شناخت محدودیت و رخدادهای همان گروه کمک می‌کنند. مسیر دقیق گروه به نحوهٔ اجرای برنامه وابسته است؛ عدد ریشهٔ سیستم را جای عدد سرویس خود نگذارید.رخداد OOM در گروه می‌تواند مستقل از وضعیت کل میزبان باشد. در چنین محیطی، ابتدا محدودیت مؤثر برنامه را با مقدار قراردادی سرویس تطبیق دهید. مرجع کنترل حافظه در cgroup v2
برگهٔ تصمیم برای ارتقا
برای هر رخداد، پنج خانه پر کنید:
- اثر روی کاربر: کدام عملیات، چه مدت و با چه خطایی؟
- زمان و بار: چند درخواست یا کار پس‌زمینه فعال بوده؟
- شاهد منبع: فشار حافظه، I/O، محدودیت گروه یا رخداد OOM؟
- تغییر کنترل‌شده: زمان‌بندی، تعداد Worker یا اصلاح یک Query؟
- نتیجه: تأخیر بهتر شد، بدتر شد یا تغییری نکرد؟
تعداد Worker بیشتر همیشه ظرفیت بیشتر نیست. اگر مجموع حافظهٔ آن‌ها از بودجه عبور کند، نتیجه می‌تواند انتظار و توقف بیشتر باشد. دادهٔ قبل و بعد را با بار مشابه مقایسه کنید؛ تغییر هم‌زمان پلن، افزونه و تنظیمات، علت بهبود را نامعلوم می‌گذارد.
این بررسی به انتخاب VPS چه کمکی می‌کند؟
هنگام مقایسهٔ سرور مجازی ایران یا سرور مجازی آلمان، این برگه روشن می‌کند به چه منبعی نیاز دارید. انتخاب موقعیت شبکه تصمیم دیگری است و باید بر اساس کاربران و وابستگی‌های برنامه انجام شود؛ PSI کیفیت مسیر اینترنت را اندازه نمی‌گیرد.
برای بودجه‌بندی اولیه، راهنمای انتخاب CPU، RAM و NVMe را کنار این آزمایش قرار دهید. نتیجهٔ مناسب ممکن است ارتقای RAM، کاهش هم‌زمانی یک کار سنگین یا اصلاح برنامه باشد. معیار نهایی، بهترشدن عملیات کاربر در بار قابل مقایسه است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام