MySQLエラー：多くのGunicorn APIリクエストによってトリガーされた新しい接続（errno = 11）を処理するスレッドを作成できません
MySQL DB5.7.23とGunicornWebサーバーを備えたホスト型仮想サーバーでUbuntu16.04.4 LTSを実行しています。これは、WebアプリケーションにAPIを提供しています。すべてが正常に実行されていますが、多くのAPIリクエスト（> 200の接続/リクエスト）が発生すると、MySQLサーバーから次のエラーが発生します。
新しい接続を処理するスレッドを作成できません（errno = 11）
時々、mysqlエラーが発生した後、MySqlサーバーへの接続を初期化したWebサーバーを停止するまで、各コマンドラインコマンドでこのエラーが発生することがあります。
須藤：フォークできません：メモリを割り当てることができません
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
私は物理メモリ（約12GB〜14GBの空き容量）が不足していません。すべての新しい構成を正しく理解していれば、OSレベルで最大スレッド制限に達することはもうありません。
エラーが発生したときのhtopの外観は次のとおりです。 htop
編集：セットアップの説明：Gunicornアプリケーションサーバーの前でリバースプロキシとしてNginxを使用しています。 Gunicornサーバーは、8つのワーカーとワーカーごとに2つのスレッドで実行されています。
アプリケーション：Flask Webページのサーバーチャート。多くの時系列が表示されます。各チャートは、内部非同期を介してロードされます。同じサーバーでの「API」リクエスト。APIリクエストは基本的にチャート構成と時系列データを返します。たとえばウェブページに20のチャートがある場合、APIへの非同期リクエストは20あります。さらに、APIは内部で他の部分も使用しています。 APIの例： https：// xyz/getCharts/1 -> 1つのデータベースクエリを実行して、グラフ1に表示する内容に関する情報を取得し、もう一度呼び出すことで必要な時系列データを要求します。 API https：// xyz/getSeries/12 、これもデータベースクエリを作成します。したがって、1つのAPIリクエストで他のサーバーAPIリクエストやデータベースリクエストをトリガーできます。各データベースクエリ自体は非常に高速です。複合インデックスとクエリごとの比較的少量のデータ。
コメントは、200を超える接続/要求がMySQLデータベースまたはサーバーセットアップには多すぎることを示唆しています。この場合、クライアント側でリクエストの数を制限するにはどうすればよいですか？したがって、基本的にNginxまたはGunicornレベルで要件を制限します。この点で私がこれまでに試したことは、gunicornの労働者の数を減らすことです。ただし、これを実行すると、次のようなgunicornエラーが発生します。
OSError：[Errno105]使用可能なバッファスペースがありません
ワーカーの数を減らしているときにバッファスペースエラーが発生することは、私にはまったく意味がありません。
編集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アプリケーションは、エンジンを再利用して新しい接続を開くのではなく、すべての新しいデータベースリクエストに対してsqlalchemyのメソッド "create_engine"を使用しました。ただし、このボトルネックは解決されていますが、Gunicornエラー： OSError: [Errno 105] No buffer space availableは、アプリケーションでMySQLエラーが発生しなくなったため、より頻繁に発生しています。
編集：グローバル変数を表示： https://Pastebin.com/LGsBQgR
グローバルステータスを表示： https://Pastebin.com/Q0pGJpwn
MysqlTuner： https://Pastebin.com/U1nBVPTT
リクエスト中のiostat： https://Pastebin.com/yQkAib91
max_connections = 20000
高すぎます。 200の方が現実的です。 20K接続を同時に行おうとしている場合open、システムにアーキテクチャ上の問題があります。
APIリクエストshouldミリ秒単位で出入りするため、20Kのライブ接続が蓄積されません。
クライアント（Apache、Tomcatなど）が20Kスレッドの実行を許可している場合、thatが問題になります。
ステータス/変数の分析
観察：
- バージョン：5.7.23-0ubuntu0.16.04.1
- 16GBのRAM
- 稼働時間= 05：08：49;一部のGLOBALSTATUS値は、まだ意味がない場合があります。
- Windowsで実行していません。
- 64ビットバージョンを実行しています
- 完全に（またはほとんど）InnoDBを実行しているようです。
より重要な問題：
たくさんのSHOWコマンド-何が起こっているのですか？
多くのクエリは、内部一時テーブルを使用するか、全表スキャンを実行します。下long_query_timeそしてslowlogをオンにして、最悪の事態を確認します。
詳細およびその他の所見：
( innodb_buffer_pool_size / _ram ) = 2048M / 16384M = 12.5%-％of RAM InnoDBbuffer_poolに使用
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (16M / 0.20 + 2048M / 0.70) / 16384M = 18.3%-利用可能なRAMのほとんどは、キャッシュに利用できるようにする必要があります。 - 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がOSにブロックの書き込みを要求する方法。二重バッファリングを回避するために、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-チャーン-「キューに入れないでください。ただやってください。」 （MySQLがキューとして使用されている場合。）
( innodb_flush_neighbors ) = 1-ブロックをディスクに書き込むときのマイナーな最適化。 --SSDドライブには0を使用します。 HDDの場合は1。
( innodb_io_capacity ) = 200-ディスク上で可能な1秒あたりのI/Oops。低速ドライブの場合は100。ドライブの回転には200。 SSDの場合は1000〜2000。 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の一部としてdisk "temp"テーブルを作成する頻度--tmp_table_sizeとmax_heap_table_sizeを増やします。 MyISAMの代わりにMEMORYを使用する場合の一時テーブルのルールを確認してください。おそらく、スキーマやクエリを少し変更するだけで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-ガレラ：欲望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
1秒あたりのレート= 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
65,000以上のcom_rollbackイベントの原因、エラーログの内容などについて話し合う必要があります。