Мы сталкиваемся с прерывистыми периодами 100% загрузки ЦП.
Конфигурация сервера:
HP DL580 G7 (4 процессора по 8 ядер каждый; 128 ГБ памяти).
Операционная система: Solaris 10_x86 update 9
Применение: Oracle 10 R2; ASM для управления дисками. Размер БД 5ТБ; SGA 78 ГБ
Подсистема хранения данных: система хранения с прямым подключением HP MSA2312sa Dual Controller SAS
В обычный день (загрузка ЦП 20%) vmstat вывод представлен ниже
kthr страница памяти неисправность диска cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 s3 in sy cs us sy id
0 27 26 128133040 6469184 362 4937 829 3 22 0 117-0 4 0 97 85888 383138 19238 19 2 79
0 20 31 129089972 4009408 294 4341 28 0 0 0 0 0 2 0 96 144240 363898 27797 12 5 82
1 17 31 128869152 3731692 243 4437 0 0 0 0 0 0 6 0 88 142738 385237 26503 10 5 84
1 21 31 128803936 3665112 283 5545111 0 0 0 0 0 3 0102 157962 347356 26940 12 5 82
2 20 31 128556548 3515596 274 10806 0 0 0 0 0 0 6 0 99 253881 391554 34754 13 7 80
Сводка процессов:
Выполнение процессов очереди - 0 ~ 2 заблокированных процесса - 17 ~ 27 процессов с заменой мест - 31
Сводка по загрузке ЦП:
Пользователь - 10% ~ 20% Система - 2% ~ 7% Режим ожидания - 79% ~ 85%
Что может быть причиной такого нерационального поведения процессора?
Почему заблокированные процессы (b) и замененные процессы (w) намного выше, чем запущенные процессы (r)?
Мы смотрим на узкое место ЦП, узкое место памяти или узкое место ввода-вывода?
Мы действительно выполняем резервное копирование Oracle RMAN, но оно выполняется каждый день в 4 часа утра.
В то время как загрузка ЦП достигает 100% в обычные рабочие часы (с 10:00 до 18:00), в этот период фоновое резервное копирование не выполняется.
Что касается больших запросов, мы выполняем довольно длинные и сложные запросы. Эти запросы выполняются каждый день, и загрузка ЦП едва превышает 40%, но за последнюю неделю мы наблюдаем короткие всплески 100% загрузки ЦП.
На первый взгляд, в прошлом ваша система испытывала острую нехватку оперативной памяти. Средняя скорость сканирования с момента последней загрузки составляет 117, в то время как она должна равняться 0 или близка к ней в системе с достаточным объемом оперативной памяти. Кажется, это подтверждается вашим столбцом 31 w, что, вероятно, означает, что 31 демон был заменен во время события нехватки оперативной памяти и никогда не возвращался неиспользованным.
Испытываете ли вы 100% загрузку всех 32 ядер ЦП или только нескольких? Я не могу говорить о статистике, которую вы опубликовали, поскольку она довольно нечитабельна, но попытаюсь дать некоторые общие ответы на то, что вы испытываете:
Заблокированные / замененные процессы Иногда процессы в серверной ОС привязываются к определенному ядру ЦП и ТОЛЬКО используют это ядро для своих нужд, игнорируя все остальные ядра. Как правило, это больше проблема для старых программ, которые не были предназначены для работы в многоядерных системах. Конечным результатом является то, что если у вас есть несколько процессов, которые делают это, и они решили использовать одно и то же ядро, они будут постоянно блокировать и менять местами друг друга, чтобы делать то, что им нужно, в то время как другие ядра простаивают, ничего не делая. Иногда вы можете настроить программное обеспечение для выбора конкретных ядер и вручную «балансировать» процессы между вашими процессорами (аналогично ручным настройкам IRQ в свое время), но это, очевидно, нежелательно, поскольку требует ручной перенастройки с вашей стороны и вас. может в конечном итоге ухудшить ситуацию. Выясните, какие процессы блокируют друг друга, и сосредоточьтесь на них. Я сомневаюсь, что у вас есть узкое место в процессоре с 32 ядрами, но я также не могу сказать наверняка. Прочтите документацию по процессам / программному обеспечению, чтобы узнать, что рекомендует поставщик, и можете ли вы даже настроить процесс для этого.
Заблокированные / замененные процессы выше, чем запущенные процессы Вероятно, что происходит, так это то, что ваш счетчик производительности просто тикает каждый раз, когда процесс блокируется / выгружается, и не показывает ТЕКУЩИЕ заблокированные / замененные процессы, поэтому он всегда должен быть выше, чем ваши запущенные процессы (это именно то, что он говорит - количество запущенных в настоящее время процессов в вашей системе). Это не должно вызывать беспокойства.
У ваших виртуальных машин такое же количество процессоров, что и в хост-системе? в таком случае это плохо и может помешать правильной работе планировщика. IE, если у вас 8-ядерная система, то ни одной системе на этом компьютере не должно быть назначено 8 ядер. У вас может быть 20 виртуальных машин с 4 назначенными ядрами, и это не проблема, но 1 ящик с 8 назначенными ядрами может вызвать проблемы под нагрузкой.
Есть ли у вас какие-либо автоматизированные процессы резервного копирования или что-то, что могло бы перегружать диски? Это звучит смутно, как будто у вас проблемы с IOwait. Можете ли вы получить снимок mpstat, когда ваш сервер недоволен? Вероятно, вы могли бы исключить проблему дискового ввода-вывода, выполнив небольшие записи 5 ГБ на диск или что-то еще в режиме DIRECT_IO (чтобы обойти тот факт, что вы можете кэшировать половину земли в свободной памяти на этом сервере). Кроме того, пробовали ли вы (если можете) изучить свои запросы в это время? Может быть, кто-то закидывает вас кучей полных сканирований или что-то в этом роде?