web-dev-qa-db-ja.com

データベースに必要なハードウェアリソースの量をどのように計算しますか？

現在、データベースサーバーのスケーリングを行っています。データベースに必要なハードウェアリソースの量をどのように計算すればよいのでしょうか。

現在のデータベースサーバーに関する情報を次に示します。

  • MySQLデータベース
  • すべてのテーブルのInnoDB
  • 約80テーブル
  • 最大のテーブルは、15 GB、13 GB、12 GB、5 GB、残りが1 GB未満です。
  • ディスク上のデータベースのサイズは175 GBで、ibdata1、およびそれなしで56 GB
  • データベースは毎月約10％増加します-12か月前は約5-6％でした
  • 通常の使用で実行される約60の接続
  • InnoDBバッファーサイズは合計24 GBのうち16 GBで、99％使用されています
  • 2.27 GHz Intel Xeon 8コアL5520のCPU使用率は約30％
  • 約33％が書き込み、66％が読み取り
  • 以下のスニペットによると、2.31 TPSと1126 QPSがあります-QPSは750と1500の間で急上昇しているようです

。

use information_schema;
select VARIABLE_VALUE into @num_queries from GLOBAL_STATUS where VARIABLE_NAME = 'QUESTIONS';
select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME = 'UPTIME';
select VARIABLE_VALUE into @num_com from GLOBAL_STATUS where VARIABLE_NAME = 'COM_COMMIT';
select VARIABLE_VALUE into @num_roll from GLOBAL_STATUS where VARIABLE_NAME = 'COM_ROLLBACK';
select (@num_com + @num_roll) / @uptime as tps, @num_queries / @uptime as qps;

現在のサービスプロバイダーは、次のアップグレードを提供しています。

  • アクティブ/パッシブ設計（2台のサーバー、それぞれ以下で説明）
  • シングルプロセッサ、Octo Core Intel Xeon E5-2630 v3 2.4Ghz
  • 64 GBのメモリ
  • RAID 1; 300 GB 12 Gbps（15,000 SAS 2.5 "）x 2

私の質問は：

  1. これがやりすぎかどうかはどうすればわかりますか？これは明らかに巨大なアップグレードであるという事実にもかかわらず、それが本当に必要なものであり、リソースの浪費や目立たないパフォーマンスの向上ではないかどうかを知りたいのです。式、記事、または本の推奨事項は高く評価されます。
  2. 現在のデータベースの詳細を考えると、必要なリソースを見つけるのに役立つ自動化されたツールはありますか？

更新＃1

変数を表示

グローバル変数を表示

グローバルステータスを表示

RIADコントローラー

  • Dell PERC 6i; RAID 5
  • 書き込みポリシー：ライトスルーとライトバック
  • キャッシュメモリサイズ：256 MB
mysqldata-warehousehardwarescalability
6
Mahdi

短い答え：わかりません。十分な情報がありません。

長い答え...

データが10％/月で増加している場合、64/24倍のサイズになるまでに約1年かかります。したがって、RAMとbuffer_poolを64/24増加させると、buffer_poolと同じキャッシュパフォーマンスが得られる可能性が高くなります。わずか1年後です。

99％の使用率は、ワーキングセットが少なくとも16GBであること以外は何も言っていません。データセットはそれよりもはるかに大きいので、それは当然のことです。

30％のCPUとは、平均して1.3コアが常に実行されていることを意味しますか？もしそうなら、私はあなたがいくつかの遅いクエリを持っていると思います。それらを見て、改善できるかどうか見てみましょう。運が良ければ、いくつかのクエリを修正すると、より強力なマシンの必要性が遅れる可能性があります。

8コア（1.3と比較）は、コアがたくさんある可能性が高いと言っています。しかし、現在の4を超える可能性があります。

すべてのデータを移動する必要があるため、移動を開始する前に、新しいマシンでinnodb_file_per_table=1を設定することを強くお勧めします。 （私はあなたがInnoDBを使用していると思います。）

移動するときにMySQLをアップグレードします。

query_cache_sizeを50Mより大きく設定しないでください。これが高CPUの原因である可能性があります。 「常に」すべてのテーブルに書き込む場合は、クエリキャッシュを完全にオフにすることをお勧めします。 （これは購入を停止する別の方法かもしれません。）

I/O容量の何パーセントを現在使用していますか？

新しいRAIDにはバッテリバックアップ式書き込みキャッシュがありますか？これにより、書き込みが事実上無料になります。

さらに分析が必要な場合は、提供してください

RAM size (currently 24GB)
SHOW VARIABLES;
SHOW GLOBAL STATUS;   -- STATUS, not VARIABLES.

