1. Форумы
  2. KernelCare
  3. KernelCare Обсуждение
  1. Фред Флинт
  2. Воскресенье, 04 марта 2018
  3. Подписка по электронной почте
Вчера я обратил внимание на ядро ​​на два узла OpenVZ.

042stab127.2

Один из них выглядит нормально, но у другого были проблемы в одночасье. Действительно высокая смена и загрузка, хотя было еще много неиспользуемой памяти. В индивидуальных контейнерах использовались все их vswap. Не все контейнеры используют vswap. Я перезагрузил контейнеры с vswap и, похоже, исправил обмен / загрузку. Слишком много совпадений, что это случилось вечером, когда я обновил ядро. Больше ничего не было сделано, и этот сервер работает непрерывно в течение нескольких месяцев

Другой узел все еще в порядке. Надеюсь, перезапуск контейнеров скорректировал его, и мне не придется откатывать ядро.

Оба узла - Supermicro с процессором Intel (R) Xeon (R) E3-1230 v3 @ 3.30GHz и 16GB RAM

Оба запускают kcare 042stab127.2

Базовое ядро ​​отличается, хотя

Один из них все еще работает 2.6.32-042stab113.21
У проблемы, которая возникла проблема, является 2.6.32-042stab108.8
Оценить этот пост:
  1. 04.03.2018 15:03:15
  2. # 1
Фред Флинт Принято ответа
Сообщений: 0
Присоединился: 10.12.2019
0
Голосов
расстегивать
BTW, они оба запускали то же самое ядро ​​kcare перед обновлением. Последний вышел до этого кризиса / Spectre.
  1. 05.03.2018 17:03:40
  2. # 2
Фред Флинт Принято ответа
Так я единственный, у кого есть эта проблема? Это определенно связано с Kernelcare. Это произошло сразу после того, как я провел тяжелый процесс, который очищает весь кеш и вызывает большую нагрузку в течение нескольких минут. Сразу после этого, вместо того, чтобы груз утихал, он взлетел вверх. Средняя загрузка была 200, когда она обычно ниже 4. Состояние ожидания процессора переместилось между 50% и 95%, что означает, что он ожидает ввода-вывода.

Я отключил тяжелую работу cron, но я подозреваю, что проблема все еще существует и может быть запущена снова, когда выполняется тяжелое задание cron.
  1. 05.03.2018 18:03:36
  2. # 3
Фред Флинт Принято ответа
Я должен указать, что я обновил другие серверы с помощью собственного ядра 042stab127.2, а не с помощью ядра, и не видел этой проблемы.
  1. 05.03.2018 18:03:55
  2. # 4
Александр Парубочий Принято ответа
Сообщений: 187
Присоединился: 31.01.2017
0
Голосов
расстегивать
Фред, пожалуйста, создайте билет на https://cloudlinux.zendesk.com (Отдел KernelCare), поэтому наша служба поддержки может помочь вам в решении этой проблемы.
  1. 09.03.2018 23:03:12
  2. # 5
Питер Законы Принято ответа
Сообщений: 3
Присоединился: 22.01.2018
0
Голосов
расстегивать
Был ли какой-то результат? Это был КК? Я уже давно напугался, чтобы обновить kernelcare на yum сейчас ...
  1. 10.03.2018 13:03:25
  2. # 6
Александр Парубочий Принято ответа
Сообщений: 187
Присоединился: 31.01.2017
0
Голосов
расстегивать
Для расследования проблемы был создан билет #26416.
КСТАТИ, yum update kernelcare не должны возникать проблемы с бинарными исправлениями, которые применяются KC.
  1. 10.03.2018 19:03:54
  2. # 7
Питер Законы Принято ответа
Сообщений: 3
Присоединился: 22.01.2018
0
Голосов
расстегивать
Я глуп, я думал, что вам нужен последний KC для обновления до stab127.2 ... Кажется, у меня была эта версия ядра на века ... :o

как (_8 (|) говорит ..... d'oh
  1. 14.03.2018 15:03:11
  2. # 8
Фред Флинт Принято ответа
Сообщений: 0
Присоединился: 10.12.2019
0
Голосов
расстегивать
До сих пор проблема с высокой нагрузкой не повторялась с первого раза, когда я перезапускал контейнеры, которые используют vswap.
  1. 19.03.2018 18:03:13
  2. # 9
Владимир Принято ответа
Сообщений: 108
Присоединился: 04.07.2017
0
Голосов
расстегивать
Рад слышать.

Не стесняйтесь, дайте мне знать, если у вас возникнут дополнительные вопросы или проблемы.
  1. 17.04.2018 18:04:06
  2. # 10
Фред Флинт Принято ответа
Сообщений: 0
Присоединился: 10.12.2019
0
Голосов
расстегивать
Ну, это снова произошло. Я перезагрузил контейнеры 2, которые, казалось, вызывали высокую нагрузку, и он снова ушел. Мне придется обновить этот узел до реального ядра и посмотреть, не заботится ли он об этом.
  1. 17.04.2018 19:04:11
  2. # 11
Владимир Принято ответа
Сообщений: 108
Присоединился: 04.07.2017
0
Голосов
расстегивать
Здравствуйте.

Мы хотели бы проверить эту проблему.
Пожалуйста, отправьте билет на https://cloudlinux.zendesk.com, наши специалисты проведут проверку на месте.
  1. 17.04.2018 20:04:23
  2. # 12
Фред Флинт Принято ответа
Сообщений: 0
Присоединился: 10.12.2019
0
Голосов
расстегивать
Здравствуйте.

Мы хотели бы проверить эту проблему.
Отправьте билет на https://cloudlinux.zendesk.com, наши специалисты проведут проверку проблемы.


Вы, ребята, уже сделали и сказали, что ничего не нашли. Кажется, трудно воспроизвести. Я вижу, что в последнем ядре OVZ было зафиксировано одно состояние гонки, поэтому, возможно, это позаботилось об этом. Это началось, как только обновленный Kernelcare, и я нашел это на других узлах, которые не запускают KernelCare, но работают с одним и тем же реальным ядром. Поэтому я думаю, что лучше всего запустить реальное ядро ​​в этом случае.
  1. 19.04.2018 15:04:40
  2. # 13
Владимир Принято ответа
Сообщений: 108
Присоединился: 04.07.2017
0
Голосов
расстегивать
Извините, но вам сложно помочь, не зная, что происходит на этом сервере.
Мы действительно хотели бы проверить эту проблему на месте. Пожалуйста, отправьте билет в https://cloudlinux.zendesk.com и наши специалисты расследуют его дальше.
  • Страница:
  • 1


Там нет ответов, сделанные на этот пост пока нет.
Будьте одним из первых, чтобы ответить на этот пост!
гость
Отправить Ваш ответ
Загрузить файлы или изображения для обсуждения этого вопроса, нажав на кнопку загрузки ниже. опоры GIF, JPG, PNG, ZIP, RAR, PDF
• Вставить • Удалить Загрузка файлов (Максимальный размер файла: 2 MB)
Защитный код
Чтобы защитить сайт от ботов и несанкционированных сценариев, мы требуем, чтобы вы ввели коды капчи ниже, прежде чем отправить свой вопрос.