Остановить MariaDB от процесса блокировки - PullRequest
Новая
       9

Остановить MariaDB от процесса блокировки

0 голосов
/ 12 июня 2018

Мы запускаем установку CentOS DirectAdmin с MariaDB 10.2.14, где установлен Magento.

В настоящее время наша БД очень часто блокируется при запуске процесса, поэтому все остальные процессы ждут завершения текущего процесса.Это довольно проблематично, потому что, например, в этом случае также ожидается процесс добавления в корзину, и люди не могут сделать заказ.

Как мы можем предотвратить блокировку БД так долго и решить эту проблему?

Сервер: 

6x Intel Xeon
32GB RAM
500GB SSD

My.cnf: 

[mysqld]

bind-address = 127.0.0.1
local-infile=0
innodb_file_per_table=1
innodb_file_format=barracuda

slow_query_log = 1
slow_query_log_file=/var/log/mysql-log-slow-queries.log

key_buffer = 250M
key_buffer_size = 250M
max_allowed_packet = 128M
table_cache = 512
sort_buffer_size = 7M
read_buffer_size = 7M
read_rnd_buffer_size = 7M
myisam_sort_buffer_size = 64M
tmp_table_size = 190M
query_cache_type = 1
query_cache_size = 220M
query_cache_limit = 512M
thread_cache_size = 150
max_connections = 225
wait_timeout = 300
innodb_buffer_pool_size = 7G
max_heap_table_size =180M
innodb_log_buffer_size = 36M
join_buffer_size = 32M
innodb_buffer_pool_instances = 7

long_query_time = 15
table_definition_cache = 4K
open_files_limit = 60K
table_open_cache = 50767
innodb_log_file_size= 128M
innodb_lock_wait_timeout = 700

Ответы [ 3 ]

0 голосов
/ 13 июня 2018

Это устарело;их имена изменились.Уберите их: 

key_buffer = 250M
table_cache = 512

Они выше, чем должны быть: 

key_buffer_size = 250M
query_cache_size = 220M
thread_cache_size = 150
long_query_time = 15
table_definition_cache = 4K
table_open_cache = 50767
innodb_lock_wait_timeout = 700

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

Я чувствую, что 5 - это достаточно долго для транзакции.

Вы иногда получаете это? 

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
0 голосов
/ 15 июня 2018

Предложения для вашего раздела my.cnf [mysqld]

Следующее приведение к #, чтобы отключить или УДАЛИТЬ, чтобы позволить значениям по умолчанию соответствовать вашим требованиям. Некоторые из них уже упоминались Риком Джеймсом в предыдущем комментарии.

.key_buffer.key_buffer_size.table_cache.sort_buffer_size.read_buffer_size.read_rnd_buffer_size.MyISAM_sort_buffer_size.join_buffer_size.long_query_time.innodb_lock_wait_timeout

внесите эти изменения или добавьте строки в свой my.cnf для 

query_cache_type=0  # from 1  to turn OFF QC and conserve CPU cycles
query_cache_size=0  # from 220M to conserve RAM for more useful work
query_cache_limit=0  # from 512M to conserve RAM for more useful work
thread_cache_size=100  # from 150  V8 refman suggested CAP to avoid OOM
innodb_lru_scan_depth=100  # from 1024 to minimum to conserve CPU every SECOND
innodb_flush_neighbors=0  # from 1 no need to waste CPU cycles when using SSD
innodb_io_capacity_max=10000  # from 2000 since you have SSD
innodb_io_capacity=5000  # from 200 to use more of your SSD capability

для получения дополнительной помощи, пожалуйста, проверьте мой профиль, clk Профиль сети для контактной информации.

0 голосов
/ 12 июня 2018

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

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

Если вы можете войти в MySQL из CLI и запуститьСледующая команда

SHOW PROCESSLIST;

, вы получите следующий вывод 

+———+—————–+——————-+—————–+———+——+——-+——————+———–+—————+———–+
|      Id        |   User     |             Host             |       db       | Command | Time | State | Info | Rows_sent | Rows_examined | Rows_read |
+———+—————–+——————-+—————–+———+——+——-+——————+———–+—————+———–+
| 6794372 | db_user| 111.11.0.65:21532 | db_name| Sleep          | 3800 |          | NULL |          0       |          0                   |          0             |
| 6794475 | db_user| 111.11.0.65:27488 | db_name| Sleep         | 3757 |          | NULL |          0        |          0                   |          0             |
| 6794550 | db_user| 111.11.0.65:32670 | db_name| Sleep         | 3731 |          | NULL |          0        |          0                   |          0             |
| 6794797 | db_user| 111.11.0.65:47424 | db_name | Sleep         | 3639 |          | NULL |          0       |          0                   |          0             |
| 6794909 | db_user| 111.11.0.65:56029 | db_name| Sleep         | 3591 |          | NULL |          0       |          0                   |          0              |
| 6794981 | db_user| 111.11.0.65:59201 | db_name| Sleep         | 3567 |          | NULL |          0        |          0                   |          0             |
| 6795096 | db_user| 111.11.0.65:2390 | db_name| Sleep           | 3529 |          | NULL |          0        |          0                   |          0             |
| 6795270 | db_user| 111.11.0.65:10125 | db_name | Sleep         | 3473 |          | NULL |          0       |          0                   |          0             |
| 6795402 | db_user| 111.11.0.65:18407 | db_name| Sleep         | 3424 |          | NULL |         0         |          0                   |          0             |
| 6795701 | db_user| 111.11.0.65:35679 | db_name| Sleep         | 3330 |          | NULL |          0        |          0                   |          0             |
| 6800436 | db_user| 111.11.0.65:57815 | db_name| Sleep         | 1860 |          | NULL |          0       |          0                   |          0             |
| 6806227 | db_user| 111.11.0.67:20650 | db_name| Sleep         |  188 |          | NULL |          1        |          0                   |          0             |
| 6806589 | db_user| 111.11.0.65:36618 | db_name| Query        |   0    | NULL | SHOW PROCESSLIST |       0         |       0                 |       0       |
| 6806742 | db_user| 111.11.0.75:38717 | db_name| Sleep          |   0    |          | NULL |         0         |          0                    |          0            |
| 6806744 | db_user| 111.11.0.75:38819 | db_name| Sleep         |    0    |          | NULL |          61       |          61                  |          61         |
+———+—————–+——————-+—————–+———+——+——-+——————+———–+—————+———–+
15 rows in set (0.00 sec)

В качестве примера 6794372 вы можете увидеть, что команда sleep ивремя 3800. Это предотвращает другие операции.

Эти процессы должны быть убиты 1 на 1 с помощью команды.

KILL 6794372;

Один развы разорвали все спящие соединения, все должно начать работать как обычно

...