У меня есть сервер godaddy, который периодически перестал отвечать. Было сложно устранить неполадки, потому что я не могу подключиться к нему по ssh, когда он перестает отвечать. Я понял, что происходит, добавив задание cron, которое передавало вывод «сверху» в файлы журнала каждые 5 минут. В следующий раз, когда я выключил и снова включил его после того, как он перестал отвечать, я проверил эти журналы и обнаружил, что барабан был исчерпан, но своп в основном не использовался.
Я работаю над сокращением использования оперативной памяти двумя серверами приложений на этом компьютере (оказывается, открывалось слишком много соединений. Каждый из них использовал 30 м, поэтому после открытия 40 на сервере заканчивается оперативная память), но что я Я действительно хотел бы знать, как убедиться, что я могу подключиться к машине по ssh.
Если файл подкачки не заполнен, я бы подумал, что у сервера будет достаточно места для ответа, даже если он будет делать это так медленно. Есть ли способ зарезервировать немного оперативной памяти, чтобы я всегда мог подключиться к машине по ssh?
Вот пример того, как это выглядит, когда сервер работает нормально:
top - 15:13:21 up 3:12, 2 users, load average: 0.15, 0.30, 0.33
Tasks: 127 total, 1 running, 126 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.4%us, 1.8%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 2064980k total, 1611252k used, 453728k free, 45852k buffers
Swap: 2096472k total, 0k used, 2096472k free, 790212k cached
Вот последний главный журнал, который был зарегистрирован перед остановкой сервера:
top - 14:45:08 up 15:20, 0 users, load average: 0.27, 0.16, 0.10
Tasks: 141 total, 2 running, 139 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.7%us, 1.9%sy, 0.0%ni, 95.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2064980k total, 2007652k used, 57328k free, 60496k buffers
Swap: 2096472k total, 100k used, 2096372k free, 689584k cached
Обратите внимание, что задание cron, регистрирующее «верхний» вывод, также перестает работать, когда на сервере заканчивается оперативная память, поэтому, по-видимому, весь сервер просто останавливается.
У меня были подобные проблемы раньше, и их может быть неудобно отслеживать. Поскольку вы предоставили много информации, мне придется рассказать о некоторых вещах, которые нужно проверить, а также о том, в чем оказалась моя проблема.
Сначала проверьте свои журналы. В частности, в этом случае вывод команды dmesg (это кольцевой буфер ядра, куда он выгружает данные журнала). Это периодически сбрасывается в файл (ы) в / var / log, хотя где именно зависит от вашей ОС. Например, в Red Hat есть файл / var / log / dmesg. Вы ищете все, что выглядит необычно, особенно в том, что касается убийца OOM обработать. Это завершает программы, когда ОЗУ начинает заполняться, чтобы сервер оставался работоспособным и быстро реагировал. sshd должен быть освобожден от этого, но это зависит от дистрибутива относительно того, как он установлен. Современная форма определения исключения OOM - дать sshd оценку, показывающую ядру, насколько он ценен для сервера в целом (что должно поместить его в конец списка процессов, которые необходимо уничтожить в случае возникновения критической ситуации с ОЗУ). Ваш дистрибутив должен был установить это правильно.
Еще нужно проверить, что у вашего сервера достаточно энтропии со следующим:
cat /proc/sys/kernel/random/entropy_avail
Нормальное значение выше примерно 1000-1500. Ниже и ваш на исходе. На моих машинах он действительно достигает примерно 4000-5000 (это основано на моих наблюдениях за моими серверами).
У меня были проблемы со входом на серверы, на которых энтропия была настолько низкой (и генерация была медленной), что приложения зависали, ожидая, когда станет доступно больше энтропии. На это указывает печально известная ошибка Debian Exim. Exim использовал GNU TLS в Debian, который использовал только / dev / random и использовал массу энтропии для каждого соединения. Видеть Вот. Когда энтропия исчерпывалась, Exim просто зависал. Это также приведет к тому, что другие программы, которые полагаются на энтропию, также начнут отказываться от соединений.
Поскольку ключи сеанса генерируются каждый сеанс, sshd нужен хороший источник случайных чисел. Хотя он должен использовать / dev / urandom для сбора псевдослучайных чисел, если / dev / random блокируется, я не уверен, будет ли это делать sshd.
Эта проблема может быть довольно серьезной для виртуальных систем, так как многие источники случайных чисел не передаются на виртуальную машину. Основным источником энтропии является дисковый ввод-вывод, но обычно он не передается в виртуальную машину. Аппаратные генераторы случайных чисел, которые могут быть встроены в набор микросхем / ЦП физической машины, также вряд ли будут переданы в виртуальную машину.
это - довольно хорошая статья по этому поводу.
я бегу rngd в фоновом режиме на моем сервере для подачи / dev / random данными из / dev / urandom с помощью этого:
rngd -r /dev/urandom -o /dev/random
Это не лучшее решение, но полезный прием, чтобы держать вещи вместе, пока вы ищете лучшие источники случайных чисел. Я ищу кормление rngd с данными из другого источника, но пока у нас не было возможности сделать это.