محتوای آموزشی وبلاگ نت‌آرام
در زمان اوج، اتصال‌های تازه به سرور دیر برقرار می‌شوند یا برخی کاربران خطای اتصال می‌بینند، در حالی که اتصال‌های قدیمی هنوز کار می‌کنند. یکی از علت‌های ممکن پر شدن صف پذیرش یک سوکت شنونده است: درخواست‌ها رسیده‌اند، اما برنامه با سرعت کافی آن‌ها را تحویل نمی‌گیرد.
این فقط یکی از علت‌های کندی شبکه است. DNS، فایروال، ظرفیت برنامه و مسیر ارتباط نیز می‌توانند دخیل باشند. با چند مشاهده در زمان مشکل، شواهد مربوط به صف را جمع می‌کنیم و بعد میان اصلاح برنامه، ظرفیت و تنظیم محدودیت تصمیم می‌گیریم.
۱. سوکت و پورت واقعی را پیدا کنید
با SSH یا کنسول وارد سرور لینوکس شوید. اگر برنامه روی پورت نمونه
کد / دستور443 گوش می‌دهد:ss -lnt 'sport = :443'
sudo ss -lntp 'sport = :443'
پورت را با پورت واقعی عوض کنید. فرمان اول سوکت‌های TCP شنونده را نشان می‌دهد؛ فرمان دوم در صورت داشتن مجوز، اطلاعات پردازش مالک را نیز نمایش می‌دهد. روی سرورهای دارای چند آدرس یا سوکت، سطر درست را از ستون آدرس محلی پیدا کنید. اگر چیزی دیده نشد، ممکن است سرویس روی پورت یا فضای شبکه دیگری باشد.
در خروجی
ss برای سوکت LISTEN، Recv-Q تعداد اتصال‌های پذیرفته‌شده‌ای است که هنوز منتظر تحویل به برنامه هستند و Send-Q سقف صف گزارش‌شده را نشان می‌دهد. این برداشت برای سطر شنونده است؛ همان ستون‌ها در اتصال برقرارشده معنی متفاوتی دارند. یک عکس لحظه‌ای هنگام نبود ترافیک معمولاً کافی نیست.۲. در زمان مشکل چند نمونه بگیرید
همان
کد / دستورss -lnt را در چند لحظه نزدیک به زمان کندی اجرا و عددها را یادداشت کنید. اگر Recv-Q بارها نزدیک سقف می‌رسد، کندشدن پذیرش اتصال محتمل است. سپس در صورت وجود ابزار nstat، شمارنده‌های مربوط را ببینید:nstat -a | grep -E 'TcpExtListenOverflows|TcpExtListenDrops'
دو مقدار را یادداشت کنید، کمی بعد در همان شرایط دوباره بخوانید و اختلاف را حساب کنید. این شمارنده‌ها معمولاً تجمعی و مربوط به فضای شبکه‌اند، نه لزوماً فقط پورت انتخاب‌شده. افزایش آن‌ها همراه با صف پر، شاهد مهمی است اما به تنهایی نام برنامه مسئول یا علت ریشه‌ای را ثابت نمی‌کند. اگر
nstat نصب نیست، مدیر سرور می‌تواند از ابزارهای موجود همان توزیع استفاده کند.۳. چرا برنامه اتصال را دیر تحویل می‌گیرد؟
وضعیت سرویس و گزارش همان بازه را ببینید:
کد / دستورsystemctl status example.service --no-pager
journalctl -u example.service --since '15 minutes ago' --no-pager
نام واقعی سرویس را جایگزین کنید. اگر برنامه هم‌زمان به پایگاه داده کند وصل می‌شود، کارگرها قفل می‌شوند یا پردازش سنگینی روی نخ اصلی انجام می‌دهند، ابتدا همان گلوگاه را در نسخه آزمایشی برطرف کنید. اگر موج درخواست از ظرفیت واقعی بیشتر است، محدودیت نرخ مناسب، افزایش سنجیده کارگرها یا ظرفیت بیشتر ممکن است لازم شود؛ هر انتخاب باید با حافظه و توان سرویس سازگار باشد.
اگر صف فقط هنگام یک جهش کوتاه پر می‌شود و پس از آن برنامه سریع تخلیه‌اش می‌کند، یک صف بزرگ‌تر ممکن است به جذب همان جهش کمک کند. اگر صف مدام پر است، بالا بردن عدد فقط زمان انتظار و مصرف منابع را بیشتر می‌کند و جای حل کندی را نمی‌گیرد.
۴. محدودیت‌ها را پیش از تغییر مقایسه کنید
somaxconn سقف سیستم برای backlog درخواستی برنامه را محدود می‌کند:sysctl net.core.somaxconn
برنامه یا وب‌سرور نیز هنگام
listen() اندازه‌ای درخواست می‌کند؛ افزایش مقدار سیستم به‌تنهایی الزاماً اندازه سوکت موجود را زیاد نمی‌کند. تنظیم backlog هر برنامه و نسخه آن را در مستنداتش پیدا کنید. صف اتصال‌های کامل و صف مربوط به handshakeهای ناقص را یکی فرض نکنید؛ tcp_max_syn_backlog کاربرد مرتبط اما متفاوتی دارد.اگر مدیر سرور پس از اندازه‌گیری، افزایش سقف را مناسب تشخیص دهد، مقدار قبلی را ثبت و ابتدا در محیط آزمایشی با عدد متناسب آزمایش کند. برای مثال، فقط اگر مقدار فعلی کمتر از
کد / دستور512 و این عدد برای سرویس تأیید شده باشد:sudo sysctl -w net.core.somaxconn=512
این تنظیم سراسری و موقت است و ممکن است برای سوکت از قبل ساخته‌شده کافی نباشد. تغییر تنظیم برنامه یا ساخت دوباره سوکت می‌تواند نیاز به راه‌اندازی کنترل‌شده سرویس داشته باشد و کاربران را قطع کند. برای بازگشت، عدد قبلی ثبت‌شده را با همان کلید بازگردانید. تنظیم پایدار و اثر سایر فایل‌های sysctl را با سیاست توزیع بررسی کنید. گزینه‌هایی مثل
tcp_abort_on_overflow را کورکورانه فعال نکنید؛ ممکن است به اتصال کاربران آسیب بزنند.۵. بعد از اصلاح نتیجه را اندازه بگیرید
در بار مشابه و مجاز، صف و اختلاف شمارنده‌ها را دوباره مشاهده کنید. هم‌زمان زمان پاسخ واقعی و نرخ خطای کاربران را بسنجید. اگر شمارنده همچنان زیاد می‌شود، پردازش و ظرفیت را دوباره بررسی کنید. برای تفاوت کندی شبکه و بازفرست بسته‌ها، راهنمای TCP Retransmission و برای کمک تخصصی مدیریت سرور نت‌آرام را ببینید. شرح سقف سیستم در مستندات کرنل لینوکس آمده است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام