Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MySQL > MySQL грузит процессор на все 100%

Автор: nIkTo 4.8.2010, 14:38

Доброго времени суток. Подскажите как уменьшить нагрузку на процессор.
Раз в минуту скрипт делает выборку заданий :

Код


select * from tasks where status='wait' limit 5000

как только MySQL начинает обрабатывать этот запрос сервер застывает секунд на 5, такие провисания не приемлемы, в таблице около 30милионов записей.
Структура таблицы:

Код


create table tasks (
            id int not null auto_increment,
            query varchar(50) not null,
            language char(2) not null,
            status char(4) not null,
                        primary key (id),
                        unique key (query, language))
                        character set utf8 collate utf8_bin

Подскажите как оптимизировать мускул чтобы он имел так сказать планку и выше не прыгал. Может что-нибудь в конфигах MySQL сервера оптимизировать ?
Буду благодарен за любые идеи.

Pentium® 4 CPU 2.40GHz
MySQL 5.0.67

Автор: skyboy 4.8.2010, 15:00

что показывает explain? и, может, есть смысл проиндексировать поле status?

Автор: nIkTo 4.8.2010, 15:43

skyboy, explain говорит:

Цитата

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE tasks ALL NULL NULL NULL NULL 29250194 Using where

skyboy, сколько на это времени примерно уйдёт? Подозреваю что не мало.

Автор: nIkTo 4.8.2010, 18:14

Код


alter table tasks add index (status)

прошло 2 часа, поле ещё индексируется =)

Что быстрее бы отрабатывало (выборка из базы), если для поля status использовать (имеет 3 состояния) :

status tinyint(1) not null default 0, key (status)
status int(1) not null default 0, key (status)
status set('0','1','2') not null default 0, key (status)
status tinyint(1) not null default 0, key (status(1))
status int(1) not null default 0, key (status(1))
status set('0','1','2') not null default 0, key (status(1))

Автор: skyboy 4.8.2010, 21:10

Цитата(nIkTo @ 4.8.2010, 17:14

)

Что быстрее бы отрабатывало

практически пофиг.

Цитата(nIkTo @ 4.8.2010, 17:14

)

прошло 2 часа, поле ещё индексируется =)

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

Автор: gcc 5.8.2010, 01:19

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

если фрейворк, то можно влючить отладку и смотреть в каких участках медленно выплняются действия

в сложно запросе очень часто можно сделать ошибку, где mysql будет грузить сильно CPU

Автор: nIkTo 5.8.2010, 09:48

Цитата(skyboy @ 4.8.2010, 21:10

)

подскажите как правильней будет перегнать данные в новую таблицу.

Автор: skyboy 5.8.2010, 10:37

я точно не уверен. поиском найти не смог. может, кто-то ещё подскажет.

Автор: skyboy 5.8.2010, 11:27

нашел. я дезинформировал тебя. это было http://habrahabr.ru/blogs/mysql/76149/. и идея не просто в создании копии таблицы, а в последующей подмене MYI-файлов. А затем REPAIR TABLE
Внимание: в той статье говорится о создании уникального индекса. Применимо ли указанное к неуникальному индексу - для меня загадка.
жаль, что без подмены файлов не обойдется :(

Автор: nIkTo 5.8.2010, 11:44

Дело в том что

Код


alter table tasks add index (status)

отработал, но теперь база ведёт себя как-то не адекватно =( выполнение запроса

Код


select count(*) from tasks where status='done'

, вообще не выполняется, точнее мускул начинает обрабатывать этот запрос (видно через дерево процессов) но потом процесс пропадает а ответа нету =(

что делать ?

Добавлено через 4 минуты и 6 секунд
Запросы типа

Код


select * from tasks where status='wait' limit 2000

отрабатывают на ура, в чем тут трабл =(

Добавлено через 6 минут и 23 секунды
explain говорит :

Код


explain select count(*) from tasks where status='done'

Цитата

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE tasks ref status status 12 const 12326762 Using where; Using index

Автор: skyboy 5.8.2010, 11:51

долго индекс создавался-то?
к сожалению, помочь не могу(даже боюсь навредить - опыта работы с такими большими таблицами у меня нет). стоит посмотреть в логах. может, ошибка загрузки индекса в память или ещё что.

Цитата(nIkTo @ 5.8.2010, 10:44

)

отрабатывают на ура

быстрее, после создания индекса?

Автор: nIkTo 5.8.2010, 11:57

skyboy, индекс около 4х часов создавался. Гораздо быстрее стало, раньше ~ 10 сек теперь меньше секунды =)

Автор: Zloxa 6.8.2010, 10:46

Цитата(nIkTo @ 5.8.2010, 11:44

)

explain говорит :

весьма вероятно, для запроса select count(*) from tasks where status='done', использование индекса происходит не на благо а во вред. А план показывает что индекс использвуется.
Если более 20% записей попадают под критерий status='done', то использование индекса для отбора по этому предикату, как правило, оказвается не эффективным. Если этот тот самый случай, лучшеhttp://dev.mysql.com/doc/refman/5.5/en/index-hints.html, что индекс использовать не стоит.

Автор: nIkTo 6.8.2010, 11:49

Zloxa, действительно, игнорируя индекс запрос :

Код


explain select count(*) from tasks ignore index (status) where status='done'

выполняется, хотя и не так быстро как хотелось бы.

Автор: Zloxa 6.8.2010, 11:55

Цитата(nIkTo @ 6.8.2010, 11:49

)

не так быстро как хотелось бы.

было бы настораживающе странно, если бы 30млн записей пересчитались мгновенно.

Автор: Бонифаций 10.8.2010, 10:20

А вот интересно key_buffer_size у вас сколько?

Автор: nIkTo 10.8.2010, 11:14

Бонифаций, в файле my.cnf записано только :

Цитата

[mysqld]
local-infile=0

так что предполагаю key_buffer_size по дефолту

Автор: Бонифаций 12.8.2010, 05:13

Дефольные натсройки - это _очень_мало. Потому и тормоза. У вас, кстати, myisam?