Низкая скорость записи данных в mysql, как ускориться?

Ю
На сайте с 24.03.2013
Offline
15
9622

Добрый день!

Есть БД mysql, на текущий момент размером в 7 GB. Таблицы InnoDB.

На начальном, этапе при сборе данных в базу, скорость создания комплектов записей (несколько связанных записей в разных таблицах) составляла 100-130 в минуту.

Сейчас идет пересчет базы, через update. Сначала скорость обработки комплектов записей была примерно прежней 100-130 в минуту, но потом резко упала до 10-20 в минуту.

Причем скорость создания одного комплекта записей меняется от 0,1 сек до 15 сек.

Попытался разобраться с настройкой mysql (файл my.cnf). Мало что в этом понимаю. Cтояли совсем скромные параметры по умолчанию. Поставил

innodb_buffer_pool_size = 6G

Поменял еще пару настроек, остальное не трогал.

Теперь mysql стал использовать больше памяти (с 0,5 ГБ до 1,9 ГБ), но все равно не весь разрешенный объем.

Загрузку процессора не полная (intel core i7).

top - 13:42:57 up 3:58, 1 user, load average: 2.78, 3.02, 3.18
Tasks: 137 total, 2 running, 135 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.8 us, 5.1 sy, 0.0 ni, 80.2 id, 3.9 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 16156044 total, 9949348 used, 6206696 free, 864868 buffers
KiB Swap: 8387568 total, 0 used, 8387568 free, 5975988 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2886 mysql 20 0 7030m 1.9g 8160 S 104.1 12.1 236:22.69 mysqld

Получается, что раз БД не использует оперативную память, процессоры не загружены, то проблема в скорости записи на HDD? (стоят 2 обычных HDD в raid 1). Не знаю как это проверить.

Можно как-то ускорить процесс? Например, как то заставить mysql сливать изменения на HDD раз в минуту.

Может проблема в чем-то другом и поможет грамотная настройка my.cnf?

Приведу результаты анализа через mysqltuner:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.31-0+wheezy1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 4G (Tables: 244) //это другая БД, но с ней проблем нет, 99% операций на чтение
[--] Data in InnoDB tables: 6G (Tables: 27)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 744K (Tables: 12)
[!!] Total fragmented tables: 40

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2h 57m 3s (1M q [171.188 qps], 35K conn, TX: 5B, RX: 316M)
[--] Reads / Writes: 84% / 16%
[--] Total buffers: 6.1G global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 6.5G (41% of installed RAM)
[OK] Slow queries: 0% (7/1M)
[OK] Highest usage of available connections: 11% (17/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/1.0G
[OK] Key buffer hit rate: 98.9% (73M cached / 808K reads)
[OK] Query cache efficiency: 54.1% (836K cached / 1M selects)
[!!] Query cache prunes per day: 4521356
[OK] Sorts requiring temporary tables: 2% (649 temp sorts / 31K sorts)
[OK] Temporary tables created on disk: 0% (79 on disk / 69K total)
[OK] Thread cache hit rate: 99% (141 created / 35K connections)
[OK] Table cache hit rate: 28% (400 open / 1K opened)
[OK] Open file limit used: 58% (604/1K)
[OK] Table locks acquired immediately: 99% (876K immediate / 876K locks)
[!!] InnoDB data size / buffer pool: 6.7G/6.0G

Evas EvaSystems
На сайте с 31.05.2012
Offline
116
#1

Ну как минимум, это innodb_buffer_pool_size должен быть больше или равен InnoDB data size, а так же

Key buffer size должен быть больше или равен всему размеру индексов, innodb_flush_log_at_trx_commit = 0

и innodb_flush_method = O_DIRECT. InnoDB медленнее, чем Myisam, но надёжнее в плане восстановления после сбоя.

Лучше уделите внимание нормальной настройке my.cnf, почитайте разные манюалы, советы людей и т.д.

Ну а вообще, надёжнее будет нанять специалиста для этого.

P.S. SSD диск так же, существенно, ускорит всё ваше добро...

Системный администратор Linux. Настройка, сопровождение и оптимизация серверов. Отзывы - searchengines.guru/ru/forum/1017473
Ю
На сайте с 24.03.2013
Offline
15
#2

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

Ю
На сайте с 24.03.2013
Offline
15
#3

Скорость обработки дошла до 0,01-0,03 сек. против 1-15 сек ранее. Это ускорение в 100-500 раз. Если бы скрипт не содержал вычислений, а состоял только из записи в БД, то прирост был бы еще значительнее. Просто чудеса благодаря четырем параметрам в my.cnf

DV
На сайте с 01.05.2010
Offline
644
#4

Имейте в виду, что кэш со временем "прогревается" и работает быстрее сам по себе.

VDS хостинг ( http://clck.ru/0u97l ) Нет нерешаемых задач ( https://searchengines.guru/ru/forum/806725 ) | Перенос сайтов на Drupal 7 с любых CMS. ( https://searchengines.guru/ru/forum/531842/page6#comment_10504844 )
soko1
На сайте с 02.05.2014
Offline
3
#5
Юрий_:
Добрый день!
Можно как-то ускорить процесс? Например, как то заставить mysql сливать изменения на HDD раз в минуту.

Советую вам поиграться с sysctl-переменными, подробнее можно тут почитать, например: http://drupal-admin.ru/blog/%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-linux-%D0%BF%D0%BE%D0%B4-%D0%BD%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D1%83-%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%B9-%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8-%D0%BD%D0%B0-%D0%B4%D0%B8%D1%81%D0%BA

Вот из основного:


/proc/sys/vm/dirty_writeback_centisecs (default 500): в сотых долях секунд. Этот параметр означает как часто pdflush возобновляет работу для записи данных на диск. По умолчанию возобновляет работу 2 потока каждые 5 секунд.
Возможно недокументированное поведение, которое пресекает попытки уменьшения

dirty_writeback_centisecs для более агрессивного кэширования данных процессом pdflush. Например, в ранних версиях ядра 2.6 Linux в файле mm/page-writeback.c код включал логику, которая описывалась "если запись на диск длится дольше, чем параметр dirty_writeback_centisecs, тогда нужно поставить интервал в 1 секунду". Эта логика описана только в коде ядра, и ее функционирование зависит от версии ядра Linux. Так как это не очень хорошо, поэтому вы будете защищены от уменьшения этого параметра.

/proc/sys/vm/dirty_expire_centiseconds (default 3000): в сотых долях секунд. Этот параметр указывает как долго данные могут находится в кэше, после чего должны быть записаны на диск. Значение по умолчанию очень долгое: 30 секунд. Это означает, что при нормальной работе до тех пор пока в кэш не запишется достаточно данных для вызова другого метода pdflush, Linux не будет записывать данные на диск, находящиеся в кэше менее 30 секунд.

/proc/sys/vm/dirty_background_ratio (default 10): Максимальный процент оперативной памяти, который может быть заполнен страничным кэшем до записи данных на диск. Некоторые версии ядра Linux могут этот параметр устанавливать в 5%.
В большинстве документации этот параметр описывается как процент от общей оперативной памяти, но согласно исходным кодам ядра Linux это не так. Глядя на meminfo, параметр dirty_background_ratio расчитывается от величины MemFree + Cached - Mapped. Поэтому для нашей демонстрационной системы 10% составляет немного меньше, чем 250MB, но не 400MB.

Ну и да, SSD - неплохой выход из ситуации, тем более что у вас не такая уже и объёмная база.

Оперативно поможем вам в решении ваших проблем: /ru/forum/814513 (/ru/forum/814513)
iamsens
На сайте с 26.08.2009
Offline
115
#6

Evas, всё верно написал, но

InnoDB - быстрее

Myisam - надежне

[Удален]
#7
iamsens:
Evas, всё верно написал, но
InnoDB - быстрее
Myisam - надежне

Ничего не перепутали?

---------- Добавлено 12.05.2014 в 20:01 ----------

Кроме того innoDB таки может быть и быстрее, зависит от структуры скрипта, запросов.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий