محتوای آموزشی وبلاگ نت‌آرام
سرور لینوکس بعد از راه‌اندازی مجدد مدت زیادی طول می‌کشد تا سرویس‌ها در دسترس قرار بگیرند. ممکن است شبکه، دیسک، اتصال یک فایل‌سیستم راه دور یا خود برنامه باعث انتظار شده باشد. عدد بالای کنار نام یک سرویس در گزارش، به‌تنهایی ثابت نمی‌کند همان سرویس مقصر اصلی است؛ شاید آن سرویس منتظر وابستگی دیگری مانده باشد.
در این راهنما بدون خاموش‌کردن تصادفی سرویس‌ها، زمان بوت و زنجیره وابستگی را می‌خوانیم. دستورها برای سرور لینوکسی دارای systemd هستند. پیش از هر تغییر در سرور تولیدی، دسترسی کنسول جایگزین، نسخه پشتیبان تنظیمات و زمان مجاز اختلال را آماده کنید.
۱. اندازه تأخیر را مشخص کنید
پس از اتصال SSH یا کنسول، این فرمان‌ها را اجرا کنید:
کد / دستورsystemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain
فرمان اول زمان بخش‌هایی مانند kernel، initrd و userspace را، اگر در سیستم موجود باشد، نشان می‌دهد. این زمان الزاماً به معنی آماده‌شدن کامل همه برنامه‌ها یا پایان کار دیسک نیست. فرمان دوم واحدها را بر اساس زمانی که برای فعال‌شدن ثبت شده مرتب می‌کند. فرمان سوم یک زنجیره مهم تا هدف پیش‌فرض را نمایش می‌دهد.
در
critical-chain عدد بعد از @ زمان رسیدن به آن مرحله و عدد بعد از + مدت ثبت‌شده فعال‌سازی است. سرویس‌ها می‌توانند هم‌زمان اجرا شوند؛ اعداد blame را با هم جمع نکنید. برخی واحدها مثل سرویس‌های Type=simple یا انتظار سخت‌افزار به‌شکل کامل در این گزارش دیده نمی‌شوند. از این خروجی برای انتخاب محل بررسی استفاده کنید، نه برای اعلام قطعی علت.۲. سرویس مشکوک و گزارش همان بوت را ببینید
نام واقعی واحد را به جای
کد / دستورexample.service بگذارید:systemctl status example.service --no-pager -l
systemctl cat example.service
journalctl -b -u example.service --no-pager
systemctl list-units --failed
این دستورها وضعیت، فایل واحد و تنظیم‌های تکمیلی، گزارش همان بوت و واحدهای ناموفق را نشان می‌دهند. پیام‌هایی مثل انتظار شبکه، تلاش تکراری اتصال یا پیدا نشدن یک مسیر را همراه زمان بررسی کنید. گزارش ممکن است نام میزبان و مسیر خصوصی داشته باشد؛ قبل از اشتراک‌گذاری، داده حساس را حذف کنید.
اگر سرور اکنون سریع بوت شده اما دفعه قبل کند بود، گزارش بوت قبلی فقط در صورتی در دسترس است که سیستم آن را نگه داشته باشد:
کد / دستورjournalctl -b -1 -u example.service --no-pager
نبودن گزارش بوت قبلی به معنی نبود مشکل نیست. برای دیدن وابستگی‌ها از
systemctl list-dependencies example.service استفاده کنید؛ وابستگی نمایش‌داده‌شده لزوماً به معنی علت تأخیر نیست.اگر برنامه خودش دیر آماده می‌شود، زمان ثبت‌شده شروع آن را با گزارش داخلی برنامه مقایسه کنید. مثلاً اتصال ناموفق به پایگاه داده ممکن است چند بار با فاصله تکرار شود؛ در این حالت اصلاح آدرس، مجوز یا آماده‌بودن پایگاه داده در محیط آزمایشی از تغییر زمان‌بندی تصادفی مفیدتر است. وابستگی‌های
After و Requires وظیفه یکسانی ندارند و تغییر آن‌ها بدون شناخت رفتار واحد می‌تواند ترتیب شروع را خراب کند. ابتدا تنظیم فعلی و نسخه قابل بازگشت را نگه دارید.۳. اگر زنجیره به انتظار شبکه می‌رسد
واحدی مانند
کد / دستورnetwork-online.target یا سرویس انتظار شبکه ممکن است منتظر آماده‌شدن رابطی باشد که وجود ندارد یا تنظیمش کامل نشده است. ابتدا نام رابط‌های واقعی و وضعیت آن‌ها را ببینید:ip -brief address
systemctl status network-online.target --no-pager
سپس گزارش مدیر شبکه مورد استفاده همان سیستم را بخوانید. تنظیم AlmaLinux، Ubuntu و NetworkManager می‌تواند متفاوت باشد. اگر یک رابط غیرفعال یا پیکربندی قدیمی باعث انتظار است، تنظیم آن را بر اساس نقش واقعی سرور اصلاح و در محیط آزمایشی بسنجید.
غیرفعال‌کردن سرویس انتظار به صورت کلی ممکن است برنامه یا فایل‌سیستم شبکه‌ای را پیش از آماده‌شدن اتصال اجرا کند. قبل از هر تغییر، وابستگی سرویس‌های دیگر و راه بازگشت از کنسول را بشناسید.
۴. اگر تأخیر مربوط به دیسک یا فایل‌سیستم است
خطاهای mount و شناسه دستگاه را در گزارش همان بوت ببینید:
کد / دستورjournalctl -b -p warning --no-pager
findmnt --verify
df -h
findmnt --verify تنظیمات فایل‌سیستم را بررسی می‌کند؛ خروجی و گزینه‌های آن در نسخه‌های مختلف ممکن است تفاوت داشته باشد. مسیر شبکه‌ای در دسترس‌نبودنی، UUID اشتباه یا خطای دیسک می‌تواند علت انتظار باشد. هر UUID را با دستگاه واقعی و نسخه پشتیبان تنظیمات تطبیق دهید. ویرایش شتاب‌زده fstab می‌تواند بوت بعدی را متوقف کند؛ برای UUID اشتباه راهنمای Emergency Mode را بخوانید.۵. اصلاح را با بوت کنترل‌شده تأیید کنید
پس از رفع علت مشخص، وضعیت فعلی سرویس و عملکرد سایت را آزمایش کنید. اگر برای تأیید بوت دوباره لازم است، ابتدا از کاربران و سرویس‌های وابسته اطلاع داشته باشید و زمان کم‌ترافیک و دسترسی کنسول را آماده کنید. پس از بوت، سه دستور اول را تکرار و زمان و عملکرد واقعی سرویس را با قبل مقایسه کنید. کوتاه‌شدن یک عدد بدون آماده‌شدن برنامه نتیجه کافی نیست.
برای رسیدگی تخصصی مدیریت سرور نت‌آرام و برای محدودیت‌های اندازه‌گیری مستندات systemd-analyze را ببینید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام