Увеличение количества подключений, которые MySQL 8 может обрабатывать (сервер Debian 9) и планировщик событий автоматического перезапуска

У меня есть сервер Debian 9 (12 процессоров, 80 ГБ ОЗУ), на котором запущен сервер Percona для MySQL 8.0, около 1100 клиентов в секунду, нагрузка не очень высока, от 0,3 до 2,30

Запоздалые числа из состояния innodb show engine: 183,82 вставок / с, 169,69 обновлений / с, 5,79 удалений / с, 2179444,29 чтения / с

Большую часть времени он работает очень хорошо, но в последнее время он внезапно отказывается от новых подключений (когда очень загруженная таблица блокируется на долгое время или какой-то запрос занимает слишком много времени).

Журналы показывают:

[ОШИБКА] [MY-000000] [connection_h] Дроссельная заслонка журнала ошибок: 1912 «Невозможно создать поток для обработки нового соединения», ошибка (я) подавлена ​​

[ОШИБКА] [MY-010249] [Сервер] Невозможно создать поток для обработки нового соединения (errno = 11)

[ОШИБКА] [MY-010053] [Сервер] Event_scheduler :: execute_top: не удается создать рабочий поток событий (errno = 11). Остановка планировщика событий


Итак, в основном у меня есть два вопроса:

1. Как настроить сервер, чтобы он принимал больше подключений (я пробовал много вещей, которые перечислю ниже), он не может обрабатывать более 4821 а точнее

2. Всякий раз, когда это происходит, планировщик событий останавливается, и мне приходится вручную включать его снова, это действительно плохо, потому что у меня есть ПАМЯТЬ таблицы, которые заполняются, они справляются с интенсивным трафиком и сбрасывают другие таблицы каждые 5 секунд


. До сих пор я пытался установить мягкие и жесткие ограничения в /etc/security/limits.conf для *, mysql и пользователей root:

*         hard    nofile      400000
*         soft    nofile      400000
*         hard    nproc       400000
*         soft    nproc       400000
mysql     hard    nofile      400000
mysql     soft    nofile      400000
root      hard    nofile      400000
root      soft    nofile      400000

Я также сделал многие изменения в /etc/sysctl.conf перечисляют некоторые ниже:

kernel.pid_max = 262144
vm.max_map_count = 262144
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.ip_local_port_range = 2000 65500
net.ipv4.tcp_max_syn_backlog = 32768
fs.file-max = 450000
net.core.netdev_max_backlog = 450000
net.core.somaxconn = 32768

Я также внес изменения в файлы конфигурации systemd: /lib/systemd/system/mysql.service - настройка:

LimitNOFILE=220000
TasksMax=32768

mysqld.conf

bind-address                    = 0.0.0.0

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

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

wait-timeout                   = 600

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

# BINARY LOGGING #
sync-binlog                    = 0

# CACHES AND LIMITS #
tmp-table-size                 = 32M
max-heap-table-size            = 32M
max-connections                = 20000
thread-cache-size              = 300
open-files-limit               = 65535
table-definition-cache         = 4096
table-open-cache               = 4096

# INNODB #
innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-log-file-size           = 512M
innodb-flush-log-at-trx-commit = 0
innodb-file-per-table          = 1
innodb-buffer-pool-size        = 64G
innodb-fast-shutdown           = 0
innodb-buffer-pool-dump-pct    = 75
innodb-buffer-pool-dump-at-shutdown = 1
innodb-buffer-pool-load-at-startup  = 1
innodb-io-capacity             = 400
innodb-io-capacity-max         = 2000

# LOGGING #
log-error                      = /var/log/mysql/mysql-error.log
log-queries-not-using-indexes  = 0
slow-query-log                 = 1
slow-query-log-file            = /var/log/mysql/mysql-slow.log
long-query-time                = 5

event_scheduler = 1
general_log_file               = /var/log/mysql/general.log
general_log                    = 0
local-infile                   = 1

Я не знаю, что еще я могу сделать или где еще я могу посмотреть, попытался найти проблемы и не смог найти ничего, что работает, для планировщика событий еще хуже, там почти ничего не найдено об этом (попробуйте поискать в Google MY-010053 или Невозможно создать рабочий поток событий почти нет результатов)

Сервер не перестает отвечать на запросы или работает медленно , если я специально заблокирую таблицы,Я получаю сообщение об ошибке примерно через 10 секунд, и когда я разблокирую его, сразу же восстанавливается

Как просил Уилсон Хаук:

ulimit -a

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 326193
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 400000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 326193
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

iostat -xm 5 3

