Добрый день!

Есть Windows 7 x64 + MySQL 5.6 на десктопе i5-3470 2.2 GHz RAM 16 GB, RAID 1 для данных, RAID 0 для временных файлов.

MySQL установлен "из коробки", особого тюнинга не производилось. Установлен при помощи мастера в конфигурации Server Machine (там есть еще Developer и Dedicated). Но так как переустанавливать уже лень/долго/проблемно, хочу переконфигурировать сервер.

Проблема в следующем: MySQL не использует больше 25% CPU! Может снижаться до 19-20%, но потом возвращается до 24-25%.
MySQL не обслуживает левые запросы откуда-то из вне, используется тупо для расчетов и выполняет однотипный запрос по очереди по миллионам записей (читает из одной, пишет в другую). На каждый тратится по 13-14 сек. Хочется что бы он "жарил" как следует :)

По данным диспетчера задач подгружается всегда первое ядро, хотя галки стоят на всех четырех. Если отключить первое, то загрузка становится на втором или на третьем.

Каких-то запредельных значений по использованию диска не отмечено, все очень скромно, по данным монитора ресурсов 1-3 Мбит

Так как нигде тормозов не отмечено, полагаю, что MySQL просто скромничает с процессором и время запроса можно было бы сократить раза в 3-4 только процессором.

Any ideas?

V2oD2o,

Вопрос скорее в том почему MySQL использует только один поток.
Фотошоп например кушает все и процент загрузки у него до 100% доходить может.

Запрос примерно такого вида:

f1,f2 - составной индекс уникальных элементов в tab3
123 - целое число
f1,pos - составной индекс уникальных элементов в tab1, tab2

INSERT INTO tab3 (f1,f2,f3)
(
SELECT
'123',
tab1.f1,
@sum := SUM((
SELECT BIT_COUNT(tab1.mm&tab2.mm)
FROM tab2
WHERE tab2.f1 = 123 AND tab2.pos = tab1.pos)) sum
FROM tab1
GROUP BY f1
ORDER BY sum DESC
LIMIT 500
)
ON DUPLICATE KEY UPDATE f3 = @sum

в принципе то все

V2oD2o,

tab1 - это исходная таблица, постоянный рост, важны все данные, около 2 млн записей.
tab2 - это выборка из tab1 по WHERE f1 = 123, значительно ускорило расчет
tab3 - это результат, можно распиливать на старые и новые данные, около 2 млн записей. делать пока не спешу, так как пока не вижу тормозов в этом

SergeyPerm,

LIMIT 500 нужен потому, что не нужна вся выборка из tab1. фильтрация через ORDER BY

ORDER BY sum DESC - нужен как раз потому, что LIMIT 500, так как нужное может не войти в эти 500 :-)

tanglirScareCrow, ну да... только они у ТСа стоят в некой "очереди", и ХШ говорит, что одновременно запускать их нельзя :)
Очередь есть, но запускать то как раз можно... попробую.

Очередь формируется по другим законам, это просто таблица с одним столбцом с идентификаторами, и имеет размеры от 1000-5000, периодически пополняется/оптимизируется по крону... один скрипт берет идентификаторы и удаляет из очереди, другой пополняет :) это удобно когда имеется большой поток данных.

P.S. кстати, если интересно, очередь в другом месте сделана так (фрагмент скрипта bash):
for ID in `mysql -N ... db -e 'SET @uids := null; UPDATE queue SET do = (SELECT @uids := domainId) WHERE do IS NULL LIMIT 1; SELECT @uids'`; do
... тут все остальное с ид=ID
... потом удаляем элемент из очереди
done

Очереди в несколько тысяч элементов отлично отрабатываются, могут быть размещены в памяти. Наложений тоже нет, когда запущено несколько десятков или сотен экземпляров обработчика очереди.

javajdbcИсправленому -- верить:




непонятненько про единички... у меня логическое "И" используется между двумя u/bigint, которое заполнено именно битами со своим порядком (то есть там пофиг какое число), они перемножаются (пересечение), что остается считается, а потом суммируется внутри группы. вот