Приветствую коллеги. Проблема обозначилась в окончательном виде.

В http://www.sql.ru/forum/1267380/mariadb-galera-cluster-zavisaut-zaprosy я писал, о том, что зависают отдельные запросы, но это "цветочки" по сравнению с тем, что происходит дальше. Через некоторое время с момента запуска (от 15 минут до нескольких дней) кластер становится колом - не принимает и не обрабатывает запросы приложений.

В PROCESSLIST при этом висит некоторое количество запросов в статусе Query End, при попытке их "убить" статус меняется на Killed - и всё.

В syslog\mysql-error.log может не быть ошибок совсем, а может быть что-то вроде

Aug 3 10:43:32 ru-tul-dc01-db-galera-node1 mysqld[1122]: 2017-08-03 10:43:32 139707425306368 [Warning] Aborted connection 2905 to db: 'basename' user: 'username' host: 'ip' (Got an error reading communication packets)
Aug 3 10:43:32 ru-tul-dc01-db-galera-node1 mysqld[1122]: 2017-08-03 10:43:32 139707424700160 [Warning] Aborted connection 2919 to db: 'basename' user: 'username' host' host: 'ip' (Got an error reading communication packets)

и\или множество

Aug 3 14:35:08 ru-tul-dc01-db-galera-node1 mysqld[1115]: 2017-08-03 14:35:08 140310822119168 [Warning] WSREP: certification interval for trx source: dcdccd42-7837-17837-11e7-a045-2a82ddbaac7a version: 3 local: 1 state: CERTIFYING flags: 1 conn_id: 1010 trx_id: 10244940 seqnos (l: 152638, g: 5113465, s: 5088151, d: -1, ts: 3445: 3445393337346) exceeds the limit of 16384)


Единственный способ вернуть кластер к жизни (на время) - перезапустить ноду на которую ведется запись. Переносить mysqld в одну NUMA ноду пробовал - проблема остается. Помогите пожалуйста понять где грабли, уже голову сломал. Конфиг прилагаю.

ScareCrow, похоже, что она выключена. Или я не то\ не там смотрю?

MariaDB [(none)]> SHOW VARIABLES LIKE 'performance_schema';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| performance_schema | OFF |
+--------------------+-------+
1 row in set (0.00 sec)

ScareCrow,

включил.

MariaDB [(none)]> show variables like 'performance%';
+--------------------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------------------+-------+
| performance_schema | ON |
| performance_schema_accounts_size | 100 |
| performance_schema_digests_size | 10000 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_stages_history_size | 10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size | 10 |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_hosts_size | 100 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | 3300 |
| performance_schema_max_digest_length | 1024 |
| performance_schema_max_file_classes | 50 |
| performance_schema_max_file_handles | 32768 |
| performance_schema_max_file_instances | 3077 |
| performance_schema_max_mutex_classes | 200 |
| performance_schema_max_mutex_instances | 10000 |
| performance_schema_max_rwlock_classes | 40 |
| performance_schema_max_rwlock_instances | 5000 |
| performance_schema_max_socket_classes | 10 |
| performance_schema_max_socket_instances | 1020 |
| performance_schema_max_stage_classes | 150 |
| performance_schema_max_statement_classes | 188 |
| performance_schema_max_table_handles | 4000 |
| performance_schema_max_table_instances | 12500 |
| performance_schema_max_thread_classes | 50 |
| performance_schema_max_thread_instances | 1100 |
| performance_schema_session_connect_attrs_size | 512 |
| performance_schema_setup_actors_size | 100 |
| performance_schema_setup_objects_size | 100 |
| performance_schema_users_size | 100 |
+--------------------------------------------------------+-------+
32 rows in set (0.00 sec)


На что стоит обратить внимание? К сожалению, доселе не работал с perfomance schema, потому прошу прощения за глупые вопросы.

netwind,

через час-несколько часов ломается, без корреляции с NUMA. Вот вывод команды в состоянии "кластер стоит колом".

numastat -pm| grep mysqld
5879 (mysqld) 52241.51 2614.92 54856.43

Прилагаю вывод SHOW PROCESSLIST, где видны зависшие запросы (айпи я "замазал")

netwind,

Не исключено... Но к разгадке "что же делать" это не ведет. Буду думать дальше.

netwind,

cat /sys/kernel/mm/ksm/merge_across_nodes
1

И вот сейчас у меня есть один единственный зависший запрос типа

| 2641 | юзер | ip:49454 | база| Execute | 7571 | NULL | SELECT * FROM `таблица` WHERE useralias = '74224752' | 0.000 |

Как бы извлечь максимум информации о том, что происходит с этим запросом?

Если я просто вбиваю его в командную строку, он выполняется мгновенно.

netwind,

с другой стороны cat /sys/kernel/mm/ksm/run
0


Т.е. ksm получается не запущен.

netwind,

так это же SELECT - он не вызывает изменений в базе и потому не реплицируется никуда.

netwind,

не могу понять как ее лучше исправить. Выключить в опциях ядра? Выключить в опциях mysqld? Урезать innodb_buffer_pool_size до половины RAM?

netwind,

Не вполне очевидно что делать - man короткий и малопонятный (лично мне) . Вот какая картина сейчас:
numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 96849 MB
node 0 free: 60960 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 96957 MB
node 1 free: 90813 MB
node distances:
node 0 1
0: 10 21
1: 21 10

numactl --show mysqld
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
cpubind: 0 1
nodebind: 0 1
membind: 0 1


Мне, получается, нужно сделать так, чтобы mysqld работал в рамках только одной ноды (например, 1).

Мне нужно установить это командой вроде numactl -cpunodebind=1 --membind=1 mysqld ?

ScareCrow,

Может быть, порекомендуете как с помощью Perfomance Schema посмотреть что происходит с зависшими запросами? К сожалению, не получается найти информацию самостоятельно, вероятно я не то и не там ищу.

ScareCrow,

Спасибо! При очередном зависании соберу данные.