LINUX.ORG.RU

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


0

0

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

Я создал такую таблицу:
CREATE TABLE stack
(
id INT NOT NULL AUTO_INCREMENT,
infa VARCHAR(64) UNIQUE NOT NULL,
view BOOL,
PRIMARY KEY (id)
);

Всего есть три запроса:

взять для обработки:
db.query('select infa from stack where view=0 limit 1')

пометить как взятое:
db.query(«update stack set view=1 where infa='%s'» % infa)

и вставить полученные данные запросом:
insert ignore into stack (infa, view) values ('foo', 0),('bar', 0) итд.

Я знаю, что запросы уязвимы, но тут данным можно доверять.

Проблема в том, что когда работают 10 экземпляров скрипта загрузка процессора mysql'ем составляет уже 60-70%, а мне нужно 20-30 экземпляров, дабы они обеспечивали полное использование интернет канала. Сейчас в базе 4.5 млн записей.

Все это происходит на Debian Squeeze, Pentium-4 2.6, 1024 ram. Сам скрипт на питоне с использованием mysql-python.

Собственно вопрос - что, где подкрутить дабы исправить ситуацию?

И да, я включал и смотрел mysql-slow.log и ничего там не обнаружил.



Последнее исправление: PoMbl4 (всего исправлений: 1)

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

Я не замерял процессорное время когда тестировал, но нагрузку делал приличную, мускл отлично справлялся со вставкой в таблицу содержащей десятки миллонов записей. Он у меня 1,5к инсертов в секунду отрабатывал. И кстати, тестил я связку lighttpd + perl + FastCGI + MySQL/MyISAM. Один перловый процесс обрабатывал всю нагрузку.

Reaper ★★
()

Предполагаю, что тебя интересует не загрузка процессора, а какое количество запросов при этом будет обслужено. Тут надо тестировать с разным количеством потоков. Может получиться, что при 8-ми потоках ты получишь максимальную производительность (которой тебе будет достаточно) и нагрузку на проц 20%, а при 16-ти нагрузка на проц вырастет, а производительность упадет.

Если нужна многозадачность, то, возможно, тебе больше подойдет postgrsql. Но у него с синтаксисом жестче и могут быть другие причины по которым он не подойдет для твоего проекта.

В твоем проекте может получиться, что для поля

infa VARCHAR(64) UNIQUE NOT NULL,

лучше будет избавиться от UNIQUE, а вместо этого считать хеш от строки на стороне скрипта и хранить его в виде, например, пары BIGINT. А уже для этой пары сделать constraint UNIQUE.

Liosha_Syrnikov
()

Сделал так, чтобы скрипт читал/писал помногу, но редко. Так что проблему можно считать решенной.

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