+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

[SOLVED]/proc/stat слишком много бездействия, Proxmox Виртуальная Среда

JNG

Guest

22.10.2019 10:28:00

Здравствуйте всем! У меня возникла странная проблема, в которой я, похоже, не понимаю всех механизмов: у меня есть сервер Proxmox (5.4-5) с только контейнерами. В некоторых из моих контейнеров время простоя в /proc/stat зашкаливает (до 15281440583165230629). Однако это касается не всех моих контейнеров. Вот выдержка из /proc/stat моего хоста и всех его контейнеров (время простоя — это четвертое число): Код: PROXMOX: cpu 249831240 739348 112704491 41524746240 36109750 0 10716115 0 0 0 Lxc 101:cpu 1087462 0 0 7237883161620866592 0 0 0 0 0 0 Lxc 202:cpu 6710018 0 0 10498331248841811323 0 0 0 0 0 0 Lxc 203:cpu 2823807 0 0 2618472444 0 0 0 0 0 0 Lxc 205:cpu 13133112 0 0 5230079033 0 0 0 0 0 0 Lxc 206:cpu 114943641 0 0 3760916293231833407 0 0 0 0 0 0 Lxc 214:cpu 5601276 0 0 5236861199 0 0 0 0 0 0 Lxc 215:cpu 3188382 0 0 753066715665654677 0 0 0 0 0 0 Lxc 216:cpu 7641882 0 0 5234613545 0 0 0 0 0 0 Lxc 218:cpu 7266864 0 0 9277556796665397440 0 0 0 0 0 0 Lxc 221:cpu 729038 0 0 5242362687 0 0 0 0 0 0 Lxc 222:cpu 7587024 0 0 15281440583165230629 0 0 0 0 0 0 Lxc 223:cpu 8118629 0 0 5234631398 0 0 0 0 0 0 Lxc 224:cpu 11540087 0 0 5229515948 0 0 0 0 0 0 Lxc 225:cpu 1513987 0 0 5240446385 0 0 0 0 0 0 Ошибка: контейнер '226' не работает! Lxc 229:cpu 4843023 0 0 5230115101 0 0 0 0 0 0 Lxc 326:cpu 44216243 0 0 5190742122 0 0 0 0 0 0 Перезагрузка контейнера не сбрасывает этот счетчик полностью (он только делит его пополам). Хотя я понимаю, как работает линия счетчика CPU на «металле», существует ли механизм в lxc или другом компоненте Proxmox, который подделывает, маскирует или изменяет счетчик простоя? Обычно меня это не беспокоило бы, но в моих контейнерах работает Cassandra, которая выдает NumberFormatException, потому что пытается преобразовать это значение в long. Поскольку значение слишком велико, система зависает при загрузке. Это своего рода ошибка на стороне Cassandra, но это значение простоя тоже странное. Спасибо заранее за любые подсказки, я исчерпал свои идеи. РЕДАКТИРОВАНИЕ: после дополнительных исследований оказалось, что /proc в proxmox lxc обрабатывается lxcfs. Я продолжаю исследования в этом направлении. Буду держать вас в курсе.

oguz Guest	#2 0 06.11.2019 16:23:00 Привет, я не смог это воспроизвести, можешь рассказать больше о своей настройке? (количество CTS, что на них запущено, время работы хоста, частота обновлений и т.д.) Ты нашел что-то еще?

JNG

Guest

06.11.2019 23:41:00

