Имею 4 фильерных головки NetApp 2240-4. Это одно шасси, «кластер в коробке», то есть два отдельных блока.
За последние несколько дней, примерно в одно и то же время - все они начали регистрировать МНОГО точек согласованности отметок низкого уровня воды.
Бег wafl_susp -w
дает мне cp_from_low_water
ускорение 10 / сек и более. До этого они были почти полностью cp_from_timer
со скоростью 1 каждые 10 секунд или около того.
Два моих ящика перестали отвечать и были перезагружены, и проблема снова исчезла. Я не уверен на 100%, что это связано, но это кажется разумной ставкой на виновника.
Два других - это полностью простаивать, так как у них есть и базовая ОС, и пара вфилеров - и больше ничего. Но все же - низкий водяной знак, говорит о том, что им по какой-то причине не хватает памяти. Я могу только предположить, что происходит какое-то состояние отказа в обслуживании (возможно, «неудачный вход по SSH»?).
Может ли кто-нибудь дать представление о том, как решить эту проблему? В частности, с точки зрения NetApp, я ищу несколько подсказок, как извлечь то, что занимает мою память.
Открыть билет - это признак того, что есть нехватка системной памяти, и если мало что делается, а ящики по-прежнему не отвечают, происходит что-то странное. Раньше я проходил через процесс проверки использования внутренней памяти с поддержкой на линии, но это не то, что клиенты должны делать сами. Вам нужно будет использовать priv set
команда и проверьте запущенные процессы.
Открыто дело с продавцом о проблеме.
CP с низким уровнем воды являются результатом истощения памяти: (Ссылка производителя)
CP, вызванный низкой отметкой воды; объем памяти, доступный для рутинных служебных задач, достаточно мал, поэтому идеально подходит для запуска CP, чтобы освободить еще несколько
Для взаимодействия с поставщиком мы запустили perfstat - загружаемый инструмент NetApp, который позволяет отправлять информацию о поддержке, относящуюся к производительности. Это привело нас к ошибке ID 697790 (Требуется вход в систему поддержки), присутствует в версии кода, в которой мы работали, исправлено в ONTAP 8.2.3
В частности, утечка памяти в конкретном случае, когда аутентификация LDAP не удалась. Поскольку все 4 хоста использовали одну и ту же учетную запись, и из-за того, что в какой-то момент сработала блокировка, все они до абсурда часто выходили из строя. (И в первую очередь это были системы с очень низким объемом памяти).
Я просмотрел другие системы, в которых присутствовала эта ошибка, и есть некоторые признаки того, что это происходит, но даже в системах с временем безотказной работы 700+ дней возникло незначительное количество.
В целом (с оговоркой, что команды 'diag' потенциально опасны в использовании, поэтому следует выполнять их с особой осторожностью, не обращаясь к поставщику) - мы могли бы определить проблему, посмотрев на mem_stat
- второй столбец - это «байты» и ищите «sasl».
1306719 5268691008 maytag.ko::sasl_client_new+149
Я не знаю, на каком уровне возникает проблема - жду, пока система снова выйдет из строя, чтобы проверить. Но я бы предположил, что использование памяти превышает 5%, вам следует подумать о том, чтобы принять меры. Исправляет перезагрузка и обновление кода.
Сейчас я фиксирую cp_types и объем памяти как часть моего режима мониторинга, поэтому я могу наблюдать, как это происходит. Также будьте более активны в обнаружении блокировки учетной записи LDAP.