LINUX.ORG.RU
ФорумAdmin

MySQL сильно потребляет процессор


2

1

Доброго времени суток, уважаемые коллеги. Столкнулся я вот с такой проблемой: хотели увеличить скорость работы сайта, за счёт увеличения кэшей в озу и перехода на SSD переехали c: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz 8 GB RAM 200GB HDD на сервер: AMD Opteron 3280 8 x 2,4 GHz 32 GB RAM 250GB SSD

А получили напротив жёсткие тормоза в часы пик. Сейчас пишу пост, всё летает, а по вечерам - тормоза. MySQL жрёт ЦПУ ядер 5, load average 12-15 иногда даже до 30 доходит. Наши характеристики в часы пик ~75 посетителей онлайн, количество запросов в секунду почему-то после переезда выросло с 8 до 30, в то же время посещаемость сильно не изменилась.

Уже так и этак колдую с конфигом, c mysqltuner'ом и руками, немного ситуацию улучшил конечно, но проблема не уходит, скорость в часы пик ниже чем до переезда. Вот какой конфиг получился:

[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0

[mysqld]
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
lc-messages-dir	= /usr/share/mysql
skip-external-locking

key_buffer		= 16M
max_allowed_packet	= 16M
thread_stack		= 192K
thread_cache_size       = 64
myisam-recover         = BACKUP
#max_connections        = 300
query_cache_limit	= 1M
expire_logs_days	= 10
max_binlog_size         = 100M

#important optimize
table_cache             = 800
query_cache_size       = 512M
join_buffer_size       = 1G
memlock

#innidb configure
innodb_buffer_pool_size = 16G
innodb_log_buffer_size=4M
#innodb_flush_logs_at_trx_commit=2
innodb_thread_concurrency=50
innodb_flush_method=O_DIRECT
innodb_file_per_table
innodb_additional_mem_pool_size = 32M

max_heap_table_size = 256M
tmp_table_size = 256M
low_priority_updates = 1
key_buffer_size = 256M
max_length_for_sort_data = 1048576
sort_buffer_size = 268434432
read_rnd_buffer_size = 268434432

server-id=XXXXXXX
log_bin=mysql-bin
log_error=mysql-bin.err
binlog_do_db=XXXXXX
binlog_do_db=XXXXX
log_slave_updates=1
auto_increment_offset=2
auto_increment_increment=2

bind-address            = XXX.XXX.XXX.XXX

log-slow-queries=/var/log/mysql/slow.log
relay-log = /var/log/mysql/slave-relay-bin
relay-log-index = /var/log/mysql/slave-relay-bin.index
slave-skip-errors = all

[mysqldump]
quick
quote-names
max_allowed_packet	= 16M

[mysql]
[isamchk]
key_buffer		= 16M

!includedir /etc/mysql/conf.d/

character_set_server  = utf8
collation_server      = utf8_general_ci

Как можно решить проблему? (базы на innodb, mysql 5.5)



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

Столкнулся я вот с такой проблемой: хотели увеличить скорость работы сайта, за счёт увеличения кэшей в озу и перехода на SSD переехали c: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz 8 GB RAM 200GB HDD на сервер: AMD Opteron 3280 8 x 2,4 GHz 32 GB RAM 250GB SSD

ИМХО у тебя было узкое место в HDD, и процессор успевал всё что надо просчитать, пока оно тупило в ожидании данных с HDD. А теперь не тупит, а считает.

за счёт увеличения кэшей в озу

во первых верни кеши обратно.

emulek
()

Увеличение кэшей в озу должно быть пропорционально скомпенсировано увеличением ОЗУ. Иначе постоянный свопинг и жуткие тормоза.

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

ну так оно пропорционально, чтобы увеличить кеши увеличили озу с 8 гб до 32 гб, как видно из описания. Своп пустой, mysql я вообще запретил туда суваться.

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

А можно вкратце что он там советует, а то на работе смотреть 30 минут видео - непозволительная роскошь)

whitemaster
() автор топика

для начала верни все настройки мускуля в дефолтные, потом анализируй

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

на дефолтных можно сразу вешаться, с них и начинал)

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

%wa время потраченное процессом на ожидание устройств ввода вывода. Посмотреть можно в top, atop ну или в (предпоследняя колонца)

]# vmstat -wn 2
procs -------------------memory------------------ ---swap-- -----io---- --system-- -----cpu-------
 r  b       swpd       free       buff      cache   si   so    bi    bo   in   cs  us sy  id wa st
 0  0       7376     128176     337880    1685256    0    0     2     5    0    0   0  0 100  0  0

Конечно маловероятно. но я бы проверил что он в норме. Вдруг это у вас «блочная запись» на SSD чудит

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

Открываешь top и смотришь на %io