У меня около 10 CT в этом кластере, хотя я не уверен, что это связано. Они запускают Java-приложение с Apache, MySQL и Cassandra. Тем не менее, это, похоже, не связано с содержимым контейнера, так как "пустой" контейнер (без приложения) проявляет ту же проблему. Более удивительно, что он может начать с разумного значения простоев, а затем, внезапно (я это мониторил), перейти на исключительно большое значение. Перезагрузка сервера не решает проблему. У нас есть другие прокс-мокс, но это единственный кластер с этой проблемой. Я не знаю, откуда это берётся, но, возможно, это связано с конкретным оборудованием. Это единственный кластер с AMD Epyc, но я не вижу, почему этот процессор не мог бы обрабатывать LXC. Судя по тому, что мы наблюдали, эта проблема, похоже, глубоко укоренилась в lxcfs. На самом деле им довольно трудно эмулировать значение простоя, так как cgroup не предоставляет его само по себе. Думаю, разработчики lxcfs, в основном, стараются поддерживать значение относительно согласованным (потому что получить абсолютное значение невозможно). Тем не менее, мы используем lxcfs 3.0.3, и с тех пор они провели основную переработку (https://github.com/lxc/lxcfs/commit/8be92dd19ceecb0ab54f36cc69d5f3845ba29844) для lxcfs 3.1.2. Однако из-за этой сложности я не знаю, связана ли моя проблема со старой версией lxcfs. Это мои два цента. Я всё ещё пытаюсь разобраться, откуда берётся эта проблема, но я как-то потерялся, и так как я, возможно, единственный в этой ситуации, может быть, это что-то другое, что я упустил.

ebiiii

Guest

02.12.2019 21:58:00

У нас такая же проблема, примерно половина наших контейнеров показывает время ожидания в порядке величины unsigned long на 64-битной архитектуре (мы даже видели один с эквивалентом 0xFFFFFFFFFFFFFFFF). Пока не похоже, что это связано с фактической загрузкой, запущенными службами, физической машиной или физическим процессором, к ним подключенным. Наша конфигурация работает на процессорах Intel, и все наши машины аналогично затронуты. На самом деле, если у вас lxcfs 3.0.3-pve1, он не собран из ветки 3.0.x, а из неопределенного снимка главной ветки примерно в феврале 2019 года (http://download.proxmox.com/debian/...ption/binary-amd64/lxcfs_3.0.3-pve1.changelog). Это уже включает коммит, на который вы ссылаетесь, и следующий, который делает ситуацию еще сложнее (https://github.com/lxc/lxcfs/commit/056adcefe4c6b345e91b1e8c38be4f02db970d3b). Я подозреваю, что функция cpuview_proc_stat имеет какой-то крайний случай/состояние гонки, что приводит к тому, что мы наблюдаем. Интересно, что мы обнаружили проблему, потому что постоянное значение для времени ожидания заставляет некоторые инструменты мониторинга сообщать о 100% загрузке процессора, например, htop: https://github.com/hishamhm/htop/issues/936.

ebiiii

Guest

20.03.2020 10:53:00

Привет всем! Мы вручную собрали и развернули версию 4.0 LXCFS на тестовом сервере с proxmox 6 (pve-manager/6.1-5/9bf06119), и на данный момент (после недели работы с около 10 контейнерами) проблема больше не возникала. Не могу гарантировать, что это решит вашу проблему, @JNG, но попробовать стоит. @oguz, как ты думаешь, можно ли будет обновить версию LXCFS, упакованную в proxmox, в следующем релизе? Нам бы не хотелось применять такие грязные хаки на наших боевых серверах

Большое спасибо и хорошего дня!

JNG

Guest

20.03.2020 11:06:00

Спасибо, @ebiii. Я постараюсь сделать это, как только смогу (в данный момент, из-за европейских событий, это может занять некоторое время). Тем не менее, так как я воспроизвел это только на конкретном сервере, мне придется сделать это на нашем тестовом сервере, который сегодня довольно загружен. Тем не менее, я поддерживаю ваше предложение обновить LXCFS, на мой взгляд, всегда приятно иметь последние версии.

oguz Guest	#7 0 20.03.2020 15:53:00 Мы тоже это тестируем, так что оно будет доступно скоро, но не раньше следующей недели.

JNG Guest	#8 0 29.06.2020 08:58:00 Проблема была решена путем обновления до PVE6. Я по-прежнему считал, что в более ранней версии lxcfs есть проблема. Однако: это решено! Спасибо всем за вашу помощь.

Читают тему

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