Що може призвести до того, що ВСІ сервіси на сервері знизяться, але все ще реагують на ping? і як розібратися


9

У мене траплялося вже двічі протягом декількох днів, коли мій сервер повністю вийшов з ладу, тобто http, ssh, ftp, dns, smtp, в основному ВСІ сервіси перестають реагувати, як ніби сервер був вимкнений, за винятком того, що він все ще відповідає ping , що саме мене найбільше стримує.

У мене є кілька скриптів для php, які викликають величезне навантаження (процесор і пам'ять) на сервер за коротких поривів, які використовує невелика група користувачів, але зазвичай сервер "виживає" чудово підходить до цих сплесків, і коли він знижується ніколи не збігаються з такими піками використання (я не кажу, що це не може бути пов'язано, але це не відбувається відразу після них).

Я не прошу вас, щоб ви магічно змогли сказати мені остаточну причину цих збоїв, моє запитання: чи існує єдиний процес, смерть якого може призвести до того, що всі ці служби одночасно знизяться? Найсмішніше, що всі мережеві сервіси знижуються, крім ping. Якщо на сервері 100% з'їденого процесора якимось процесом, він також не відповів би на ping. Якщо apache вийшов із-за (наприклад) зламаного скрипта php, це вплине лише на http, а не на ssh та dns .... тощо.

Моя ОС - Cent OS 5.6

Найголовніше, після жорсткого перезавантаження сервера, які системні журнали слід переглянути? / var / log / messages не виявляє нічого підозрілого.

Відповіді:


8

( tl; dr. все ще відповідає ping - це очікувана поведінка, перевірте використання пам'яті)

ICMP-запити ехо (тобто ping) обробляються мережевим стеком в ядрі, без іншої залежності.

Ядро відоме як "резидент пам'яті", а це означає, що воно завжди буде зберігатися в оперативній пам'яті, і його не можна поміняти на диск, як звичайний додаток.

Це означає, що в ситуаціях, коли у вас не вистачає фізичної пам'яті, програми замінюються на диск, але ядро ​​залишається там, де воно є. Коли фізична та обмінна пам'ять заповнені (і система не може довго управляти вашими програмами), машина перевалиться. Однак оскільки: а) ядро все ще зберігається в пам'яті і б) воно може відповідати на запити ping без допомоги нічого іншого, система продовжуватиме відповідати на ping, незважаючи на те, що все померло.

Що стосується вашої проблеми, я сильно підозрюю проблеми пам'яті. Встановіть "sysstat" і скористайтеся командою "sar", щоб побачити журнал пам'яті / cpu / load / io навантаження і т. Д. Я б очікував, що під час аварії ви побачите як 100% фізичний, так і swap.

Я б також розглядав можливість dmesg або / var / log / повідомлень для будь-яких ознак вбивці OOM (вбивця поза пам'яттю). Це надзвичайна система ядра, яка почне вбивати процеси у випадку вичерпання пам'яті. Його ефективність багато в чому залежить від того, які процеси вбиваються. Один процес з’їдання пам’яті буде ефективно знищений і звільнений від пам’яті, однак веб-сайт, заснований на апашах, породжує процеси заміни, як тільки вбитий дочірній процес.


+1 для OOM Killer
HTTP500

Дякую велике, я майже впевнений, що це проблема, оскільки і оперативна пам’ять, і своп були повними до відмови сервера. (Я можу бачити статистику менеджера ovh). І це, мабуть, деякі мої шалені сценарії PHP, що використовують багато пам'яті. Однак це загадує мене з кількох причин. (1) схоже, що пам'ять, з'їдена php, не звільняється згодом, але це не має сенсу; (2) у будь-якому випадку я не очікував, що належна операційна система повністю загине лише через один (або навіть декілька) процесів, що використовують занадто багато пам'яті ... Я б очікував цього
маттео

відмовляйтеся виділяти пам'ять програмам, які просять її, коли недостатньо оперативної пам’яті, щоб система нормально працювала ... Я маю на увазі помилку або навіть шкідливу програму ніколи не зможе знищити всю систему ...
matteo

3
@matteo Linux має те, що він називає "overcommit": лише тому, що ви malloc()1 ГБ оперативної пам’яті, насправді не означає, що ви його будете використовувати, тому менеджер пам'яті відстежує, скільки пам'яті думає ваша програма і скільки пам'яті Програма фактично використовується, і вона справді працює добре, більшу частину часу. Принаймні, поки більш ніж одна програма фактично не хоче використати всі 1GB, які вона вважає.
DerfK

1
@matteo Я не бачу жодних ознак, що це проблема OOM. Зазвичай вбивця OOM вибирає конкретні або процеси, які відповідають певним критеріям, але це не завжди вбиває демона, як ssh. Це безумовно на стороні вводу / виводу. Ви не пояснили ситуацію / характеристики вашої апаратури, як я просив у своїй відповіді.
ewwhite

5

Зазвичай це проблема вводу / виводу або дискової підсистеми. Часто це буде поєднуватися з надзвичайно високим середнім завантаженням системи. Наприклад, система, детальна на наведеному нижче графіку, стала невідповідною (поки вона була pingable), коли скрипт не поспішав, заблокував купу файлів і завантаження збільшилося до 36 ... у системі 4-ЦП.

введіть тут опис зображення

Служби, які працюють в оперативній пам’яті та не потребують доступу до диска, продовжують працювати ... Таким чином, мережевий стек (ping) працює, але інші служби зупиняються, коли потрібен доступ до диска ... SSH, коли на ключ посилається або необхідний пошук пароля. SMTP, як правило, вимикається, коли середнє навантаження становить 30 або близько ...

Коли система перебуває в такому стані, спробуйте пульт дистанційного керування nmapпроти IP-адреси сервера, щоб побачити, що відбувається.

Ваш імовірний журнал, ймовірно, не працює, якщо це проблема з диском або сховищем ...

Чи можете ви описати налаштування обладнання? Це віртуальна машина? Що таке макет зберігання?

Більше, ніж ведення журналу, ви хочете побачити, чи можете ви графікувати продуктивність системи та розуміти, коли це відбувається. Подивіться, чи це стосується конкретної діяльності.


Припустимо, це проблема, чи є спосіб сказати SSH зберігати пароль (и) в пам'яті, так що навіть якщо сервер знаходиться в такому стані, я, принаймні, зможу увійти в нього через ssh і виконати деякі команди, щоб побачити що відбувається?
Маттео

1
Якщо це введення-виведення, вам потрібно перейти до нижньої частини випуску. Якщо це час очікування дискового масиву або взаємодія з драйвером, це відрізняється від сценарію, який виконує погано або проблеми з вмістом ресурсів.
ewwhite
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.