на дефолтных можно сразу вешаться, с них и начинал)

У тебя тоже какой-то бред там.

innodb_buffer_pool_size = 16G

На поток! При стандартных 8 метрах!

Вопрос - у тебя mysql память всю не отжирает?

С твоими настройками у тебя пиковое потребление при полной нагрузке до 247892 метров (со стандартными - 576).

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

Цитирую:

Если у вас есть выделенный сервер для MySQL и вы используете только innodb-таблицы, возможно вы захотите отдать всю неиспользуемую память для пула буферов InnoDB.

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

15.11.07

Ты ничего старее не мог найти?

Как минимум query_cache_size уменьши до 64 метров для проверки.

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

devl547 ★★★★★
()
Последнее исправление: devl547 (всего исправлений: 3)
Ответ на: комментарий от devl547

а разница? идеи то правильные, если 7 лет назад при том оборудовании рекомендовали использовать 12 GB на кеш при 16 GB в наличии, то сейчас и подавно. Тем более что писалось под MySQL 5.5, так что никаких противоречий. Да я и сам проверил на своём опыте, при уменьшение размера буфера нагрузка на процессор возрастает. У меня размер файлов БД+индексы 12 GB, так что 16 GB на буфер - оптимальное значение с учётом постоянного роста БД

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

ну попробовал, поставил 64M ради интереса. сервер лёг намертво. в срочном порядке вернул на рабочий конфиг

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

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

просто добавили памяти? А настройки?

Своп пустой, mysql я вообще запретил туда суваться.

это не самая лучшая идея. Что в тестинге, что тем более в продакшене.

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

да, было узкое место в HDD, даже в консоли были жуткие лаги, но работало то лучше в часы пик

теперь упёрлось в CPU. Может кеши настолько большие, что CPU не успевает их все просчитать. Мало данных для анализа.

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

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

это верно.

emulek
()

Я так понимаю, посмотреть explain на запросы из show full process list в момент «затупливания» ни у кого смекалки не хватило? Если раньше было много IO => сейчас говнистые запросы без индексов (или упаси боже с filesort'ом) выполняются в огромном количестве.

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

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

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

Воспользовался вашим генератором, получил вот такую конфигурацию:

# Generated by Percona Configuration Wizard (http://tools.percona.com/) version REL5-20120208
# Configuration name server generated for whthaker@gmail.com at 2014-01-29 10:27:04

[mysql]

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

[mysqld]

# GENERAL #
user                           = mysql
default-storage-engine         = InnoDB
socket                         = /var/lib/mysql/mysql.sock
pid-file                       = /var/lib/mysql/mysql.pid

# MyISAM #
key-buffer-size                = 32M
myisam-recover                 = FORCE,BACKUP

# SAFETY #
max-allowed-packet             = 16M
max-connect-errors             = 1000000

# DATA STORAGE #
datadir                        = /var/lib/mysql/

# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

# REPLICATION #
relay-log                      = /var/lib/mysql/relay-bin
slave-net-timeout              = 60

# CACHES AND LIMITS #
tmp-table-size                 = 32M
max-heap-table-size            = 32M
query-cache-type               = 0
query-cache-size               = 0
max-connections                = 500
thread-cache-size              = 50
open-files-limit               = 65535
table-definition-cache         = 1024
table-open-cache               = 2048

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

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

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

В общем то да, в целом похоже на мою конфигурацию. Попробую даже ради интереса поставить на продакшен сервер, посмотреть что получится, только не в час пик, а утром для начала.

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

А что нужно для перехода на postgresql? Какие там есть инструменты для администрирования? хорошо ли работает репликация Master-Master?

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

если 7 лет назад при том оборудовании рекомендовали использовать 12 GB на кеш при 16 GB в наличии

Тебе говорят про query_cache_size а не innodb_buffer_pool_size

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

А что нужно для перехода на postgresql?

apt-get install postgresql

Какие там есть инструменты для администрирования?

psql, pgadmin

хорошо ли работает репликация Master-Master?

конкретно это не пробывал

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

ок, база на psql. Начинает тупо тормозить при insert. Как лечить?

переливать старые данные в другие таблицы, снимать констрейнты, юзать COPY, перестраивать и менять индексы

quest ★★★★
()
Последнее исправление: quest (всего исправлений: 1)
Ответ на: комментарий от whitemaster

512Mb может быть тоже слишком много. Если кеш запросов будет забиваться запросами, которые выполняются только 1 раз, то потом он будет долго чистится.

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

уменьшил, вроде всё так-же как и было. А вот mysqltuner ещё предлагает: join_buffer_size (> 1.0G, or always use indexes with joins) стоит увеличивать?

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

join_buffer_size (> 1.0G, or always use indexes with joins) стоит увеличивать?

стоит «always use indexes with joins»

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