MySQLチューナーが返す：MySQLの最大メモリ使用量が危険なほど高い
誰かが私のMSQL構成を最適化するのを手伝ってくれる？.
Ubuntu 18.4でZabbixとGrafanaを実行しています。 MySQL Tunerは、メモリ使用量が危険なほど高いことを示していますが、freeコマンドを使用すると、十分なメモリがあることを示しています。
Mysqltunerの完全な関係は次のとおりです。 MySQLTuner
以下に出力を示します。 SHOW GLOBAL VARIABLES および SHOW GLOBAL STATUS および SHOW FULL PROCESSLIST
そして、次の出力： SHOW ENGINE INNODB STATUS Zabbixはinnodbテーブルを過度に使用するため。
Topコマンドの出力とhtopコマンドの出力には、innotopの出力もあります。 Google Drive
そして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) 31652
max locked memory (kbytes, -l) 16384
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) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31652
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
そして無料-h
total used free shared buff/cache available
Mem: 7,8G 7,0G 146M 37M 689M 554M
Swap: 2,0G 417M 1,6G
MySQLのメモリ使用量を増やすにはどうすればよいですか？ MySQL構成を最適化して、CPUとメモリの使用量を最大化するにはどうすればよいですか？
助けてくれてありがとう！
1秒あたりのレート= RPS
My.cnf [mysqld]セクションで検討すべき提案
read_rnd_buffer_size=128K # from 256K to reduce handler_read_rnd_next RPS of 917
innodb_change_buffer_max_size=15 # from 25 (percent) set aside for maintenance
innodb_flush_neighbors=2 # from 1 to clear in current extent to reduce innodb_buffer_pool_pages_dirty count faster
innodb_flushing_avg_loops=5 # from 30 to reduce flushing delay
innodb_lru_scan_depth=100 # from 1024 to reduce 90% of CPU cycles used for function every second
innodb_thread_concurrency=6 # from 10 to expedite query completion by your 4 cores
これらの変更により、RAMが必要になり、応答時間が短縮されます。追加の提案および無料でダウンロードできるユーティリティスクリプトについては、プロファイル、連絡先情報のネットワークプロファイルを参照してください。
観察：8 GBサーバーは、26 GBのinnodbデータをサポートするために引き続き苦労します。 48GBは、ワークロードにとって妥当なステップアップです。 com_beginは、com_commitアクティビティよりも34多いカウントでした。完了時に誰かがCOMMITを忘れましたか？ちなみに、88,665秒（1日強）の間に34回のロールバックがあったようです。
mysql/mariadb（およびおそらく他のエンジン）のRAM消費量は、次のように表すことができます。
_+----+----------------+-------------------+-----------------------------+
| OS | Other services | DB common caching | DB clients buffers |
| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | |
+----+----------------+-------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_一般的なDBキャッシングは、_key_buffer_と_InnoDB_buffer_pool_の値の合計です。
各クライアントのバッファサイズは、_read_buffer_、_read_rnd_buffer_、_join_buffer_および_sort_buffer_の合計です。この金額に_max_connections_値を掛けます。両方の値を合わせて、RAM全体の妥当な部分より大きくすることはできません。一部のRAMはホストのOS自体で必要であり、一部のRAMはホスト上のサードパーティサービスのために残しておく必要があります。
Maximum possible memory usage: 9.0G (116.34% of installed RAM)は、mysqlサービスに専念していることを意味しますRAMホストが物理的にインストールしたものよりも多くなります。これは、 DBへの同時接続が多すぎて、スワッピングのために最初にスローダウンが発生します。
Mysqlを完全に調整する場合は、同時に確立できる接続の数を知っておく必要があります。この値は次のとおりです。
_Highest usage of available connections: 40% (61/151)
_次に、RAM各クライアントに必要な量を決定する必要があります。この値は、DBデータとクエリに依存します。DBがそれほど重要でない場合は、適切な値から始めて、それらを減らすことができます全体的なパフォーマンスが大幅に低下するまで2倍にしますが、一般的には、各クライアントのバッファーに1〜2 MB、合計4〜8 MBで十分です。
次に、クライアントのバッファの合計に_max_connections_値を掛けます。デフォルトでは151ですが、実際の接続のピーク数の1.2〜1.5倍に変更できます。
たとえば、最大61の実際の接続について、接続ごとに8MBのバッファで_max_connections = 80_を予約します。つまり、80x8 = 640MBのRAMを予約しました。
これで、OS自体に1 GB、その他のサービスに512 MBを残しています。残りは次のとおりです。
_8GB - 1GB - 512MB - 640MB = 6016MB
_6GBに丸めましょう。これはRAM MyISAM _key_buffer_と_innodb_buffer_pool_の間で分割できます。DBにMyISAMテーブルがない場合は_key_buffer_size = 256k_を設定できます_mariadb 10.1.x_は引き続き内部でMyISAM/ARIAを使用し、残りはすべてinnodbキャッシング専用にすることができます：_innodb_buffer_pool_size = 6G_
今、あなたはそのようなものを得るでしょう：
_Total buffers: 6.G global + 8M per thread (80 max threads)
Maximum possible memory usage: 6.7G (84% of installed RAM)
_