ADDENDA-変数とステータスのレビュー

**観察

バージョン：5.6.13-log 24 GBのRAMあなたはWindows上で実行しています。64ビットバージョンを実行しています。InnoDB全体（または大部分）を実行しているようです。

より重要な問題

  • innodb_buffer_pool_sizeをRAMの約70％に増やす必要があります。

  • innodb_log_file_sizeを約300Mに増やします。幸い、これは5.6.8以降で簡単です。

  • 頻繁に変更されるデータベース（「USE」）について何かを行います。以下のCom_change_dbを参照してください。

  • read_buffer_size = 128K

  • 複数のステートメントをトランザクションにまとめることが理にかなっているかどうかを確認します。

  • 遅いクエリに取り組みます。

詳細

（innodb_buffer_pool_size/_ram）= 12,884,901,888/24576M = 50.0％-=RAM InnoDB buffer_poolに使用される（（Innodb_buffer_pool_reads + Innodb_buffer_pool_pages_flushed））=（（21354175 + 179458852））） sec-InnoDB I/O-innodb_buffer_pool_sizeを増やしますか？

（Innodb_log_writes）= 306,041,138/1821852 = 167 /秒

（稼働時間/ 60 * innodb_log_file_size/Innodb_os_log_written）= 1,821,852/60 * 48M/314550301184 = 4.86-InnoDBログローテーション間の分5.6.8以降、これは動的に変更できます。 my.cnfも必ず変更してください。 -（ローテーション間の60分の推奨はやや恣意的です。）innodb_log_file_sizeを調整します。

（tmp_table_size）= 179M-SELECTのサポートに使用される一時テーブル[〜＃〜] memory [〜＃〜]の一時テーブルのサイズの制限-tmp_table_sizeを減らして、不足するのを防ぎます羊。おそらく64M以下です。

（Handler_read_rnd_next）= 766,168,067,814/1821852 = 420543 /秒-大量のテーブルスキャン（Select_full_join）= 29,673,902/1821852 = 16 /秒-インデックスなしの結合（Select_scan）= 70,915,674/1821852 = 39 /秒-フルテーブルスキャン（Select_scan/Com_select）= 70,915,674/771524414 = 9.2％-全表スキャンを実行する選択の割合。 （ストアドルーチンにだまされる可能性があります。）（Created_tmp_tables）= 75 /秒-インデックスの追加/クエリの最適化

（Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi）=（30050199 + 842 + 264 + 0 + 287315111 + 278）/ 1821852 = 174 /秒-書き込み/秒-50書き込み/秒+ログのフラッシュはおそらく最大通常のドライブのI/O書き込み容量

（long_query_time）= 10.000000 = 10-「遅い」クエリを定義するためのカットオフ（秒）。 -提案2

（Com_change_db /接続数）= 953,574,484/23878 = 39,935-接続あたりのデータベーススイッチ数（Com_change_db）= 953,574,484/1821852 = 523 /秒-おそらくUSEステートメントが原因です。 -DBとの接続、db.tbl構文の使用、偽のUSEステートメントの削除などを検討してください。

（Threads_created /接続）= 1,339/23878 = 5.6％-プロセス作成の迅速性-thread_cache_sizeを増やす（Windows以外）

（read_buffer_size）= 65536- http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_read_buffer_size -128Kの方が良いかもしれませんが、この時点で予測するのが難しいこと。

ADDENDA 2-質問に戻ります

一般的に、あなたが言及した方向へのスケーリングはうまくいくようです。

  • あなたは今かなりうまく動いているようです。
  • 私はあなたがあなたが持っているものでしばらくの間生きるのを助けるいくつかのものを箇条書きにしました。
  • 難しいもの：不要なサードパーティのism（change_dbなど）を取り除く
  • 難しい問題：遅いクエリを見つけて改善する
  • すでに最新の5.6を使用しているため、8コアでより多くの接続を処理するのは簡単です。
  • InnoDB I/Oはたくさんありますが、キャッシュが「非効率的」であることを示すものは何もありません。 RAMが増えると、変更する最も重要なことはinnodb_buffer_pool_size（使用可能なRAMの70％まで）になります。
  • 10％/月、1年か2年後に成長すれば、その「大規模なアップグレード」を行うことができ、再度アップグレードする必要はありません。

気になることが1つあります...現在、通常のドライブの最大容量に達しています。 （InnoDBから110のIOPが表示されます。）それが10％に達すると、最初にI/O容量が不足する可能性があります。あなたの新しい設定は少しだけ役に立ちます。代替策：RAID-5（ストライピングとパリティー、ただし少なくとも3つのドライブが必要）またはSSD（より高価）。

10
Rick James