RDS MySQL サーバーのイメージを、どの段階でより大きな CPU/RAM インスタンスに増やす必要があるのか疑問に思っています。
CPU 使用率のグラフは 0 に近く、平均空きメモリは約 150 MB です。平均スワップ使用量は 420 MB です。
読み取りレイテンシは 0 ～ 20 ミリ秒/操作ですが、ランダムに急上昇します。平均書き込みレイテンシは平均 5 ミリ秒/操作ですが、最大 10 ～ 20 ミリ秒/操作まで急上昇します。
ここで従うべき共通のルールはありますか?
ありがとう！
答え1
共通のルールはない
パフォーマンス ルールは、恣意的なものではなく、ビジネスおよび技術目標に基づいて設定する必要があります。
どのようなパフォーマンスの問題を解決または防止しようとしていますか?
指標はパフォーマンスと一致するものではなく、ビジネス目標や技術目標とはほとんど関係がないことがよくあります。
通常、私はパフォーマンスの 2 つの側面に注目します。
- パフォーマンス目標を満たすために監視する必要がある指標は何ですか?
- これらのパフォーマンス目標を確実に達成するために、どの程度のリソース オーバーヘッドを維持したいか。
他のデータがない場合にデータベース リソース メトリックのみに焦点を当てても、あまり役に立たない可能性があります。これらのメトリックにはコンテキストが必要です。そうでない場合は、時期尚早な最適化にしかなりません。
使用率がわかっている場合、このようなメトリックは容量計画に役立ちます。
したがって、おそらくより重要な質問は次のようになります。
- ピーク使用レベルで、アプリケーションのパフォーマンスは許容範囲内ですか?
- ピーク時のリソース使用率はどのくらいですか?
- 予想される成長により、リソースの使用率はどうなるでしょうか?
多くの場合、人々は ping、電力、パイプ (CPU/ディスク/RAM) と呼んでいるものに注目しています。これらが注目すべき重要な点であることはほとんどありません。
上記の質問に対するデータを取得し、目標を設定すると、技術的およびビジネス上の正当性の両方に基づいてスケーラビリティの決定を下すのに役立ちます。
答え2
RDS インスタンスで確認したところ、FreeableMemory はかなり低く、SwapUsage は比較的高いようです。ワークロードはメモリを大量に消費するため、少なくともメモリを追加すれば改善されると思われます。
より一貫したレイテンシを実現するには、すでに 300 GB 以上のストレージを割り当てている場合は、Provisioned IOP が最適です。http://docs.aws.amazon.com/AmazonRDS/latest/ユーザーガイド/USER_PIOPS.html