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

Ну как бы стандартный вопрос - MyISAM vs InnoDB - что используете ?

Использую MyISAM

попробуйте использовать insert delayed.

sir_nuf_nuf, мне кажется это не решит проблемы, сейчас запросы собираются в очередь в программе, из за этого она сжирает всю память и умирает, если я правильно понял то insert delayed только переведёт эту очередь на сторону mysqld, то есть будет умирать mysql ...


Есть вариант увеличения работоспособности , но это затратно RAID 0+1

есть ещё идеи ?

Что Вы скрыли под термином "многострочная вставка"? пример плиз... скажем сборки трёх простеньких запросов (2 поля хватит).

Таблица :


В клиентской части (Perl скрипт) формируется очередь из данных на вставку, отдельный поток берёт из очереди данные и постепенно формирует запрос из 2000 записей, а потом отправляет на выполнение mysql ....

Кто Вас научил ТАК писать запросы??? 
1) Список полей следует перечислять ЯВНО.
2) Автоинкрементное ключевое поле в набор полей НЕ включается.


Добавлено через 2 минуты и 32 секунды
Кстати...    ignore - это прелестно, но ошибки всё-таки надо обрабатывать. Или хотя бы ловить.

Akina, прибавки в скорости это не дало никакой.

А я как бы и не ожидал...


А с чего ты решил, что он будет умирать? Он будет сливать записи в таблицу по мере возможности. Кстати, каково соотношение запросов запись/чтение в таблицу?
С дугой стороны - объясни, почему ты не хочешь сливать записи по мере их появления? зачем тебе непременно хочется набрать большую пачку? чем это оправдано?

Akina,


так как запросы будут Mysql по мере возможности будет сливать записи, а остальные будут оставаться в очереди и хранится в оперативной памяти, а памяти на сервере всего 1gb, если mysql и не упадёт, то и работоспособной система оставаться не будет.



не думаю что 2000 запросов выполнится быстрее чем 1 но с большим количеством данных

На потолке подсмотрел? Может вполне быть, что 2000 запросов отработают быстрее. 
У тебя перл и мускул - на одной машине или на разных? если на разных - выделенный ли меж ними сегмент и какой пропускной способности? если на одной - то откуда берутся вообще эти 2000 записей? а дисковая подсистема на машине с мускулом - нормальная?


А какие задачи на сервере? сколько остаётся собственно серверу БД?

nIkTo, конкретные цифры назови, сколько занимает вставка этих 2000 строк.
Как я понимаю, это вдс-сервер и при превышении лимита памяти убивается процесс с наибольшей памятью. Так?

nIkTo, заместо извращения со склейкой данных в одну пачку могу порекомендовать делать insert как prepared statement. 
Т.е. один раз подготовить statement а потом вставлять данные.

sir_nuf_nuf, если правильна вас понял, сделал так :


но опять же тут будет выполнятся 2000 запросов вместо 1.
Итог: через минуту в очереди $insert 122129 

nIkTo, Да, но очередь будет на стороне MySQL. 

И вообще, если у вас данные поступаю с такой частотой, что MySQL (на данной машине) не успевает их писать в таблицу - вас ничто не спасет от переполнения очереди.

Теперь техническая сторона вопроса: как сделать так что бы MySQL успевал ?
1) проверьте что это вообще возможно на вашей машине:
1.1) пишите в самую простую таблицу без доп. UNIQUE индексов, можно  вообще без индексов.
1.2) почитайте документацию и оптимизируйте буфера MyISAM
1.3) посмотрите (top, iostat, systat) во что упирается система при записи (по идее должна в диск)
1.4) Akina наверняка еще добавит что-то

Если все сделали и все равно очередь растет - у вас слабая машина. 

Кстати та часть скрипта которая пишет в очередь ($insert->enqueue) должна проверять ее наполнение и приостанавливаться если очередь полна.

Это много или мало ?

8 мегабайт? при гектаре на сервере?
Сам-то как думаешь... кстати, по дефолту 16М

1) Многострочная вставка - это правильно. Тут могу порекомендовать написать небольшой тест-скрипт, померить удельную скорость от изменения кол-ва данных в одной пачке именно ваших запросов, имеет смысл попробовать увеличить кол-во. В какой-то момент скорость перестанет расти.


Не может, увы. И не вижу причин упоминания потолка, даже если у вас нет практического опыта, представьте весь процесс вставки и посчитайте накладные расходы.

2) Основная проблема в ключе по varchar. Вы можете оптимизровать структуру таблицы, завести числовое поле равное какой-нибудь функции от row_name (например, crc32 (int) или половинке от md5 (bigint)), и уникальный ключ строить по ниму. Есть небольшая вероятность коллизий, но оно того стоит.

3) Есть такая фишка - delay_key_write. Если его включить, для данной таблицы или для всех, это в зависимости от значения key_buffer_size снизит вам нагрузку на диск при записи в таблицы. Есть минус - умирание mysql'я приведёт к порче индексов всех таблиц, для которых была включенна отложенная запись ключей. Но это решается myisamchck'ом перед стартом. Работает оно просто - пока есть свободный key_buffer - пишет ключи в момент выполнения запроса в память. Чтобы получить какой-то значимый эффект нужно увеличить key_buffer_size соразмерно кол-ву данных или возможностям хоста. Следить за наполнением буффера ключей можно через show global status like 'key_b%';

Простейший пример - неустойчивый канал связи с большим процентом потерь.

Замечательный пример. Возьмите tcpdump и посчитайте кол-во пакетов в случае с одним запросом из 2000 строк и 2000 запросов. А теперь умножьте разницу на процент потерь и получится кол-во ретрансмитов, умножьте на задержку в сети и получите время, на которое 2000 запросов дольше одного запроса только лишь из-за сетевых проблем.

Это сообщение отредактировал(а) muzer - 5.10.2010, 12:43