Linux 4.9.0-8-amd64 (zelda)     03/07/2019      _x86_64_        (12 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11.24    0.00    1.56    0.76    0.00   86.44

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.41    44.17    2.41   67.61     0.05     1.61    48.55     0.37    5.23    4.74    5.25   1.37   9.59

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.77    0.00    1.91    0.82    0.00   87.51

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00    52.20    0.00   81.60     0.00     1.85    46.51     0.45    5.51    0.00    5.51   1.14   9.28

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.83    0.00    1.41    0.77    0.00   91.99

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00   132.00    0.00  161.40     0.00     8.12   103.00     0.88    5.47    0.00    5.47   0.66  10.72

показать полный список процессов там ничего нет special:

4087783 event_scheduler localhost       Daemon  1   Waiting for next activation     0   0
275050068   xgh 179.191.66.174:51143    xgh Sleep   3           0   0
275050130   xgh 179.191.66.174:51144    xgh Query   0   starting    show full processlist   0   0
300324788   xgh 179.191.66.174:40708    xgh Sleep   12595           5   61
304505269   xgh 179.191.66.174:51680    xgh Sleep   72          0   0
304505986   xgh 179.191.66.174:51706    xgh Sleep   72          0   0
305818676   xgh 172.30.5.2:57288    xgh Query   0   Sending data    SELECT *
 FROM (`noticias`.`noticia`)
 WHERE `texto` =  'Carlos Ghosn deixa prisão após mais de 100 dias detido em Tóquio'    0   0
305818680   xgh 172.30.5.2:57296    xgh Sleep   57          0   0
305818682   xgh 172.30.5.2:57302    xgh Sleep   57          0   0
305818689   xgh 172.30.5.2:57316    xgh Sleep   57          0   0
305818692   xgh 172.30.5.2:57324    xgh Sleep   57          0   0
305842475   xgh 172.30.5.2:49326    xgh Sleep   1           94  550698
305842479   xgh 172.30.5.2:49334    xgh Sleep   1           0   0
305842481   xgh 172.30.5.2:49340    xgh Sleep   1           0   0
305842486   xgh 172.30.5.2:49350    xgh Sleep   1           0   0
305842489   xgh 172.30.5.2:49358    xgh Sleep   1           0   0
305842492   xgh 172.30.5.2:49364    xgh Sleep   1           0   0
305842496   xgh 172.30.5.2:49372    xgh Sleep   1           0   0
305842498   xgh 172.30.5.2:49376    xgh Sleep   1           0   0
305842501   xgh 172.30.5.2:49382    xgh Sleep   1           0   0
305842505   xgh 172.30.5.2:49392    xgh Sleep   1           0   0
305842508   xgh 172.30.5.2:49398    xgh Sleep   1           0   0

ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС: https://pastebin.com/cg1v5bHD

ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ: https://pastebin.com/8mkTzpr0

-1
задан 12 March 2019 в 19:53
2 ответа

Предоставьте уведомление SHOW CREATE TABLE . Если texto относится к типу TEXT , то один из выполняемых запросов в PROCESSLIST требует просмотра таблицы. Если это VARCHAR , то, вероятно, поможет индекс.

Вы утверждаете, что существует много соединений, но я вижу, что только одно что-то делает. Итак, снова ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ , надеясь получить несколько запросов.

1
ответ дан 5 December 2019 в 19:39

Скорость в секунду = RPS - Предложения, которые следует учитывать для вашего раздела my.cnf [mysqld]

innodb_lru_scan_depth=100  # from 1024 to conserve 90% of CPU cycles used for function
innodb_flushing_avg_loops=5  # from 30 to reduce delay and reduce innodb_buffer_pool_pages_dirty of 90,000 +
innodb_io_capacity=1900  # from 400 to allow higher IOPS to data devices
read_rnd_buffer_size=128K  # from 256K to reduce handler_read_rnd_next RPS of ~ 600,000 RPS

Монитор innodb_buffer_pool_pages_dirty с помощью SHOW ГЛОБАЛЬНЫЙ СТАТУС, КАК "% dirty%";

Потребители времени, требующие проверки, A)com_rollback_to_savepoint AVG 1 каждые 62 секунды, B) handler_rollback AVG 1 каждые 52 секунды, C) handler_savepoint_rollback AVG 1 каждые 31 секунду.

Отказ от ответственности: я являюсь автором mysqlservertuning.com, как указано в моем профиле Network profile. Удачи вашему экземпляру со средней скоростью 367 подключений в секунду.

0
ответ дан 5 December 2019 в 19:39

Теги

Похожие вопросы