وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

چرا برنامه لینوکس ناگهان با خطای Killed متوقف شد؟ تشخیص کمبود حافظه

تشخیص OOM Killer، بررسی گزارش و مصرف حافظه، محدودیت کانتینر و روش‌های ایمن کاهش فشار رم سرور.

انتشار:
توسط تیم فنی نت‌آرام
۶ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله چرا برنامه لینوکس ناگهان با خطای Killed متوقف شد؟ تشخیص کمبود حافظه در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
برنامه‌ای روی سرور در حال اجرا بود و ناگهان متوقف شد. شاید در ترمینال فقط کلمه Killed دیده باشید یا در گزارش سیستم عبارتی مانند Out of memory و Killed process آمده باشد. یکی از علت‌های ممکن این است که سیستم یا محدودیت حافظه یک سرویس با فشار شدید روبه‌رو شده و پردازشی را متوقف کرده است.
هر توقف ناگهانی الزاماً OOM نیست و هر گزارش OOM هم ثابت نمی‌کند همان برنامه علت اصلی افزایش حافظه بوده است. در این راهنما علت را با زمان رخداد و گزارش واقعی تشخیص می‌دهیم و سپس راه‌حل مناسب را انتخاب می‌کنیم؛ بدون خاموش‌کردن کورکورانه حفاظت سیستم.

قدم اول: زمان خطا و اثر آن را یادداشت کنید

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

قدم دوم: دنبال نشانه OOM در گزارش همان زمان بگردید

برای دیدن پیام‌های اخیر کرنل در راه‌اندازی فعلی، این دستور را اجرا کنید:
کد / دستورsudo journalctl -k -b -n 2000 --no-pager | grep -iE 'out of memory|oom-kill|killed process'
این دستور حداکثر بخشی از پیام‌های اخیر کرنل را می‌خواند و خطوط دارای عبارت‌های نمونه را جدا می‌کند. خروجی ممکن است نام پردازش، شناسه و زمان داشته باشد. اگر پیام مرتبط با همان دقیقه را دیدید، چند خط قبل و بعد آن را نیز در گزارش کامل بخوانید؛ ممکن است اطلاعاتی درباره محدودیت یک گروه یا مقدار حافظه وجود داشته باشد. این خروجی را فقط در مسیر امن به فرد مسئول بدهید.
اگر خطی پیدا نشد، نتیجه نمی‌گوید OOM غیرممکن است: ممکن است رخداد در راه‌اندازی قبلی بوده، در ۲۰۰۰ پیام آخر نباشد، ثبت دائمی فعال نبوده یا ابزار دیگری پردازش را متوقف کرده باشد. برای دیدن راه‌اندازی‌های موجود sudo journalctl --list-boots را اجرا کنید. اگر راه‌اندازی قبلی ثبت شده است، مدیر می‌تواند همان دستور را با -b -1 به جای -b اجرا کند. اگر گزارشی نگهداری نشده، با حدس نمی‌توان آن را بازگرداند.
عبارت OOM مربوط به یک کانتینر یا cgroup ممکن است نشان‌دهنده رسیدن همان گروه به محدودیتش باشد، حتی اگر در کل سرور هنوز حافظه آزاد دیده شود. در مقابل، مشکل می‌تواند به فشار حافظه کل سیستم مربوط باشد. نام گروه و پیام‌های اطراف را با تنظیم سرویس مقایسه کنید و از نتیجه‌گیری صرفاً بر اساس یک خط خودداری کنید.

قدم سوم: وضعیت حافظه را الان ببینید

برای دیدن نمای کلی حافظه و swap، اجرا کنید:
کد / دستورfree -h
ستون available تخمینی از حافظه قابل استفاده برای کارهای تازه را نشان می‌دهد؛ مقدار free به‌تنهایی معیار سالم‌بودن یا نبودن حافظه نیست، زیرا لینوکس از حافظه برای کش هم استفاده می‌کند. مقدار فعلی پس از توقف یک برنامه می‌تواند بهتر از لحظه حادثه باشد. بنابراین این خروجی را با نمودار و گزارش زمان رخداد همراه کنید.
برای دیدن پردازش‌های فعلی با مصرف حافظه مقیم بیشتر، دستور زیر مفید است:
کد / دستورps -eo pid,user,rss,comm --sort=-rss | head -n 11
ستون RSS معمولاً بر حسب کیلوبایت گزارش می‌شود و نام پردازش و کاربر را می‌بینید. RSS هر پردازش معیار کامل مصرف اختصاصی آن نیست و جمع ساده آن‌ها به دلیل حافظه مشترک می‌تواند گمراه‌کننده باشد. پردازشی که کرنل متوقف کرده ممکن است دیگر در فهرست فعلی نباشد؛ مصرف آن را باید از لاگ‌ها و مانیتورینگ همان زمان بررسی کنید.
اگر تعداد زیادی کارگر یک سرویس هم‌زمان فعال‌اند، تعداد آن‌ها و حافظه تقریبی هرکدام را کنار RAM واقعی و سایر سرویس‌ها بگذارید. مثلاً اجرای ده کارگر سنگین روی یک VPS کوچک می‌تواند هم‌زمان بیشتر از ظرفیت موجود حافظه بخواهد. این مثال نسخه محاسبه‌شده برای همه سایت‌ها نیست؛ مصرف باید برای برنامه واقعی اندازه‌گیری شود.

قدم چهارم: محدودیت سرویس یا کانتینر را جداگانه ببینید

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

قدم پنجم: متناسب با علت، فشار را کم کنید

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

چطور مطمئن شویم مشکل برطرف شده است؟

کار متوقف‌شده را پس از کاهش خطر، در اندازه کوچک‌تر و زمان مناسب اجرا کنید. هم‌زمان مقدار حافظه قابل استفاده، مصرف برنامه، وضعیت سرویس و گزارش‌های جدید را زیر نظر بگیرید. موفق‌شدن یک بار اجرای سبک، تضمین پایداری در بار واقعی نیست؛ دوره پرترافیک و نمودارهای بعدی را نیز کنترل کنید.
اگر مشکل تکرار شد، زمان دقیق، نسخه سیستم، گزارش OOM بدون اطلاعات حساس، مقدار RAM و محدودیت سرویس را به مدیر یا پشتیبانی بدهید. برای انتخاب سرویس، صفحه سرور مجازی ایران نت‌آرام مشخصات پلن‌ها را نشان می‌دهد؛ اندازه مناسب باید بر اساس بار واقعی برنامه تعیین شود.
اشتراک‌گذاری:
لینکدینتلگرامایکس

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام