web-dev-qa-db-ja.com

MySQLパフォーマンスとメモリ

MySQL Ver 5.7.18をAmazon Lightsail Linuxインスタンスで実行しています（2GHzシングルコアCPU、2GB RAM、40GB SSD）。

MySQLのほかに、このマシンでいくつかのJavaサービスを実行して、データベースにアクセスします。

MySQLはデフォルト設定で実行されます。

マシンを再起動した後、またはMySQLサービスを再起動した後、一部のSELECTステートメントのパフォーマンスが大幅に低下していることがわかります。 SELECTステートメントはユーザー主導（Webフロントエンド）であり、ほとんどの場合、最新のエントリをフェッチします。数時間後、これらのステートメントのパフォーマンスが向上し始め、十分に高速になります（主に1000ミリ秒未満）。ただし、古い値に影響するクエリの実行を開始すると、パフォーマンスは再び劇的に低下し始めます。

mysqltuner.plを実行すると、次の出力が得られます。

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in InnoDB tables: 9.2G (Tables: 33)
[OK] Total fragmented tables: 0

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 20h 4m 38s (4M q [59.289 qps], 20K conn, TX: 8G, RX: 1G)
[--] Reads / Writes: 82% / 18%
[--] Binary logging is disabled
[--] Physical Memory     : 2.0G
[--] Max MySQL memory    : 465.9M
[--] Other process memory: 1.1G
[--] Total buffers: 296.0M global + 1.1M per thread (151 max threads)
[--] P_S Max memory usage: 72B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 333.1M (16.64% of installed RAM)
[OK] Maximum possible memory usage: 465.9M (23.28% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (16/4M)
[OK] Highest usage of available connections: 21% (33/151)
[OK] Aborted connections: 0.11%  (23/20438)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 1% (67 temp sorts / 3K sorts)
[OK] No joins without indexes
[OK] Temporary tables created on disk: 0% (623 on disk / 213K total)
[OK] Thread cache hit rate: 99% (45 created / 20K connections)
[OK] Table cache hit rate: 75% (1K open / 1K opened)
[OK] Open file limit used: 1% (66/5K)
[OK] Table locks acquired immediately: 100% (24K immediate / 24K locks)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[!!] InnoDB buffer pool / data size: 256.0M/9.2G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (37.5 %): 48.0M * 2/256.0M should be equal 25%
[OK] InnoDB buffer pool instances: 1
[--] Number of InnoDB Buffer Pool Chunk : 2 for 1 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 98.28% (338433973 hits/ 344356426 total)
[OK] InnoDB Write log efficiency: 91.11% (3684095 hits/ 4043723 total)
[OK] InnoDB log waits: 0.00% (0 waits / 359628 writes)

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    Set up a Password for user with the following SQL statement ( SET PASSWORD FOR 'user'@'SpecificDNSorIp' = PASSWORD('secure_password'); )
    Restrict Host for user@% to user@SpecificDNSorIp
    MySQL was started within the last 24 hours - recommendations may be inaccurate
    Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
    Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: [link]
Variables to adjust:
    innodb_buffer_pool_size (>= 9.2G) if possible.
    innodb_log_file_size should be (=32M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

出力は、innodb_buffer_pool_sizeを少なくともデータベースのサイズに調整することを推奨しています。これは、残念ながら、RAMメモリよりもはるかに大きいサイズです。

上記の動作はMySQLのバッファリング/キャッシング戦略が原因ですか、それとも構成の誤りが原因ですか？

RAM MySQLサーバーインスタンスのメモリは、データに効率的にアクセスするために、少なくともデータベースのサイズである必要がありますか？

今後、データベースは1か月あたり2,000万行の割合で増加すると予想されます。私が計算すると（20M行あたり約10GBのメモリ）、200GB以上が必要になりますRAM 1年後のメモリ。

追加でインストールするのではなく、データベースを配布するときの経験則はありますかRAMメモリ？

mysqlperformanceinnodbmemorymysql-5.7
2
trylimits
  • クエリキャッシュをオフのままにします-QCでそれを無駄にするのに十分なRAMがありません。
  • RAMが2GBしかない場合、256Mはinnodb_buffer_pool_size。これを上げるとスワップが発生し、パフォーマンスがさらに悪いになります。
  • 最善の解決策は、クエリを高速化することです。最悪のクエリを見つける必要があります。それらはおそらくテーブルスキャンを含み、いくつかのインデックス（おそらく複合インデックス）はそれらを非常に高速化します。またはクエリを再構成します。
  • それが失敗した場合、「正しい」解決策は、より大きなVMを入手することです。 （しかし、インデックス/クエリを改善できると思います。）
  • 「データベースの分散」は、「シャーディング」または自家製のソリューションのように聞こえます。これは大きな仕事です。私はこれをオプションのリストの3番目に置きます。
  • Javaは貴重なRAMスペースを使用しています。
2
Rick James

最初にこれらの2つの問題に対処してください。

[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.

シングルCPUだと言ったので...

0
Gerard H. Pille