Добрый день!
Сегодня отвечал на тестовый вопрос для одной конторы и был такой вопрос: На OpenVZ ноде LA достигает 300. Как понять причину повышения нагрузки? Напишите команды для анализа проблемы и вероятные причины начиная с самой вероятной.
Решил провести синтетический тест. Так как у меня есть десктопный компьютер с Proxmox на борту, который включает в себя KVM и OpenVZ. Я создал 3 OpenVZ контейнера с Debian 6 на борту.
На каждом из контейнеров я запустил по 10 процессов cpuburn (утилита для синтетической нагрузки процессора).
И вот, что получилось:
# uptime
Видим, что LA в районе 30. Правильно, ведь я запустил 3 контейнера по 10 процессов cpuburn.
Для начала давайте посмотрим, какие контейнеры у нас есть и какие запущены:
# vzlist -a
Проверим используемую память нашими контейнерами:
# vzmemcheck -vA
Ага! Видим, что память не так уж и заполнена (200-250 мегабайт, хотя я выделал по 1GB).
Посмотрим LA каждого контейнера:
# vzlist -o veid,laverage
Видим, что на всех контейнерах LA за 1 минуту равно 10. Это довольно плохо тем более при 1 CPU.
Так как это синтетический тест, то попробуем разобраться с одним контейнером. Давайте для начала ограничим использование процессора контейнером с CTID равным 100.
# vzctl set 101 --cpulimit 15 --save
Так же получить более адекватную информацию о памяти можно с помощью:
#vzcalc -v 100
Сегодня отвечал на тестовый вопрос для одной конторы и был такой вопрос: На OpenVZ ноде LA достигает 300. Как понять причину повышения нагрузки? Напишите команды для анализа проблемы и вероятные причины начиная с самой вероятной.
Решил провести синтетический тест. Так как у меня есть десктопный компьютер с Proxmox на борту, который включает в себя KVM и OpenVZ. Я создал 3 OpenVZ контейнера с Debian 6 на борту.
На каждом из контейнеров я запустил по 10 процессов cpuburn (утилита для синтетической нагрузки процессора).
И вот, что получилось:
# uptime
Видим, что LA в районе 30. Правильно, ведь я запустил 3 контейнера по 10 процессов cpuburn.
Для начала давайте посмотрим, какие контейнеры у нас есть и какие запущены:
# vzlist -a
Проверим используемую память нашими контейнерами:
# vzmemcheck -vA
Посмотрим LA каждого контейнера:
# vzlist -o veid,laverage
Так как это синтетический тест, то попробуем разобраться с одним контейнером. Давайте для начала ограничим использование процессора контейнером с CTID равным 100.
# vzctl set 101 --cpulimit 15 --save
Так же получить более адекватную информацию о памяти можно с помощью:
#vzcalc -v 100
Давайте же посмотрим, что за процессы так грузят процессор:
# vzctl exec 100 top -b -n 1
Видим процессы burnBX с PID'ами: 2380, 2382, 2384, 2385, 2387, 2388, 2397, 2399, 2400, 2402.
Убьем их по очереди:
# vzctl exec 100 kill -9 2380
# vzctl exec 100 kill -9 2382
....
И выведем опять top:
# vzctl exec 100 top -b -n 1
И видим, как стремительно падает LA.
А помните мы ограничили контейнер 101 процессорными мощностями в 15% ? Давайте посмотрим uptime хост системы:
И видим, что LA равно 12.00, а было 30.
10 LA мы убрали убив 10 процессов на контейнере 100 и 8 LA (еще не успело сойти до 8.5 LA) мы уменьшили потребление контейнера 101. Вот так мы вычислили виновников и наказали их!
vzpid тоже в помощь.
ОтветитьУдалить