web-dev-qa-db-ja.com

AWS RDS接続が急上昇する原因は何ですか

AWSでRDSを使用するのは初めてですが、MySQL Auroraをデフォルトの構成で実行するt2.mediumインスタンスを使用します。 CPU使用率とDB接続は、「何か」が発生するまで非常に正常です。これにより、DB接続が最大に達します（t2.mediumでは80接続です）。

enter image description here

EC2インスタンスで実行しているWebアプリは1つだけです。 DB接続が最大に達すると、EC2インスタンスのCPU使用率は完全に正常（25〜30％）ですが、DBインスタンスに接続しようとすると、すべて「接続が多すぎます」という結果になります。

enter image description here

また、そのときにDBインスタンスのCPU使用率も確認しました。高負荷の信号は表示されていませんでした。ストライキ時間中、CPU使用率は20％に低下し、その比率を一貫して維持しました。

enter image description here

わからないこと：DB接続が最大になっていますが、なぜDB CPU使用率が低下するのですか？それらの接続でのクエリの計算のために、それも最大にすべきではありませんか？

何卒よろしくお願いいたします。

（2回目の違反が発生した場合、RDSインスタンスのサイズをr4.largeに変更する必要がありました。問題が見つかるまで、今でも実行しています...）

mysqlhigh-availabilityconnectionsmax-connections
7
TrungDQ

show processlist;を実行すると、DBに対して実行されているすべての接続が表示されます。 show status like 'Conn%'を実行すると、アクティブな接続の数を示すことができます

接続の数が多いとCPUが増えると思うかもしれませんが、最終的には、それらの接続が何を実行しようとしているかに依存します。接続があまり機能していないが、メインアプリケーションが接続を実行できない場合は、通常の処理レベルになります。通常のプロセスを実行していないときにダウンします

面倒なことは、実際にはDBに接続する必要があるshow processlistコマンドを実行できることです。これは、最大接続数では実行できないためです。

わずかな回避策は、最大接続数を増やし（可能な場合）、どこかで頻繁に実行される監視を設定し（5分ごとにそれをキャッチします）、接続数が50を超えると、コマンドを実行することです後で確認できるように、アクティブな接続をどこかにダンプします。

4
Ste Bov

RDSで、最初にすべてのIOPSメトリックを確認します。

RDSは特定の量のIOPSを提供します。RDSインスタンスに10 GB SSDがある場合、おそらくIOPS量は100 IOPS（デフォルト）であり、この値はインスタンスのSSDサイズによって異なります。

十分なIOPSがない場合、RDSはIOオペレーションに対してブロックされ、MySQLで「データの送信」と高いタイムアウトを引き起こしますが、これはディスクの問題であるため、CPU使用率またはメモリの変更はありません。 。

修正するには、MySQLの設定を変更し、ダッシュボードで変更します。

MySQLをEC2インスタンスで使用しています。低コストです。

My.cnfを参照してください

[mysqld]


port                           = 3306
user                           = mysql
default-storage-engine         = InnoDB
socket                         = /var/lib/mysql/mysql.sock
pid-file                       = /var/lib/mysql/mysql.pid


log-error                      = /var/lib/mysql/mysql-error.log
log-queries-not-using-indexes  = 1
slow-query-log                 = 0
slow-query-log-file            = /var/lib/mysql/mysql-slow.log
log_error_verbosity            = 2


max-allowed-packet              = 6M
skip-name-resolve
sql-mode                        = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY
sysdate-is-now                  = 1



datadir                         = /var/lib/mysql


key-buffer-size                 = 128M
query_cache_size                = 128M #100M384M

tmp_table_size                  = 256M
max_heap_table_size             = 256M

innodb-buffer-pool-size         = 2G 
innodb_log_buffer_size          = 8M
innodb_log_file_size            = 1G


wait_timeout                    = 10
interactive_timeout             = 300


max-connect-errors              = 100000
max-connections                 = 200


sort_buffer_size                = 4M
read_buffer_size                = 2M
read_rnd_buffer_size            = 2M
join_buffer_size                = 2M
thread_stack                    = 4M
thread-cache-size               = 80


performance_schema              = on


query_cache_type                = 1 #0 #1
query_cache_limit               = 128M


table_open_cache                = 2680
open-files-limit                = 1024000
table-definition-cache          = 3024



# IOPS OPTIMIZATION #

innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-flush-log-at-trx-commit = 2

innodb_buffer_pool_instances   = 1
innodb_stats_on_metadata       = 0

innodb_io_capacity             = 100
innodb_use_native_aio          = 1
innodb-file-per-table          = 0

explicit_defaults_for_timestamp = 1

[このconfは2 vcpuと4 GB RAM、10 GB SSD、100IOPS用] AWS NLB + Auto Scaling Serviceでうまく動作します。

その他の最適化では、innodbバッファーをインスタンスのメモリの50％に増やし、innodb_log_file_sizeをinnodb-buffer-pool-size値の50％に増やします。

これを読んでください： https://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-diskio.html

私はあなたや同じ問題を持つ他のユーザーを助けたいと思います。 =）

5
Gustavo alves