BLOBからfilestorageへの変更 - mySQLの微調整

Question

ファイルバイナリがBLOBとして保存されていた昔、私はプロジェクトを引き継ぎました。それらは0.5〜50Mbの大きさであったため、テーブルはできるだけ触れられませんでした（→eBeans lazyloadingなど）。いったんAWS EC2インスタンス+ RDSに切り替えると、（明らかに）遅くなりました。

私はデータストレージをBLOBからS3に変更しました（+ DBに格納されたバケット/キーへの参照）。これはバックエンドとクライアントにとってははるかに高速です。

私の質問は明らかに、より大きなデータ（最大packagesizeなど）を扱うようにmySQL DBをセットアップする前のプログラマです。また、接続プールのサイズについていくつかの議論がありました。

mySQLの設定で確認する重要なパラメータは何ですか？それらを評価する有効な方法は何ですか？

Answer 1

あなたの質問に対する最も可能性の高い回答は、「何も変更しない」です。

MySQLには多くの「調整可能な」パラメータが多数あり、オンラインで「最適化」することについての悪いアドバイスがたくさんあります。しかし、これは避けられない誘惑です。

システム変数がデフォルト値から変更されている範囲では、設定を調整する必要があると思われる状況になった場合、最初の本物は、設定をデフォルトに戻す必要があります。特定で正当な理由はない。

設定が小さすぎると、大きな塊のようなものが壊れてしまいますが、必要以上に大きなサイズを設定しても影響はほとんどありません。「超過」は割り当てられていないか、そうでなければ有害です。 max_allowed_packetの場合、サーバが単一のパケットに割り当てなければならないメモリの量を制限することによってメモリ使用の制約が課されますが、レンガの壁の制限であるため、必ずしも縮小する必要はありません。大きなパケットを送信しない場合は、何も傷つけることはありません。

余分なメモリが必要なときだけ割り当てられるので、この変数の値を増やすことは安全です。たとえば、mysqldは長いクエリを発行した場合、またはmysqldが大きな結果の行を返す必要がある場合にのみ、より多くのメモリを割り当てます。変数の小さなデフォルト値は、クライアントとサーバーの間の不正なパケットをキャッチし、大きなパケットを誤って使用してメモリが不足しないようにするための予防措置です。

http://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html

その他のパラメータ「有効」値の範囲は「最適」な値の範囲のスーパーセットであるため、しかし、劇的にカウンターintuitice negative effectsを持つことができます。クエリキャッシュはこれの代表的な例です。 "しかし、それはより多くのキャッシュです！どのように悪いことができますか？さて、大きな家はあなたがしなければならない家事の量を増やします。そして、クエリキャッシュは、小さな箒（各スレッドが出入りする際に競合するグローバルミューテックス）を持つ大きな家です。

さらに、innodb_buffer_pool_sizeのように、実際には特定のサーバーの値の比較的小さな最適な範囲が1つしかありません。小さすぎると、プールがシステムよりも小さいため、ディスクI/Oが増加し、パフォーマンスが低下する可能性があります。大きすぎると、スワップ領域を使用しているサーバーのためにディスクI/Oが増加します。または、最後に使用可能なすべてのキロバイト空きRAMの

おそらくあなたは考えを得るでしょう。

準最適に​​構成されている可能性がある特定のパラメータがない場合は、動作中のシステムを動作させたままにします。物事を変えた場合は、一度に1つずつ変更し、進める前にそれぞれの変更が良いアイデアであることを立証したり、反証したりしてください。デフォルト以外の値を使用している場合は、デフォルト値を潜在的に良好な候補値と見なします。

変更する必要があるパラメータについての提案をする「チューニングスクリプト」から離れてください。それらは見るのが面白いですが、彼らのアドバイスはしばしば危険です。私はしばしばこれらのうちの自分のものを書くことを考えましたが、デフォルトに設定されていない値をチェックし、自分自身を説明したり、戻したりするように指示するだけです。 :)多分それはキャッチするだろう。