Я запускаю Ubuntu 16.04.4 LTS на размещенном виртуальном сервере с базой данных MySQL 5.7.23 и веб-сервером Gunicorn, который предоставляет веб-приложению API. Все работает правильно, однако, когда я сталкиваюсь с большим количеством запросов API (> 200 соединений / запросов), сервер MySQL выдает мне эту ошибку:
Невозможно создать поток для обработки нового соединения (errno = 11)
Иногда после получения ошибки mysql я получаю даже эту ошибку в каждой команде командной строки, пока я не остановлю веб-сервер, который инициализировал подключения к серверу MySql:
sudo: невозможно разветвить: невозможно выделить память
После нескольких дней поиска решения в Google я изменил несколько настроек, которые, к сожалению, не помогли решить проблему. Вот моя текущая конфигурация:
/etc/mysql/mysql.conf.d/mysqld.cnf:
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
log_error = /var/log/mysql/mysql_error.log
[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_size = 16M
max_allowed_packet = 16M
thread_stack = 256K
thread_cache_size = 500
myisam-recover-options = BACKUP
max_connections = 20000
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/mysql_error.log
expire_logs_days = 10
max_binlog_size = 100M
innodb_buffer_pool_size = 2G
/etc/systemd/system/mysql.service.de/override.conf
[Service]
LimitNOFILE=1024000
LimitNPROC=1024000
/etc/security/limits.conf
mysql soft nproc 20960
mysql hard nproc 45960
mysql soft nofile 20960
mysql hard nofile 45960
/etc/security/limits.d
mysql soft nproc 20960
mysql hard nproc 45960
mysql soft nofile 20960
mysql hard nofile 45960
root soft nproc 20960
root hard nproc 45960
root soft nofile 20960
root hard nofile 45960
У меня нет физической памяти (около 12–14 ГБ свободно), и если я правильно понимаю все новые конфигурации, я больше не должен сталкиваться с максимальным ограничением потока на уровне ОС.
Вот как выглядит htop при возникновении ошибки: htop
РЕДАКТИРОВАТЬ: Пояснение к настройке: Я использую Nginx в качестве обратного прокси перед сервером приложений Gunicorn. Сервер Gunicorn работает с 8 рабочими и 2 потоками на каждого рабочего.
Приложение: Графики обслуживания на веб-странице Flask, которые показывают множество временных рядов. Каждая диаграмма загружается через внутренний асинхронный запрос «API» на том же сервере. Запросы API в основном возвращают конфигурацию диаграммы и данные таймсерий. Если у меня, например, 20 диаграмм на веб-странице. У меня есть 20 асинхронных запросов к API. Кроме того, API внутренне использует другие части API. Например. https: // xyz / getCharts / 1 -> делает один запрос к базе данных, чтобы получить информацию о том, что должно быть показано на диаграмме 1, а затем запрашивает необходимые данные временного ряда, снова вызывая API https: // xyz / getSeries / 123, который снова делает запрос к базе данных. Поэтому один запрос API может запускать несколько других запросов API и запросов к базе данных. Каждый запрос к базе данных выполняется довольно быстро из-за составного индекса и относительно небольшого количества данных на запрос.
Комментарии предполагают, что более 200 соединений / запросов - это слишком много для базы данных MySQL или установки сервера. Если это так, как я могу ограничить количество запросов на стороне клиента? Так что в основном ограничиваем запросы на уровне Nginx или Gunicorn. То, что я пробовал до сих пор в этом отношении, - это сокращение числа рабочих-убийц. Однако, когда я это делаю, я получаю такие ошибки:
OSError: [Errno 105] Нет свободного места в буфере
Что для меня вообще не имеет смысла, что я сталкиваюсь с ошибками буферного пространства, когда УМЕНЬШАЮ количество рабочих.
РЕДАКТИРОВАТЬ 2: Полный список процессов ps:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 188876 2352 ? Ss Feb19 0:01 init -z
root 2 0.0 0.0 0 0 ? S Feb19 0:00 [kthreadd/277985]
root 3 0.0 0.0 0 0 ? S Feb19 0:00 [khelper/2779850]
root 4 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 5 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 6 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 7 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 8 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 9 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 10 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 11 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 12 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 13 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 14 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 15 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 16 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 17 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 18 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 19 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 20 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 21 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 22 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 23 0.0 0.0 0 0 ? S Feb19 0:00 [rpciod/2779850/]
root 24 0.0 0.0 0 0 ? S Feb19 0:00 [nfsiod/2779850]
root 86 0.0 0.0 59788 12228 ? Ss Feb19 0:05 /lib/systemd/systemd-journald
root 109 0.0 0.0 41808 640 ? Ss Feb19 0:00 /lib/systemd/systemd-udevd
root 214 0.0 0.0 27668 444 ? Ss Feb19 0:00 /usr/sbin/cron -f
message+ 215 0.0 0.0 42832 588 ? Ss Feb19 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
syslog 226 0.0 0.0 184624 1152 ? Ssl Feb19 0:01 /usr/sbin/rsyslogd -n
root 227 0.0 0.0 28484 596 ? Ss Feb19 0:00 /lib/systemd/systemd-logind
root 338 0.0 0.0 92748 1720 ? Ss 08:47 0:00 sshd: svm [priv]
root 343 0.0 0.0 65448 1048 ? Ss Feb19 0:01 /usr/sbin/sshd -D
svm 350 0.0 0.0 92748 1576 ? S 08:47 0:00 sshd: svm@pts/3
svm 351 0.0 0.0 20080 1572 pts/3 Ss 08:47 0:00 -bash
root 352 0.0 0.0 14412 144 tty1 Ss+ Feb19 0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt220
root 353 0.0 0.0 12780 152 tty2 Ss+ Feb19 0:00 /sbin/agetty --noclear tty2 linux
root 369 0.0 0.0 126068 1428 ? Ss Feb19 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 370 0.0 0.0 127276 3968 ? S Feb19 0:19 nginx: worker process
www-data 371 0.0 0.0 127400 4208 ? S Feb19 0:32 nginx: worker process
www-data 372 0.0 0.0 126708 3460 ? S Feb19 0:18 nginx: worker process
www-data 373 0.0 0.0 127560 4308 ? S Feb19 0:14 nginx: worker process
www-data 374 0.0 0.0 127060 3712 ? S Feb19 0:18 nginx: worker process
www-data 375 0.0 0.0 127488 4240 ? S Feb19 0:19 nginx: worker process
www-data 376 0.0 0.0 127280 4164 ? S Feb19 0:20 nginx: worker process
www-data 377 0.0 0.0 127376 4132 ? S Feb19 0:26 nginx: worker process
root 412 0.0 0.0 92748 1212 ? Ss Feb19 0:00 sshd: svm [priv]
root 532 0.0 0.0 92616 1532 ? Ss 08:52 0:00 sshd: svm [priv]
svm 541 0.0 0.0 92748 1260 ? S 08:52 0:00 sshd: svm@notty
svm 542 0.0 0.0 12820 316 ? Ss 08:52 0:00 /usr/lib/openssh/sftp-server
root 564 0.0 0.0 65348 768 ? Ss Feb19 0:00 /usr/lib/postfix/sbin/master
postfix 570 0.0 0.0 67464 780 ? S Feb19 0:00 qmgr -l -t unix -u
svm 1138 0.0 0.0 44952 996 ? Ss Feb19 0:00 /lib/systemd/systemd --user
svm 1139 0.0 0.0 60768 1592 ? S Feb19 0:00 (sd-
svm 1149 0.0 0.0 92748 1424 ? S Feb19 0:05 sshd: svm@pts/0
svm 1150 0.0 0.0 20084 1404 pts/0 Ss Feb19 0:00 -bash
root 12567 0.0 0.0 92748 1340 ? Ss Feb19 0:00 sshd: svm [priv]
svm 12576 0.0 0.0 92748 1412 ? S Feb19 0:01 sshd: svm@pts/1
svm 12577 0.0 0.0 20092 888 pts/1 Ss+ Feb19 0:00 -bash
root 13508 0.0 0.0 92748 1640 ? Ss Feb19 0:00 sshd: root@pts/2
root 13510 0.0 0.0 36504 944 ? Ss Feb19 0:00 /lib/systemd/systemd --user
root 13511 0.0 0.0 212328 1632 ? S Feb19 0:00 (sd-
root 13521 0.0 0.0 19888 1204 pts/2 Ss Feb19 0:00 -bash
mysql 14816 2.2 9.9 7023536 1665064 ? Ssl 11:55 6:56 /usr/sbin/mysqld
postfix 20748 0.0 0.0 67416 2532 ? S 16:40 0:00 pickup -l -t unix -u -c
root 26860 0.0 0.0 51360 2136 pts/2 S+ 16:52 0:00 sudo nano gunicorn-error.log
root 26861 0.4 1.0 196540 177104 pts/2 S+ 16:52 0:04 nano gunicorn-error.log
svm 29711 0.1 0.1 86568 20644 pts/0 S+ 17:06 0:00 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
svm 29714 1.5 0.6 3174864 114096 pts/0 Sl+ 17:06 0:02 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
svm 29715 1.5 0.6 3175340 114368 pts/0 Sl+ 17:06 0:02 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
svm 29716 1.4 0.6 3172408 111204 pts/0 Sl+ 17:06 0:02 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
svm 29718 1.9 0.6 3248820 112212 pts/0 Sl+ 17:06 0:02 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
svm 29719 1.5 0.6 3174548 113900 pts/0 Sl+ 17:06 0:02 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
svm 29721 2.0 0.6 3176232 115440 pts/0 Sl+ 17:06 0:02 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
svm 29723 1.7 0.6 3174600 113644 pts/0 Sl+ 17:06 0:02 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
svm 29725 1.6 0.6 3172224 111324 pts/0 Sl+ 17:06 0:02 /home/svm/Intranet/venv/bin/python3 /home/svm/Intranet/venv/bin/gunicorn intranet:app --bind 127.0.0.1:50
root 30271 0.0 0.0 65448 3224 ? Ss 17:08 0:00 sshd: [accepted]
root 30272 0.0 0.0 65448 3444 ? Ss 17:08 0:00 sshd: [accepted]
sshd 30273 0.0 0.0 65448 1324 ? S 17:08 0:00 sshd: [net]
svm 30274 0.0 0.0 36024 1660 pts/3 R+ 17:08 0:00 ps aux
Я пытался создать пространство подкачки. Однако с моим хостером VPS у меня нет разрешения на его создание.
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) 1030918
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1030918
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
df -h:
Filesystem Size Used Avail Use% Mounted on
/dev/ploop43863p1 788G 17G 740G 3% /
devtmpfs 8,0G 0 8,0G 0% /dev
tmpfs 8,0G 0 8,0G 0% /dev/shm
tmpfs 8,0G 25M 8,0G 1% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 8,0G 0 8,0G 0% /sys/fs/cgroup
none 8,0G 0 8,0G 0% /run/shm
tmpfs 1,7G 0 1,7G 0% /run/user/1001
tmpfs 1,7G 0 1,7G 0% /run/user/0
РЕДАКТИРОВАТЬ: Решение проблемы MySQL: Думаю, я нашел причину ошибок MySQL. Приложение python использовало метод create_engine из sqlalchemy для каждого нового запроса к базе данных, вместо того, чтобы повторно использовать движок и просто открывать новое соединение. Однако пока это узкое место устранено, ошибка Gunicorn: OSError: [Errno 105] No buffer space available происходит сейчас гораздо чаще, потому что приложение больше не сталкивается с ошибками MySQL.
РЕДАКТИРОВАТЬ: Показать глобальные переменные: https://pastebin.com/LGsBQgR0
Показать глобальный статус: https://pastebin.com/Q0pGJpwn
MysqlTuner: https://pastebin.com/U1nBVPTT
iostat во время запросов: https://pastebin.com/yQkAib91
max_connections = 20000
слишком высока. 200 более реалистично. Если вы пытаетесь установить соединение 20K открыто в то же время в вашей системе есть архитектурные проблемы.
Запросы API должен приходят и уходят за миллисекунды, тем самым не накапливая 20K живых соединений.
Если ваш клиент (Apache, Tomcat, что угодно) разрешает запускать 20K потоков, тогда который это проблема.
Анализ СТАТУСА / ПЕРЕМЕННЫХ
Наблюдения:
Более важные вопросы:
Множество SHOW команды - Что происходит?
Во многих запросах используются внутренние временные таблицы или выполняется полное сканирование таблиц. Нижняя long_query_time и включите замедление, чтобы увидеть, что наихудшее.
Детали и другие наблюдения:
( innodb_buffer_pool_size / _ram ) = 2048M / 16384M = 12.5% -% ОЗУ, используемого для InnoDB buffer_pool
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (16M / 0.20 + 2048M / 0.70) / 16384M = 18.3% - Большая часть доступной оперативной памяти должна быть доступна для кеширования. - http://mysql.rjweb.org/doc.php/memory
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 67,332 / 131056 = 51.4% - Часть buffer_pool в настоящее время не используется - innodb_buffer_pool_size больше, чем необходимо?
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 18,529 / 60 * 256M / 122842112 = 674 - Минуты между ротациями журнала InnoDB. Начиная с 5.6.8, это можно изменять динамически; не забудьте также изменить my.cnf. - (Рекомендация 60 минут между ротациями несколько произвольна.) Отрегулируйте innodb_log_file_size. (Нельзя изменить в AWS.)
( innodb_flush_method ) = innodb_flush_method = - Как InnoDB должен запрашивать у ОС запись блоков. Предложите O_DIRECT или O_ALL_DIRECT (Percona), чтобы избежать двойной буферизации. (По крайней мере, для Unix.) См. Предостережение по поводу O_ALL_DIRECT у chrischandler.
( Com_rollback ) = 65,020 / 18529 = 3.5 /sec - ОТКАТЫ в InnoDB. - Чрезмерная частота откатов может указывать на неэффективную логику приложения.
( Handler_rollback ) = 35,725 / 18529 = 1.9 /sec - Почему так много откатов?
( Innodb_rows_deleted / Innodb_rows_inserted ) = 250,597 / 306605 = 0.817 - Churn - «Не ставьте это в очередь, просто сделайте это». (Если MySQL используется как очередь.)
( innodb_flush_neighbors ) = 1 - Небольшая оптимизация при записи блоков на диск. - Используйте 0 для SSD-накопителей; 1 для HDD.
( innodb_io_capacity ) = 200 - Число операций ввода-вывода на диске в секунду. 100 для медленных дисков; 200 для прядильных приводов; 1000-2000 для SSD; умножить на коэффициент RAID.
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF - Регистрировать ли все взаимоблокировки. - Если вас беспокоят тупиковые ситуации, включите это. Внимание: если у вас много тупиковых ситуаций, это может привести к большой записи на диск.
( (Com_show_create_table + Com_show_fields) / Questions ) = (1 + 19522) / 140291 = 13.9% - Непослушный фреймворк - потратить много усилий на переоткрытие схемы. - Пожаловаться стороннему поставщику.
( local_infile ) = local_infile = ON - local_infile = ON - потенциальная проблема безопасности
( (Queries-Questions)/Queries ) = (24488180-140291)/24488180 = 99.4% - Доля запросов, находящихся внутри сохраненных подпрограмм. - (Неплохо, если высокое; но это влияет на обоснованность некоторых других выводов.)
( Created_tmp_disk_tables ) = 19,628 / 18529 = 1.1 /sec - Частота создания диск "временные" таблицы как часть сложных SELECT - увеличьте tmp_table_size и max_heap_table_size. Проверьте правила для временных таблиц, когда MEMORY используется вместо MyISAM. Возможно, незначительные изменения схемы или запроса помогут избежать MyISAM. С большей вероятностью помогут лучшие индексы и переформулировка запросов.
( Created_tmp_disk_tables / Questions ) = 19,628 / 140291 = 14.0% - Процент запросов, которым потребовалась таблица tmp на диске. - Лучшие индексы / без капель / т. Д.
( Created_tmp_disk_tables / Created_tmp_tables ) = 19,628 / 22476 = 87.3% - Процент временных таблиц, разлитых на диск - Возможно увеличение tmp_table_size и max_heap_table_size; улучшить показатели; избегать капель и т. д.
( Com_rollback / Com_commit ) = 65,020 / 765 = 8499.3% - Откат: коэффициент фиксации - Откат дорогостоящий; изменить логику приложения
( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (669 + 24 + 164 + 1) / 765 = 1.12 - Количество запросов на фиксацию (при условии, что все InnoDB) - Низкое: может помочь сгруппировать запросы в транзакции; Высокий: длинные транзакции напрягают разные вещи.
( Select_scan ) = 25,262 / 18529 = 1.4 /sec - полное сканирование таблиц - добавление индексов / оптимизация запросов (если они не являются крошечными таблицами)
( Select_scan / Com_select ) = 25,262 / 38182 = 66.2% -% выборок, выполняющих полное сканирование таблицы. (Может быть обманут сохраненными подпрограммами.) - Добавить индексы / оптимизировать запросы
( innodb_autoinc_lock_mode ) = 1 - Galera: желания 2 - 2 = "чередующиеся"; 1 = "последовательный" типичен; 0 = «традиционный».
( slow_query_log ) = slow_query_log = OFF - Следует ли регистрировать медленные запросы. (5.1.12)
( long_query_time ) = 10 - Отсечка (секунды) для определения «медленного» запроса. - Предложить 2
( Aborted_clients / Connections ) = 1,010 / 1457 = 69.3% - Потоки сбиты из-за тайм-аута - Увеличить wait_timeout; будь вежливым, используй отключение
( thread_cache_size ) = 500 - Сколько дополнительных процессов нужно поддерживать (не имеет значения при использовании пула потоков) (автоматически настраивается с версии 5.6.8; на основе max_connections)
( thread_cache_size / max_connections ) = 500 / 500 = 100.0%
( thread_cache_size / Max_used_connections ) = 500 / 136 = 367.6% - Нет никакого преимущества в том, что размер кэша потоков превышает ваше вероятное количество подключений. Недостатком является потеря места.
Аномально большой:
Com_kill = 0.39 /HR
Com_show_charsets = 0.39 /HR
Com_show_fields = 1.1 /sec
Com_show_slave_hosts = 0.39 /HR
Com_show_storage_engines = 0.78 /HR
Com_show_warnings = 38 /HR
Handler_read_next / Handler_read_key = 5,206
Innodb_dblwr_pages_written / Innodb_dblwr_writes = 62.7
Performance_schema_file_instances_lost = 1
gtid_executed_compression_period = 0.054 /sec
wait_timeout = 1.0e+6
Аномальные строки:
ft_boolean_syntax = + -><()~*:&
innodb_fast_shutdown = 1
optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
session_track_system_variables = time_zone, autocommit, character_set_client, character_set_results, character_set_connection
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN
Скорость в секунду = RPS - предложения для вашего раздела my.cnf [mysqld]
read_rnd_buffer_size=256K # from 1M to reduce handler_read_rnd_next RPS of 4,950
innodb_io_capacity=1500 # from 200 to enable higher IOPS
tmp_table_size=64M # from 32M for additional capacity
max_heap_table_size=64M # from 32M to reduce created_tmp_disk_tables
innodb_lru_scan_depth=100 # from 1024 to reduce CPU cycles used every SECOND
Нам нужно обсудить причины более 65000 событий com_rollback, содержимое журнала ошибок и многое другое.