Вопрос или проблема
Я устраняю некоторые проблемы с моим сервером RHEL 5. Это сервер Oracle DB, который работал несколько времени без особых проблем. Последнее время я замечаю, что нагрузка на сервер относительно высокая из-за процессов KSWAPD, вызывающих высокую загрузку ЦП. Проверив, я заметил, что на сервере много активности по свопингу.
Характеристики сервера:
12 x 2 ЦП & 64 ГБ ОЗУ
bash-3.2$ uname -a
Linux 2.6.18-408.el5 #1 SMP Пт Дек 11 14:03:08 EST 2015 x86_64 x86_64 x86_64 GNU/Linux
Когда я смотрю на top, я вижу, что на сервере все еще осталось 10 ГБ свободной физической памяти, и поэтому я не уверен, почему он свопит. Буду признателен, если кто-то подскажет правильное направление для устранения неполадок.
top - 15:31:35 запущен 231 день, 5:22, 2 пользователя, средняя нагрузка: 13.27, 13.97, 14.12
Задачи: 1443 всего, 12 выполняются, 1431 спят, 0 остановлены, 0 зомби
ЦП: 29.2%us, 17.2%sy, 0.0%ni, 47.5%id, 5.4%wa, 0.0%hi, 0.6%si, 0.0%st
Память: 65839252k всего, 53587688k использовано, 12251564k свободно, 122936k буферов
Своп: 68059128k всего, 4535508k использовано, 63523620k свободно, 45719164k кэшировано
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9423 oraitxnp 17 0 8403m 167m 166m R 98.7 0.3 0:57.51 oracle
12348 oraitxnp 17 0 8405m 242m 240m R 98.7 0.4 0:39.11 oracle
8942 oraitxnp 20 0 8404m 174m 171m R 95.6 0.3 1:59.77 oracle
9049 oraitxnp 25 0 8404m 170m 167m R 95.6 0.3 1:33.17 oracle
9402 oraitxnp 25 0 8404m 161m 158m R 95.6 0.3 1:24.03 oracle
13280 oraitxnp 17 0 8403m 161m 159m R 95.6 0.3 1:04.59 oracle
13227 oraitxnp 17 0 8403m 165m 162m R 92.4 0.3 0:40.65 oracle
1431 root 11 -5 0 0 0 R 82.8 0.0 2802:41 kswapd2
11395 oraitxnp 16 0 8403m 192m 191m R 66.9 0.3 0:15.55 oracle
sar -r
02:20:02 ДП kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
02:30:11 ДП 12860252 52979000 80.47 122888 45721248 63711928 4347200 6.39 853652
02:40:02 ДП 12591216 53248036 80.88 122876 45728156 63467408 4591720 6.75 860892
02:50:01 ДП 12648836 53190416 80.79 122928 45729408 63717800 4341328 6.38 913284
03:00:02 ДП 12489840 53349412 81.03 122932 45727364 63558884 4500244 6.61 941220
03:10:05 ДП 12380352 53458900 81.20 123064 45735548 63541648 4517480 6.64 879124
03:20:12 ДП 12195596 53643656 81.48 123124 45732364 63358440 4700688 6.91 901656
03:30:02 ДП 12425600 53413652 81.13 122936 45718624 63582308 4476820 6.58 964544
Среднее: 12406342 53432910 81.16 121691 45498460 63646323 4412805 6.48 952204
sar -B
02:20:02 ДП pgpgin/s pgpgout/s fault/s majflt/s
02:30:11 ДП 36386.86 4421.45 14369.55 2242.21
02:40:02 ДП 41398.13 5570.15 17610.94 2555.90
02:50:01 ДП 51600.70 4681.47 14093.22 1675.94
03:00:02 ДП 48850.39 5340.96 15636.23 2251.99
03:10:05 ДП 53043.46 4755.90 17506.83 2378.80
03:20:12 ДП 39151.42 5297.79 14383.58 1816.64
03:30:02 ДП 47760.58 5099.56 14774.31 2236.45
Среднее: 47687.94 4831.93 15128.85 2191.29
-bash-3.2$ free -m
total used free shared buffers cached
Память: 64296 52281 12014 0 120 44655
-/+ buffers/cache: 7506 56789
Своп: 66463 4545 61918
Какое значение у вас установлено для vm.swappiness? Значение по умолчанию – 60 (по крайней мере, на Ubuntu). Насколько я понимаю, чем меньше число, тем больше ваша система будет предпочтать ОЗУ перед свопом.
Это, конечно, при условии, что высокая нагрузка на ЦП связана с дисковым свопом. Если я правильно читаю этот вывод, те 8 процессов oraitxnp используют более 8 ГБ виртуальной (ОЗУ) памяти каждый. Это похоже на конкуренцию за физическую память, но я не уверен, как колонки RES и SHR влияют на это.
Я бы выполнил cat /proc/meminfo, чтобы лучше понять, сколько “физической” ОЗУ используется. Трудно сказать по некоторым данным sar, поскольку они смешивают 64 ГБ физической + 66 ГБ свопа, но я бы предположил, что добавление еще 64 ГБ ОЗУ в этот сервер — и, возможно, уменьшение дискового свопа до 8 ГБ или что-то подобное. В идеале, вы никогда не хотите использовать дисковый своп. Если вы это делаете, вам нужно добавить больше физической ОЗУ или потерпеть снижение производительности.
Много лет назад стандартом для свопа в Linux было “просто сделай его вдвое больше, чем ваша ОЗУ”, но это было в то время, когда большинство настольных систем работали всего на 1-2 ГБ. Даже Redhat изменил эту позицию, предлагая, что 20% от физической памяти “обычно хорошая идея.”
Ответ или решение
Процесс kswapd является одной из ключевых подсистем управления памятью в Linux, и его основная задача заключается в управлении своп-файлом и освобождении памяти для активных процессов. Ваша ситуация с высоким использованием процессора из-за kswapd может быть признаком нескольких проблем, связанных с управлением памятью на вашем сервере RHEL 5, который работает с Oracle DB.
Описание проблемы
На вашем сервере RHEL 5 с 64 ГБ ОЗУ зафиксировано значительное использование ресурса CPU процессом kswapd. При этом, несмотря на то, что доступно 10 ГБ физической памяти, наблюдается активное использование свопа и высокая нагрузка на процессора. Это может свидетельствовать о том, что память используется неэффективно, и процесс kswapd вынужден активно участвовать в переноса страниц между ОЗУ и свопом, ухудшая производительность системы.
Анализ текущей ситуации
-
Общее использование памяти:
- Вы указали, что у вас 64 ГБ ОЗУ и порядка 5,36 ГБ свободно при использовании 53,58 ГБ. Однако, система при этом продолжает достаточно активно использовать своп, что может быть признаком нехватки физической памяти.
-
Параметры swappiness:
- Значение параметра
vm.swappinessопределяет, как часто операционная система будет использовать своп по сравнению с ОЗУ. Стандартное значение равно 60; для серверов, особенно с большим объемом памяти, возможно стоит установить это значение ниже (например, 10 или 20), что заставит систему предпочитать использовать ОЗУ вместо свопа.
- Значение параметра
-
Набор процессов:
- Как видно из вывода команды
top, процессы Oracle становятся главными потребителями ресурсов. Каждому процессу выделяется более 8 ГБ виртуальной памяти, что в сочетании с текущей нагрузкой на kswapd может приводить к колебаниям в использовании памяти, требуя постоянного доступа к свопу даже при наличии свободной физической памяти.
- Как видно из вывода команды
-
Нагрузка на своп:
- Вычисления на основе
sarпоказывают значительную активность ввода-вывода – особенно в расчетах поpgpginиpgpgout, что указывает на частый доступ к свопу. Это подтверждается сообщением о высоком числе операций, ведающих системой: 47 687.94 операций ввода (pgpgin) и 4 831.93 операций вывода (pgpgout) в секунду.
- Вычисления на основе
Рекомендации по устранению проблемы
-
Настройка параметра swappiness:
Чтобы уменьшить использование свопа и снизить нагрузку наkswapd, измените значениеvm.swappinessна значение ниже 60:echo 10 > /proc/sys/vm/swappinessЭто настройка требует минимального перезагрузки и должна оказать влияние на производительность немедленно.
-
Мониторинг использования памяти:
- Запустите команду
cat /proc/meminfo, чтобы получить более детальную информацию о текущем использовании памяти. Обратите внимание на значенияBuffers,CachedиSwapCached, которые могут помочь вам понять, сколько памяти можно освободить без воздействия на производительность.
- Запустите команду
-
Добавление оперативной памяти:
- Если после применения предложенных настроек проблема все еще существует, рассмотрите возможность увеличения объема физической памяти на сервере. Оптимальная конфигурация для Oracle DB требует значительных ресурсов, особенно с увеличением числа запросов.
-
Устранение утечек памяти:
- Проверьте, не возникает ли утечек памяти в приложениях, работающих на сервере, через анализ дампов памяти (если возможно) или использование профилей памяти.
-
Планируйте регулярное обслуживание:
- Регулярно выполняйте оценку производительности системы, чтобы предотвратить подобные проблемы в будущем. Следите за регулярными отчётами по памяти и свопу, чтобы оптимизировать настройки системы.
Заключение
Проблема с высоким использованием CPU процессом kswapd на вашем сервере RHEL 5 указывает на более глубокие вопросы управления памятью и свопом. Применение указанных рекомендаций может существенно уменьшить нагрузку и улучшить общую производительность вашего Oracle DB сервера. Обязательно продолжайте мониторить состояние системы после внесения изменений.