Назад | Перейти на главную страницу

Сервер не отвечает [закрыт]

Наш сервер базы данных иногда не отвечает. Он работает под управлением полностью обновленной Ubuntu 14.04 LTS. Известными не-ванильными программами, работающими на нем, являются Nimbus, TSM и Oracle.

Примерно раз в день он перестает отвечать, пока в ночное время, когда выполняется ряд задач обслуживания, таких как резервное копирование.

После того, как он перестает отвечать, кажется, что он остается таким навсегда. Я не могу подключиться к нему по SSH, и он не принимает никаких подключений к базе данных.

Странно то, что сервер отвечает на пинг. Если я использую telnet для открытия порта 22 (SSH) или порта 1521 (Oracle), я получаю ответ от сервера. Порт 22 даже сообщает что-то вроде «Это OpenSSH». Но на самом деле использование ssh-клиента или открытие соединения с базой данных просто зависает.

Я искал в лог-файлах и ничего не нашел (dmesg, syslog, auth.log и т. Д.). Также кажется подозрительно малая активность в лог-файлах в период отсутствия ответа. После перезапуска сервера он снова работает.

Моей немедленной реакцией было запустить apt-get update и apt-get dist-upgrade и следить за достижением максимального предела файловых дескрипторов. Однако жесткое ограничение для Oracle далеко от максимума файловой системы, поэтому это кажется странным, если это так. У кого-нибудь еще есть идеи, что может вызвать это?

РЕДАКТИРОВАТЬ: Забыл упомянуть, что ЦП, память и дисковое пространство были далеко от 100%. (Они уже отслеживались, и после того, как это произошло, я также начал отслеживать дескрипторы открытых файлов, но этого еще не произошло). Я также могу добавить, что я не ожидаю, что кто-то назовет точную проблему, но любые идеи относительно дополнительных вещей, которые нужно отслеживать, будут оценены.

Все переменные выглядели вполне нормально. Однако я написал задание cron для вывода даты / времени и файловых дескрипторов каждую минуту и ​​обнаружил, что файловые дескрипторы находятся в пределах нормальных значений. Однако в 3 часа ночи серверные часы внезапно отошли на 2 часа назад (мне потребовалось время, чтобы заметить это из файла журнала), а затем они умерли без каких-либо ошибок в журналах.

Это оказалось проблемой на уровне хостинга / WMWare (что меня не касается). Между прочим, у хоста WMWare было время, которое полностью отключилось. После того, как инфраструктурная компания исправила свою платформу WMWare, она снова заработала нормально.