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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

возможность остановить есть, при остановке нагрузка сразу уходит на 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

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

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

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

> Ядры, как видим, ты уже обновил. А мускул? :)
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

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

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

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

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

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

Что за прерывание?

PS Что-то мне подсказывает что это не поможет :)

> Что за прерывание?
eth1

> Что-то мне подсказывает что это не поможет :)
помогло.

покажи top

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