36 件中 1 - 10 件を表示
次の 10 件 »
Displaying posts with tag: Performance (reset)
SQL Profiling処理について

SQLの処理に時間がかかっている場合は、基本的にEXPLAINで実行プランを確認して頂き、
必要に応じてパフォーマンスチューニングして頂きますが、更にSQLのどのイベントで時間がかかっているか確認したい時はprofilingを利用していましたがDeprecate Noticeが以前から出ているので、
Performance Schemaを用いたProfilingに慣れていく必要があります。どうしても慣れているProfilingをいまだに使いがちなので、こちらに簡単にメモしておきます。色々なサイトで方法を説明して頂いているので詳細は記載しませんが、ここでは少しだけアウトプットを確認し易くしています。

環境

root@localhost [(none)]> select @@version;
+-----------+
| @@version | …
[さらに読む]
TempTable in MySQL8.0のメモ

MySQL8.0.16のリリースノートに以下の様にTempTableの処理に変更が加わっていたので仕様を把握する為に、追加されたパラメータと挙動に関して確認してみました。見ていると、8.0.23での変更や、8.0.26におけるtemptable_use_mmapのdeprecate notice,8.0.28における変更もあるようです。なので、最新の挙動は8.0.31以降で再確認します。結論としては、8.0.28以降ではTempTable, MEMORYストレージエンジン共にtmp_table_sizeを適切に設定する必要あり。グローバルで利用されるTempTableリソースは, temptable_max_ramで上限を設定され、Defaultは1GBになっています。

InnoDB: When the amount of memory occupied by the TempTable storage engine exceeds the limit defined by the temptable_max_ram variable, …

[さらに読む]
Statement_ID and events_statements_テーブル

MySQLを運用する中で、SYS Schemaを利用してインスタンスの状態を確認する事が増えていますが、Performance Schemaを直接見てSQL処理を確認するケースも相変わら多いか思います。まだ具体的にどの様に活用していくかは目途が付いていませんが、MySQL8.0.14のリリースノートに以下の様にSTATEMENT_IDが付与される様になったとの記載があったので念の為に概要だけ確認しておきます。

SYS Schema

The Performance Schema statement event tables (events_statements_current, events_statements_history, and events_statements_history_long) now have a STATEMENT_ID column that indicates the query ID maintained by the server at the SQL level. Column values are unique for the server instance because they are generated using a global counter that is incremented atomically.

[さらに読む]
スキャン範囲アクセス方法のスキップ

MySQL8.0.13のリリースノートに遡って見て見ると、以下の様な記述があったのでどのような処理なのか?どれだけパフォーマンスに影響があるのかを確認してみました。

Optimizer Notes: The optimizer now supports a Skip Scan access method that enables range access to be used in previously inapplicable situations to improve query performance. For more information, see Skip Scan Range Access Method. Thanks to Facebook for the patch on which this access method is based. (Bug #26976512, Bug #88103)

Changes in MySQL 8.0.13 (2018-10-22, General Availability)

Skip Scan Range Access Method (スキャン範囲アクセス方法のスキップ)

このクエリーを実行するために、MySQL …

[さらに読む]
 Query Rewrite Plugin

 Query Rewrite Pluginは以前から提供されていましたが、8.0.12以降でSELECT以外のDMLをサポートしたとの事でしたので、念の為に挙動を確認してみます。他に対応方法が無い場合以外で、積極的に利用するケースは思い付きませんが、選択肢の一つとして認識しておいて良いかと思います。

install_rewriter.sql: Rewriter プラグインとその関連要素をインストールするには、このスクリプトを選択します。

uninstall_rewriter.sql: Rewriter プラグインとその関連要素をアンインストールするには、このスクリプトを選択します。

Previously, the Rewriter query rewrite …

[さらに読む]
MySQLで実行された全てのクエリを取得する

MySQLで実行された全てのクエリを把握する方法を挙げてみる。 いくつか方法はあるが、負荷の高い環境でクエリをとるにはうするのが良いだろうか?

パフォーマンスチューニングが主たる目的なので、Restoreからロールフォワードすることは考えない。 SELECT文が取れないので、SBR形式でbinary_logを書くことも除く。 version, 5.6, 5.7あたりを想定。

[さらに読む]
Slave側のSystem lockについて

MySQL5.7までのSHOW SLAVE STATUSだけでは分からない事が多かったけど、MySQL8.0のSHOW SLAVE STATUSは少し改善されていた。
マスター側で負荷をかけて、スレーブの状態を確認した時にスレーブ側で”Systetm lock”という状態になっていて、詳細を確認する為にPerformance Schemaを確認してみた。
MySQL8.0からはPerformance_Schemaを確認しなくても”Slave_SQL_Running_State”で状態が確認出来るようになっている。
以下、MySQL8.0で確認したログですが、MySQL5.7では”System lock”だった状態が、MySQL8.0では”Applying batch of row changes (update)”になっています。

[admin@misc02 ~]$ cat repli_log | grep Slave_SQL_Running_State
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates …

[さらに読む]
MySQL SYSスキーマによるモニタリング

SYSスキーマの説明をする機会があったので、改めてMySQL5.7.21でSYSスキーマに関しての概要をまとめたのでご紹介。
Performance_Schema, Information_Schemaを直接確認しないと取得出来無い情報もまだあるけれど、SYSスキーマを利用すれば簡単にMySQLの状態を確認出来、複雑なクエリーを使わないでもロックの状態、メモリーの状態、未使用のインデックス、起動してからの累積値だけれども遅いクエリー等が確認可能です。まだまだ使われていないユーザーも多いけど、便利なので是非活用下さい。

MySQL5.7.21の時点では以下のオブジェクトが存在します。


root@localhost [sys]> select * from schema_object_overview where db = 'sys';
+-----+---------------+-------+
| db  | object_type   | count |
+-----+---------------+-------+
| sys | TRIGGER       |     2 |
| sys | FUNCTION …
[さらに読む]
index_condition_pushdownの条件

5.6.1で既に実装されていてDefaultでONになっているので,5.6や5.7では普段殆ど気にしてませんでしたが、質問頂いたのでindex_condition_pushdownの条件を再確認。
DefaultはONになっています。あえて、OFFにするメリットはあまり無いかと思います。

Index Condition Pushdown(ICP): ストレージエンジンからフェッチしたレコードをMySQLが評価してWHERE区の条件による絞り込みを行っていたが、
インデックスが貼られたカラムを用いた評価については、ストレージエンジンへ条件式を渡し(プッシュダウン)、ストレージエンジン側で評価を行わせることによってオーバーヘッドの低減させる。

ICPの目標は、完全なレコードの読み取りの回数を減らし、それによって I/O 操作を減らすことです。InnoDB …

[さらに読む]
MySQL Group Replicationのモニタリング

MySQL Group Replicationの監視に関しては、Performance_schemaからレプリケーションの状態を確認して、モニタリングする事が可能ですが、MySQL Enterprise Monitor3.4ではGroup ReplicationのトポロジーViewやAdvisor等で、モニタリングを簡素化して、システムの安定稼働と運用負荷を軽減してくれるようになりました。自作でモニタリングツールを作る事も可能ですが、ツールのアップデート等に工数がかかるので、出来るだけ既存のツールを利用したい場合は有用かと思います。

Group Replicationステータスモニタリング用オブジェクト
(Group Replication Status Monitoring MySQL Objects)

performance_schema.replication_group_member_stats
performance_schema.replication_group_members
performance_schema.replication_connection_status

[さらに読む]
36 件中 1 - 10 件を表示
次の 10 件 »