web-dev-qa-db-ja.com

MySQLサーバーのパフォーマンスを最適化する

Vultrに8 GBのRAMと4vCPUを備えたVPSサーバーがあり、最適化されたmysql設定を取得しようとしています。私は約170のInnoDBテーブルのDBを持っていますが、それらにはほとんど多くのデータが含まれていません。 MyISAMテーブルは2つありますが、それぞれ150k行あり、350kに増やしたいと思います。

ここでの課題は、1回の計算ごとに長い/緯度のデータを含むテーブルで地理計算を行い、150,000行全体を通過し、最も近い（5マイル以内）距離を特定し、そのデータのみを出力することです。 。これは明らかに非常にリソースを消費します。そのため、150k行から200k行に増加すると、クエリに1秒長くかかり、350k行に増加すると、クエリごとに3〜4秒かかります。この段階ではクエリ自体を更新することはできませんが、mysqlの改善にできるだけ取り組むことができます。

MySQL設定の更新を開始し、パフォーマンスを大幅に改善しました。以下は、tuning-primerからの出力です。

MySQLバージョン5.5.55-0ubuntu0.14.04.1 x86_64

稼働時間= 2日12時間1分56秒平均qps = 61質問合計= 2665033接続されたスレッド= 3

スロークエリスロークエリログは有効になっていません。現在のlong_query_time = 10.000000秒。 10.650秒より長い2665054のうち0があります。あなたのlong_query_timeを完了するには問題ないようです

バイナリ更新ログバイナリ更新ログは有効になっていません。ポイントインタイムリカバリを実行できなくなります。参照 http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html

ワーカースレッド現在のthread_cache_size = 8現在のthreads_cached = 5現在のthreads_per_sec = 0歴史的なthreads_per_sec = 0 thread_cache_sizeは正常です

MAX CONNECTIONS現在のmax_connections = 151現在のthreads_connected = 3歴史的なmax_used_connections = 9使用されている接続の数は、設定された最大数の5％です。構成済みのmax_connectionsの10％未満を使用しています。 max_connectionsを下げると、メモリの過剰割り当てを回避するのに役立ちます。「割り当ての使用」セクションを参照して、割り当てが過剰にならないようにしてください。

INNODBステータス現在のInnoDBインデックススペース= 35 M現在のInnoDBデータスペース= 56 M現在のInnoDBバッファープールの空き容量= 25％現在のinnodb_buffer_pool_size = 128 M合計システムメモリの2/3

これまでに割り当てられたメモリの最大メモリ：4.48 G構成済みのスレッドごとの最大バッファー：1.53 G構成済みの最大グローバルバッファー：4.39 G構成済みの最大メモリ制限：5.92 G物理メモリ：7.79 G最大メモリ制限は許容範囲内にあるようです

キーバッファー現在のMyISAMインデックススペース= 79 M現在のkey_buffer_size = 256 Mキーキャッシュミス率は1：9866キーバッファーの空き率= 79％key_buffer_sizeは問題ないようです

クエリキャッシュクエリキャッシュが有効になっています現在のquery_cache_size = 4.00 G現在のquery_cache_used = 889 M現在のquery_cache_limit = 4 M現在のクエリキャッシュメモリフィル率= 21.71％現在のquery_cache_min_res_unit = 4 K query_cache_sizeが高すぎるようです。おそらく、MySQLがquery_cache_limitより大きいサイズのクエリ結果をキャッシュしない場所で、これらのリソースを使用できます。

ソート操作現在のsort_buffer_size = 2 M現在のread_rnd_buffer_size = 256 Kソートバッファーは問題ないようです

JOINS現在のjoin_buffer_size = 4.00 M結合がインデックスを正しく使用できない72592クエリがありましたjoin_buffer_size> = 4 Mこれはお勧めできません "log-queries-not-using-indexes"を有効にする必要があります遅いクエリログ。

OPEN FILES LIMIT現在のopen_files_limit = 2209ファイル通常、MyISAMの使用量が多い場合、open_files_limitをtable_cacheの2x〜3xに設定する必要があります。あなたのopen_files_limit値は問題ないようです

TABLE CACHE現在のtable_open_cache = 1024個のテーブル現在のtable_definition_cache = 1024個のテーブル合計702個のテーブルがあります1024個の開いているテーブルがあります。現在のtable_cacheヒット率は55％ですが、テーブルキャッシュの100％が使用されていますtable_cacheを増やす必要があります

TEMP TABLES現在のmax_heap_table_size = 16 M現在のtmp_table_size = 16 M 162009の一時テーブルのうち、1％がディスク上に作成されました作成されたディスクtmpテーブルの比率は問題ないようです

TABLE SCANS現在のread_buffer_size = 3 M現在のテーブルスキャン率= 66078：1 read_buffer_sizeで問題ないようです

テーブルのロック現在のロック待機率= 1：696683テーブルのロックは問題ないようです

ご協力いただきありがとうございます。詳細については、お問い合わせください。 mysql 5.6または5.7へのアップグレードに役立ちますか？

mysqlmysql-5.5optimizationperformancemysqltunerperformance-tuning
2
behjattiger

部分的にはデータベース、部分的にはプログラミングの問題。

15万行すべてを通過する必要があるすべての計算について、長い/緯度のデータを使用してテーブルで地理計算を行い、どれが最も近いか（5マイル以内）を決定します

これを効率的に行うには、LongituteとLatitudeのインデックスが必要です。

そして、いくつかの再構成-MySQLがそのまま（SQL Serverのように）サポートしない限り。

5マイルのRADIUS内では何も探しません。中心点から北、南、東、西に5マイルのBOXで何かを探します。それがデータベースにヒットします。

次に、2番目のステップで無線をフィルタリングします。

インデックスの1つで解決可能なクエリが突然発生したことに注意してください。実際の距離計算は、データのごく一部についてのみ行います。

とはいえ、なぜ空間インデックスを作成しないのですか？ MySQL 5.7は、ドキュメントに従ってそれをサポートしています。 htepローパーデータタイプを使用してください。

1
TomTom

Lat/lngパフォーマンスの問題を解決するためのステップ1：

INDEX(latitude),
INDEX(longitude)

それが適切に機能しない場合は、 http://mysql.rjweb.org/doc.php/latlng を参照してください

詳細については、SHOW CREATE TABLEと、テーブルスキャンを実行しているSELECTです。

innodb_buffer_pool_size = 128 M-最も重要なパフォーマンスチューニングは、それをavailableの70％に設定することです-RAM（すべてのテーブルを想定するとInnoDBです）。

なぜ2つのMyISAMテーブルがあるのですか？それらの変換について話しましょう。

query_cache_size = 4.00 G-これは本当に悪い悪いです。 50M以上に設定しないでください。

1
Rick James
  1. 読み取りパフォーマンスは、主にテーブルに適切なインデックスを設定し、クエリを適切に設計することに依存しています。これに代わるものはありません。
  2. この記事では、InnoDBのパフォーマンスを最適化するための指針をいくつか示します https://www.percona.com/blog/2007/11/01/innodb-performance-optimization-basics/

こちらもご覧ください https://stackoverflow.com/questions/45001764/should-mysql-take-this-long-or-is-configuration-wrong/45001812?noredirect=1#comment76977777_45001812

書き込みパフォーマンスは、実質的に2つの設定に依存します（これらの設定では書き込みが高速ですが、最初の設定に関連する問題があります。記事で説明します）。

set global innodb_flush_log_at_trx_commit=2
set global general-log=0
1
Allen King