Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Цеф MDS поймал OOM по выходным.

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Цеф MDS поймал OOM по выходным., Proxmox Виртуальная Среда
     
    k4y53r
    Guest
    #1
    0
    28.04.2025 10:21:00
    Привет, у меня кластер PVE из 4 узлов с развернутым CephFS, и последние пару месяцев я сталкиваюсь с ситуациями, когда MDS умирают из-за нехватки памяти (OOM kills), а иногда MDS переключаются на другие узлы и зависают в статусе clientreplay, после чего мне приходится перезапускать MDS, чтобы получить доступ к CephFS со всех клиентов. Я проверял запланированные задания и syslog Ceph, но не могу понять, какое задание может использовать всю доступную память на узле, поэтому не знаю, где искать решение этих проблем.

    Кластер состоит из 4 узлов, 2 с 96 ГБ ОЗУ и 2 с 192 ГБ ОЗУ, все с 24 ядрами Intel® Xeon® CPU X5675 @ 3.07GHz (2 сокета). PVE все еще на 7.3.3, а версия Ceph 17.2.5.

    Есть 2 пула Ceph: FAST с дисками NVMe (2 диска / OSD 2 ТБ на узел) и SLOW с HDD-дисками (2 диска / OSD 2 ТБ на узел). Только на пуле FAST работает 1 CephFS с 2 активными MDS и еще 2 MDS в режиме ожидания. Такая конфигурация была сделана после некоторых проблем с одним MDS, чтобы критические службы, развернутые на CephFS, продолжали работать в случае сбоя MDS без автоматического восстановления.

    Эти ошибки возникают в основном по выходным, начиная с пятницы вечером и до понедельника утром (сейчас отключены резервные копии в PBS по выходным).

    Код: -- Журнал начинается с Пт 28.10.2022 12:19:59 CEST, заканчивается в Пн 28.04.2025 08:51:01 CEST. --
    25.04 00:00:00 zpveo1 ceph-mds[782250]: 2025-04-25T00:00:00.080+0200 7f8d3c47c700 -1 получил сигнал: Hangup от killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror (PID: 3615629) UID: 0
    25.04 00:00:00 zpveo1 ceph-mds[782250]: 2025-04-25T00:00:00.104+0200 7f8d3c47c700 -1 получил сигнал: Hangup от (PID: 3615630) UID: 0
    25.04 23:55:34 zpveo1 systemd[1]: ceph-mds@zpveo1.service: Процесс этой единицы был завершен OOM killer.
    25.04 23:55:38 zpveo1 systemd[1]: ceph-mds@zpveo1.service: Основной процесс завершился, код=killed, статус=9/KILL
    25.04 23:55:38 zpveo1 systemd[1]: ceph-mds@zpveo1.service: Неудалось с результатом 'oom-kill'.
    25.04 23:55:38 zpveo1 systemd[1]: ceph-mds@zpveo1.service: Использовано 1d 1h 11min 37.806s времени работы ЦП.
    25.04 23:55:38 zpveo1 systemd[1]: ceph-mds@zpveo1.service: Запланирована перезапуск задания, счетчик перезапусков равен 7.
    25.04 23:55:38 zpveo1 systemd[1]: Остановил демон метаданных Ceph.
    25.04 23:55:38 zpveo1 systemd[1]: ceph-mds@zpveo1.service: Использовано 1d 1h 11min 37.806s времени работы ЦП.
    25.04 23:55:39 zpveo1 systemd[1]: Запущен демон метаданных Ceph.
    25.04 23:55:39 zpveo1 ceph-mds[794009]: starting mds.zpveo1 at
    26.04 00:00:00 zpveo1 ceph-mds[794009]: 2025-04-26T00:00:00.091+0200 7f8bc83c9700 -1 получил сигнал: Hangup от killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror (PID: 798340) UID: 0
    26.04 00:00:00 zpveo1 ceph-mds[794009]: 2025-04-26T00:00:00.127+0200 7f8bc83c9700 -1 получил сигнал: Hangup от (PID: 798341) UID: 0
    27.04 00:00:00 zpveo1 ceph-mds[794009]: 2025-04-27T00:00:00.097+0200 7f8bc83c9700 -1 получил сигнал: Hangup от killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror (PID: 2171840) UID: 0
    27.04 00:00:00 zpveo1 ceph-mds[794009]: 2025-04-27T00:00:00.121+0200 7f8bc83c9700 -1 получил сигнал: Hangup от (PID: 2171841) UID: 0
    28.04 00:00:00 zpveo1 ceph-mds[794009]: 2025-04-28T00:00:00.074+0200 7f8bc83c9700 -1 получил сигнал: Hangup от killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror (PID: 3543923) UID: 0
    28.04 00:00:00 zpveo1 ceph-mds[794009]: 2025-04-28T00:00:00.127+0200 7f8bc83c9700 -1 получил сигнал: Hangup от (PID: 2171841) UID: 0
    В каждом пике памяти происходит событие OOM kill на узле, и большую часть ОЗУ использует MDS.
    Я пытался ограничить использование памяти, но безуспешно.

    Некоторые скриншоты прикреплены:
    [Изображение]
    [Изображение]
    [Изображение]
    [Изображение]
    [Изображение]

    Я проверил документацию по Ceph, но не нашел никаких подсказок о корневой причине. В документации есть ссылки на возможную утечку памяти в Ceph, но нет информации о том, как ее проверить. Есть какие-нибудь идеи?

    Заранее спасибо!
     
     
     
    Maximiliano
    Guest
    #2
    0
    28.04.2025 12:01:00
    Привет, k4y53r! Похоже, сервис отключился, потому что у хоста не хватает памяти для текущей нагрузки – судя по графикам, он часто достигает доступного объема памяти. Используете ли вы ZFS для корневой файловой системы или для виртуальных машин? Если да, пришлите, пожалуйста, вывод команды `arcstat`. Это покажет нам, сколько памяти может использовать (ZFS) ARC. У вас есть раздел подкачки?
     
     
     
    k4y53r
    Guest
    #3
    0
    30.04.2025 00:01:00
    Привет, ZFS и swap вообще не используются Похоже, дело не в количестве доступной оперативной памяти, сегодня MDS падает на узле с 192 ГБ ОЗУ, как видно ниже Могу проверить логи, и там что-то сломалось в полночь:

    ```
    -- Журнал начинается с Fri 2022-10-28 12:10:38 CEST, заканчивается на Tue 2025-04-29 23:49:34 CEST. --
    Apr 26 00:00:31 zpveo2 ceph-mds[2474769]: 2025-04-26T00:00:31.742+0200 7fbc5ee29700 -1 received signal: Hangup from killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror (PID: 1034873) UID: 0
    Apr 26 00:00:31 zpveo2 ceph-mds[2474769]: 2025-04-26T00:00:31.766+0200 7fbc5ee29700 -1 received signal: Hangup from (PID: 1034874) UID: 0
    Apr 27 00:00:31 zpveo2 ceph-mds[2474769]: 2025-04-27T00:00:31.741+0200 7fbc5ee29700 -1 received signal: Hangup from killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror (PID: 2466053) UID: 0
    Apr 27 00:00:31 zpveo2 ceph-mds[2474769]: 2025-04-27T00:00:31.773+0200 7fbc5ee29700 -1 received signal: Hangup from (PID: 2466054) UID: 0
    Apr 28 00:00:31 zpveo2 ceph-mds[2474769]: 2025-04-28T00:00:31.743+0200 7fbc5ee29700 -1 received signal: Hangup from killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror (PID: 3895442) UID: 0
    Apr 28 00:00:31 zpveo2 ceph-mds[2474769]: 2025-04-28T00:00:31.767+0200 7fbc5ee29700 -1 received signal: Hangup from (PID: 3895443) UID: 0
    Apr 28 18:21:47 zpveo2 ceph-mds[2474769]: did not load config file, using default settings.
    Apr 28 18:21:47 zpveo2 ceph-mds[2474769]: 2025-04-28T18:21:47.686+0200 7f86c7f44780 -1 Errors while parsing config file!
    Apr 28 18:21:47 zpveo2 ceph-mds[2474769]: 2025-04-28T18:21:47.686+0200 7f86c7f44780 -1 can't open ceph.conf: (2) No such file or directory
    Apr 28 18:21:47 zpveo2 ceph-mds[2474769]: ignoring --setuser ceph since I am not root
    Apr 28 18:21:47 zpveo2 ceph-mds[2474769]: ignoring --setgroup ceph since I am not root
    Apr 28 18:21:55 zpveo2 ceph-mds[2474769]: unable to get monitor info from DNS SRV with service name: ceph-mon
    Apr 28 18:21:55 zpveo2 ceph-mds[2474769]: 2025-04-28T18:21:55.336+0200 7f604d754700 -1 Fail to fetch monitor info from DNS SRV
    Apr 28 18:21:55 zpveo2 ceph-mds[2474769]: 2025-04-28T18:21:56.346+0200 7f604d754700 -1 Stop using mds.zpveo2
    Apr 28 18:21:56 zpveo2 ceph-mds[797254]: starting mds.zpveo2 at
    Apr 29 00:00:31 zpveo2 ceph-mds[797254]: 2025-04-29T00:00:31.753+0200 7f604d754700 -1 Fail to open '/proc/1140492/cmdline' error = (2) No such file or directory
    Apr 29 00:00:31 zpveo2 ceph-mds[797254]: 2025-04-29T00:00:31.753+0200 7f604d754700 -1 received signal: Hangup from <unknown> (PID: 1140492) UID: 0
    Apr 29 00:00:31 zpveo2 ceph-mds[797254]: 2025-04-29T00:00:31.785+0200 7f604d754700 -1 received signal: Hangup from (PID: 1140493) UID: 0 no cronjobs configured from my side Сегодня миграция MDS прошла гладко, без последствий, но когда это происходит в выходные, чаще всего MDS перезагружается и требует ручного перезапуска Также нет проблем с использованием дискового пространства в пуле, как можно видеть ниже Какие логи стоит проверить? Спасибо за помощь!
    ```

    Кстати, не уверен, что все эти ошибки можно интерпретировать однозначно - возможно, стоит обратиться к специалисту.
     
     
     
    k4y53r
    Guest
    #4
    0
    06.05.2025 14:54:00
    Привет ещё раз, сегодня снова ошибка MDS. Не на выходных, но одна MDS зависла, но осталась в активном статусе, и почти не обрабатывала запросы.

    Код: ceph fs status
    zk8scephfso1 - 78 клиентов
    ============
    RANK  STATE    MDS       ACTIVITY     DNS    INOS   DIRS   CAPS
    0    active  zpveo3  Reqs:    4 /s  83.7k  61.6k  21.1k  60.8k
    1    active  zpveo2  Reqs:    3 /s  30.5k  25.9k   785   23.2k
            POOL            TYPE     USED  AVAIL
    zk8scephfso1_metadata  metadata  8399M  1327G
     zk8scephfso1_data      data    4788G  1327G
    STANDBY MDS
      zpveo4
      zpveo1
    Версия MDS: ceph version 17.2.5 (e04241aa9b639588fa6c864845287d2824cb6b55) quincy (stable) Памяти сегодня нет проблем, только вчера… Последний раз памяти не хватало после перезагрузки. MDS на этом узле была развернута вручную, а не из-за oom kill. Но MDS на узле3 всё ещё не работает.

    Код: [WRN] FS_DEGRADED: 1 файловая система находится в деградированном состоянии. После перезагрузки mds.0 восстановилась файловая система и затронутые сервисы.

    Код: ceph fs status
    zk8scephfso1 - 83 клиента
    ============
    RANK  STATE    MDS       ACTIVITY     DNS    INOS   DIRS   CAPS
    0    active  zpveo1  Reqs:  354 /s   116k  88.7k  14.4k  18.2k
    1    active  zpveo2  Reqs:  162 /s  11.4k  11.3k   392   10.0k
            POOL            TYPE     USED  AVAIL
    zk8scephfso1_metadata  metadata  7252M  1324G
     zk8scephfso1_data      data    4790G  1324G
    STANDBY MDS
      zpveo4
      zpveo3
    Версия MDS: ceph version 17.2.5 (e04241aa9b639588fa6c864845287d2824cb6b55) quincy (stable) Буду мониторить и обновлять до тех пор, пока проблема не будет решена…
     
     
     
    k4y53r
    Guest
    #5
    0
    12.05.2025 15:13:00
    Привет, ситуация ухудшается, за последние 24 часа 3 ошибки MDS. Последняя произошла пару минут назад. MDS зависает в статусе clientreplay и выдаёт ошибки в syslog (полный лог не могу вставить из-за ограничений, см. приложенный txt файл).

    Код: May 12 14:29:19 zpveo2 ceph-mds[2264075]: ./src/mds/CDentry.h: In function 'virtual CDentry::~CDentry()' thread 7f36b4c3c700 time 2025-05-12T14:29:19.734946+0200
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: ./src/mds/CDentry.h: 130: FAILED ceph_assert(batch_ops.empty())
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: ceph version 17.2.5 (e04241aa9b639588fa6c864845287d2824cb6b55) quincy (stable)
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x124) [0x7f36c017223c]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 2: /usr/lib/ceph/libceph-common.so.2(+0x25a3da) [0x7f36c01723da]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 3: (CDentry::~CDentry()+0x484) [0x564a70d7b2e4]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 4: (CDir::remove_dentry(CDentry*)+0x1f3) [0x564a70d87de3]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 5: (MDCache::trim_dentry(CDentry*, std::map<int, boost::intrusive_ptr<MCacheExpire>, std::less<int>, std::allocator<std::pair<int const, boost::intrusive_ptr<MCacheExpire> > > >&)+0x4c9) [0x564a70c39599]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 6: (MDCache::trim_lru(unsigned long, std::map<int, boost::intrusive_ptr<MCacheExpire>, std::less<int>, std::allocator<std::pair<int const, boost::intrusive_ptr<MCacheExpire> > > >&)+0x5d1) [0x564a70c3ab31]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 7: (MDCache::trim(unsigned long)+0xa5) [0x564a70c56935]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 8: (Migrator::export_finish(CDir*)+0x7df) [0x564a70d4e2df]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 9: (Migrator::export_logged_finish(CDir*)+0x79f) [0x564a70d4f05f]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 10: (MDSContext::complete(int)+0x5b) [0x564a70e4f3cb]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 11: (MDSIOContextBase::complete(int)+0x524) [0x564a70e4fb44]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 12: (MDSLogContextBase::complete(int)+0x41) [0x564a70e4fed1]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 13: (Finisher::finisher_thread_entry()+0x18d) [0x7f36c020a32d]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 14: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7ea7) [0x7f36bfe8aea7]
    May 12 14:29:19 zpveo2 ceph-mds[2264075]: 15: clone() Все узлы показывают неизвестный статус до перезапуска и миграции MDS на другой узел Это происходит почти на 3 узлах, а не только на затронутом узле zpveo2
    Код: ceph fs status

    zk8scephfso1 - 54 clients
    ============
    RANK     STATE       MDS       ACTIVITY     DNS    INOS   DIRS   CAPS
    0    clientreplay  zpveo2                 60.6k  35.5k  2383   1263
    1       active     zpveo3  Reqs:   10 /s   195k   194k  46.2k  24.5k
            POOL            TYPE     USED  AVAIL
    zk8scephfso1_metadata  metadata  7957M  1130G
     zk8scephfso1_data      data    5370G  1130G
    STANDBY MDS
      zpveo4
      zpveo1
    MDS version: ceph version 17.2.5 (e04241aa9b639588fa6c864845287d2824cb6b55) quincy (stable) После перезагрузки MDS находится в статусе clientreplay более 10 минут, после чего ceph возвращается в онлайн, и все узлы показывают зеленую отметку. Буду благодарен за любую помощь.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры