LINUX.ORG.RU
ФорумAdmin

Холодный старт MariaDB

 ,


0

1

Приветствую.

  • Сервер с Xeon D-1521 и 32 ГБ ОЗУ.
  • CentOS 7.2.1511.
  • MariaDB 5.5.49.
  • Базы данных находятся на SSD-разделе.

Проблема касается любого сайта/базы на сервере. Если сайт какое-то время (допустим, 1 час) был неактивен, то при первом заходе на него очень долго обрабатываются SQL-запросы, около 8-10 секунд. Обновляешь страницу - грузится моментально. Сайт - обычная легкая пустышка на wordpress. Включение или выключение query-cache никак не влияет на ситуацию.

Если выполнить sync && echo 3 | tee /proc/sys/vm/drop_caches, то эффект будет такой же: холодный старт.

Вопрос: как и что сделать, чтобы холодный старт базы был минимальным?

/etc/my.cnf.d/server.cnf:

[mysql]

# CLIENT #
port                           = 3306
socket                         = /var/lib/mysql/mysql.sock

[mysqld]

# GENERAL #
port            = 3306
#bind-address    = 0.0.0.0
socket          = /var/lib/mysql/mysql.sock
pid-file        = /var/run/mysqld/mysqld.pid
default-storage-engine         = InnoDB

# MyISAM #
key-buffer-size                = 1G
myisam-recover                 = FORCE,BACKUP

# SAFETY #
max-allowed-packet             = 16M
max-connect-errors             = 1000000
#skip-name-resolve
sysdate-is-now                 = 1

# CACHES AND LIMITS #
tmp-table-size                 = 32M
max-heap-table-size            = 32M
query-cache-type               = 1
query-cache-size               = 256M
query-cache-limit              = 1M

max-connections                = 500
thread-cache-size              = 50
open-files-limit               = 65535
table-definition-cache         = 4096
table-open-cache               = 3000

# INNODB #
innodb-buffer-pool-size        = 12G
innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-log-file-size           = 512M
innodb-flush-log-at-trx-commit = 2
innodb-file-per-table          = 1
#innodb_data_file_path          = ibdata1:512M:autoextend

# LOGGING #
#log-queries-not-using-indexes  = 1
#slow-query-log                 = 1
#slow-query-log-file            = /var/lib/mysql/mysql-slow.log


[mysqldump]
quick
single-transaction
max_allowed_packet              = 16M

[mysql]
no_auto_rehash


очень долго обрабатываются SQL-запросы, около 8-10 секунд.
Сайт - обычная легкая пустышка на wordpress.

«вэб макаки» все продолжают удивлять... у одного 10к файликов для открытия страницы читаются, у другого для «пустышки sql запрос 8-10 секунд»....
хотя чему я удивляюсь, полгода назад одни такие для страницы на которой только фраза «сайт заработает через и счетчик обратного отсчета» битрикс покупали...

anc ★★★★★
()

workaround: в крон таску, которая обходит все урлы в sitemap.xml раз в 10 минут.

а так да, лечить надо вордпресс, вангую seq scans, тоесть отсутствие индексов :)

vadv ★★
()
Ответ на: комментарий от vadv

вангую seq scans, тоесть отсутствие индексов

Правдоподобно. Можно поставить в WP плагин query monitor, посмотреть какие запросы выполняются по несколько секунд, посмотреть план выполнения этих запросов.

Помнится как-то мне попался sql-дамп в который phpmyadmin «забыл» добавить создание индексов (оказывается в этом поделии есть такая опция).

MrClon ★★★★★
()
Ответ на: комментарий от anc

Пожалуй, мне стоило уточнить: на сайте не 1 сайт на wordpress (это было в качестве примера), а около 2000 сайтов на чем угодно. Это сайты клиентов, поэтому никакие индексы, обход по sitemap и прочее я делать не могу и не буду. Вопрос про холодный старт остается открытым.

skel1
() автор топика
#slow-query-log                 = 1
#slow-query-log-file            = /var/lib/mysql/mysql-slow.log

Включи, тогда увидишь что тормозит.

anonymous
()
Ответ на: комментарий от anonymous

Сами запросы исполняются быстро: http://storage1.static.itmages.com/i/16/0822/h_1471865189_3399896_ae680f93a0.png, но общее время ожидания/выполнения 6 секунд.

Может есть какой-то плагин для того же WP, чтобы увидеть «connect time» или что-то в этом духе?

skip-name-resolve прописан, если чо.

skel1
() автор топика
Ответ на: комментарий от deterok

Фигня в том что заглушку надо было повесить «еще вчера» а из-за битрикса этот процесс растянулся по времени.

anc ★★★★★
()
Ответ на: комментарий от skel1

1. Можно посмотреть tcpdump.
2. Тот же запрос в консольной mysql так же долго будет выполняться?

anc ★★★★★
()
Ответ на: комментарий от skel1

Сами запросы исполняются быстро

Тогда почему вы думаете, что дело в БД? Там database query time 0.02s. Вангую что дело в том, что в опкеш пхп не влазят все сайты, вот он и сбрасывается.

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

Никаких пхп-акселераторов мы не используем. Но в целом наводка верная, да, мы вроде и сами выяснили, что MariaDB не при чем и отрабатывает быстро. Пока что тестируем, выясняем причину.

skel1
() автор топика
Ответ на: комментарий от skel1

Вообще-то похоже на то когда сервер (засыпает) или выгружает из памяти на диск часть вашей подсистемы для экономии ресурсов. Т.ч. пост выше про cron думаю решит вашу проблему, хотя можно и с более полезной целью сделать тоже самое, добавьте проверки в систему мониторинга которая будет каждую 1-3 монуты дергать Вашу базу. Это самый рациональный вариант. Глубокая проверка работоспособности базы плюс поддержание ее в бодрствующем состоянии.

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