LINUX.ORG.RU
ФорумAdmin

Большая загрузка в режиме ядра


0

0

сервер 2 x Intel Xeon 5450, 8G Ram
система Linux Red Hat EL 5
kernel 2.6.26

Если в системе мониторинг показывает большую загрузку в режиме ядра, это что означает?
пора процессор менять? или может можно что-то подкрутить?
на сервере MySQL крутится.

top показывает примерно такую картину

top - 12:29:17 up 64 days, 3:02, 2 users, load average: 13.34, 15.18, 13.38
Tasks: 154 total, 2 running, 152 sleeping, 0 stopped, 0 zombie
Cpu(s): 55.1%us, 28.8%sy, 0.0%ni, 15.2%id, 0.5%wa, 0.0%hi, 0.5%si, 0.0%st
Mem: 8309708k total, 7967952k used, 341756k free, 319824k buffers
Swap: 4096532k total, 144k used, 4096388k free, 5957820k cached


в Red Hat EL 5 как бы другое ядро, поделитесь причинами перехода на ванил 2.6.26

anonymous2 ★★★★★
()

1) MySQL достаточно погано распараллеливается

2) Скорее всего, у вас тормоза в IO - попробуйте my-huge.cnf/my-large.cnf

tempuser001
()

> Большая загрузка в режиме ядра

wtf режим ядра???

Komintern ★★★★★
()

> в Red Hat EL 5 как бы другое ядро, поделитесь причинами перехода на ванил 2.6.26
кончилась лицензия на обновление а продлять денех не дали.

> Скорее всего, у вас тормоза в IO
я так думаю, что если-бы причина была в этом, был-бы высокий процент iowait. а iostat ничего запредельного по вводу/выводу не показывает.

edi
() автор топика
Ответ на: комментарий от edi

>кончилась лицензия на обновление а продлять денех не дали. 
Ну прям так необходимо было обновляться. Старое ядро наверно протухло и перестало работать.

>Cpu(s): 55.1%us, 28.8%sy
Основная нагрузка юдет от юзерских процессов. Наверно от мускуля.

А тормозит по причине кривых запросов от софта, кривой организации таблиц БД и/или отсутствия индексов для больших таблиц.
Ну и настройки мускуля возможно кривые, не расчитаны на ваши БД.

dzoleg
()
Ответ на: комментарий от dzoleg

Да, основная нагрузка идет от мускула, ибо на сервере кроме него других задач не крутится.
настройки мускула самые прямые.
кривых запросов и БД хватает, но с этим планомерная борьба идёт.
проблема проявилась не вдруг, а постепенно, по мере роста числа запросов. сейчас в часы пик 1400 в секунду.
и если-бы основная проблема была в качестве запросов, если я правильно понимаю, то были-бы большие задержки с вводом-выводом, а с этим всё в порядке: iowait составляет всего 0.5-1.5%, и были-бы большие значения в user mode и невысокие в system. а у меня в user mode процессор проводит в часы пик не более 50%(если верить munin'у), а вот system иногда до 35% поднимается

edi
() автор топика
Ответ на: комментарий от edi

>если-бы основная проблема была в качестве запросов, если я правильно понимаю, то были-бы большие задержки с вводом-выводом.

Какая связь плохих запросов с дисковым вводом/выводом? Неоптизированный селект из больших полей без индексов будет тормозить
и при этом обращений к диску может и не быть.

Советую включить логирование неиндексных и тормозных запросов.
Дальше думать.

в my.cnf
log-slow-queries=/tmp/mysql-slow.log
log-queries-not-using-indexes
long_query_time=5 (можно поиграть порогом)

dzoleg
()
Ответ на: комментарий от dzoleg

> Советую включить логирование неиндексных и тормозных запросов.
всё включено и логируется.

> Неоптизированный селект из больших полей
вопрос не про плохие запросы и как их искать, а про большой процент нахождения системы в режиме ядра.

edi
() автор топика
Ответ на: комментарий от edi

или драйвер какой-то жрёт проц или системных вызовов много. Я бы стал грешить не на ядро а на ПО.

true_admin ★★★★★
()
Ответ на: комментарий от edi

>вопрос не про плохие запросы и как их искать, а про большой процент нахождения системы в режиме ядра. 

Возможно мускуль в этом и виноват.
Ну или как-то провоцирует.

Если есть возможность, остановить его на несколько секунд и посмотреть загрузку.

dzoleg
()
Ответ на: комментарий от dzoleg

возможность остановить есть, при остановке нагрузка сразу уходит на 0.
mpstat -P ALL 1 показывает такую картинку
04:14:49 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
04:14:50 PM  all   36.12    0.00   36.38    0.00    0.00    0.38    0.00   27.12   3008.08
04:14:50 PM    0   35.35    0.00   39.39    0.00    0.00    2.02    0.00   23.23   2848.48
04:14:50 PM    1   37.37    0.00   40.40    0.00    0.00    0.00    0.00   23.23     55.56
04:14:50 PM    2   34.34    0.00   34.34    0.00    0.00    0.00    0.00   32.32      3.03
04:14:50 PM    3   38.38    0.00   34.34    0.00    0.00    0.00    0.00   28.28      3.03
04:14:50 PM    4   41.41    0.00   39.39    0.00    0.00    0.00    0.00   20.20      3.03
04:14:50 PM    5   37.37    0.00   34.34    0.00    0.00    0.00    0.00   29.29      3.03
04:14:50 PM    6   33.33    0.00   34.34    0.00    0.00    0.00    0.00   32.32     86.87
04:14:50 PM    7   33.33    0.00   35.35    0.00    0.00    0.00    0.00   31.31     10.10

Интересно, почему почти все прерывания падают на одно процессорное ядро - нулевое.
Это косяк или особенность?

edi
() автор топика
Ответ на: комментарий от edi

это для увеличения производительности. Чтобы interrupt handlerы почём зря не мигрировали по процам. interrupt handler affinity, вроде, называется.

Ты тут грил что у тебя мускул круто настроен. А ты проверял? :). Ядры, как видим, ты уже обновил. А мускул? :). Там, вроде, очень древний и бажный мускул.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

> Ядры, как видим, ты уже обновил. А мускул? :)
mysql  Ver 14.12 Distrib 5.0.51b, for redhat-linux-gnu
не самый новый, но тем не менее вполне рабочий.

есть у мну еще один сервер такой-же тоже с мускулом таким-же и ядром.
там mpstat -P ALL 1 даёт такую картину:
09:30:50 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
09:30:51 PM  all    1.50    0.00    1.25   60.67    0.12    0.62    0.00   35.83   5239.39
09:30:51 PM    0    0.00    0.00    1.01   30.30    0.00    1.01    0.00   67.68    601.01
09:30:51 PM    1    1.01    0.00    1.01   69.70    0.00    0.00    0.00   29.29    602.02
09:30:51 PM    2    1.01    0.00    2.02   97.98    0.00    0.00    0.00    0.00    601.01
09:30:51 PM    3    1.01    0.00    1.01  100.00    0.00    0.00    0.00    0.00    602.02
09:30:51 PM    4    1.01    0.00    0.00    0.00    0.00    1.01    0.00   98.99    601.01
09:30:51 PM    5    1.01    0.00    1.01   98.99    0.00    1.01    0.00    0.00    601.01
09:30:51 PM    6    7.07    0.00    5.05   86.87    0.00    2.02    0.00    0.00   1024.24
09:30:51 PM    7    0.00    0.00    1.01    5.05    0.00    0.00    0.00   93.94    607.07

и с нагрузкой всё окей. бывают, конечно, кратковременные всплески, но в целом картина благоприятная.

т.е. крайне неравномерное распределение прерываний по ядрам процессоров не лучшим образом сказывается на производительности. видимо достигается пик по количеству прерываний, больше которого ядро переварить не в состоянии и система "встаёт колом". 
перезагрузка не помогла. 

edi
() автор топика
Ответ на: комментарий от edi

что-то у меня сомнения на счёт твоей теории, 3тыщи прерываний это фигня. Кстати, можно посмотреть что это за прерывания, тока как смотреть не помню.

А что top показывает на второй машине?

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

> Кстати, можно посмотреть что это за прерывания
Вот этот вопрос оказывается меня и интересовал.
файл /proc/interrupts показывает распределение прерываний по процессорам. а файлы /proc/irq/<irq num>/smp_affinity задают маски по которым прерывания распределяются на процессоры.
В общем нашел косячное прерывание раскинул его на несколько процессоров, завтра посмотрю как оно под нагрузкой работать будет.

edi
() автор топика
Ответ на: комментарий от true_admin

top - 17:49:39 up 1 day, 9 min,  1 user,  load average: 4.64, 4.42, 6.28
Tasks: 148 total,   2 running, 146 sleeping,   0 stopped,   0 zombie
Cpu(s): 30.9%us, 17.0%sy,  0.0%ni, 51.2%id,  0.4%wa,  0.1%hi,  0.5%si,  0.0%st
Mem:   8309708k total,  7977940k used,   331768k free,   395628k buffers
Swap:  4096532k total,      144k used,  4096388k free,  5579764k cached

edi
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.