Lock:extend
Lock:extend
イベントは、バックエンドプロセスがリレーションを拡張するためにロックするのを待っているときに、別のプロセスが同じ目的でそのリレーションをロックしていると発生します。
サポート対象エンジンバージョン
この待機イベント情報は、Aurora PostgreSQL のすべてのバージョンでサポートされています。
Context
イベントLock:extend
は、バックエンドプロセスがリレーションの拡張する間、他のバックエンドプロセスがそのリレーションを拡張するのを待っている間にロックを保持することを示しています。リレーションを拡張できるのは一度に 1 つのプロセスだけなので、システムはLock:extend
待機イベントを発生させます。INSERT
、COPY
、UPDATE
のオペレーションでこのイベントを生成することができます。
待機時間が増加する原因の可能性
Lock:extend
イベントが通常より頻繁に発生する場合は、パフォーマンスの問題を示していることがあります。典型的な原因は次のとおりです。
- 同じテーブルへの同時挿入または更新の急増
-
同じテーブルに挿入または更新するクエリの同時セッションが増加する可能性があります。
- ネットワーク帯域幅の不足
-
DB インスタンスのネットワーク帯域幅が、現在のワークロードのストレージ通信ニーズに対して不十分な可能性があります。これは、
Lock:extend
イベントの増加を引き起こすストレージレイテンシーの原因となることがあります。
アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
同じリレーションへの同時挿入と更新を減らす
まず、tup_inserted
、tup_updated
メトリクスの増加と、それに伴うこの待機イベントの増加があるかどうか判断します。その場合は、挿入および更新オペレーションで競合性が高いリレーションをチェックします。これを判断するには、n_tup_ins
およびn_tup_upd
フィールドでの値のpg_stat_all_tables
ビューへのクエリを実行します。pg_stat_all_tables
ビューの詳細については、PostgreSQL ドキュメントの「pg_stat_statements
ブロックおよびブロックされたクエリの詳細については、pg_stat_activity
次の例のとおりにクエリを実行します。
SELECT blocked.pid, blocked.usename, blocked.query, blocking.pid AS blocking_id, blocking.query AS blocking_query, blocking.wait_event AS blocking_wait_event, blocking.wait_event_type AS blocking_wait_event_type FROM pg_stat_activity AS blocked JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid)) where blocked.wait_event = 'extend' and blocked.wait_event_type = 'Lock'; pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type ------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+-------------------------- 7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
Lock:extend
イベントの増加に寄与するリレーションを特定したら、次の方法を使用して競合を減らします。
パーティション化によって同じテーブルの競合を減らせるかどうかを調べます。挿入または更新されたタプルを異なるパーティショニングすると、競合を減らすことができます。パーティショニングについては、「pg_partman エクステンションによる PostgreSQL パーティションの管理」を参照してください。
待機イベントが主に更新アクティビティによるものである場合は、リレーションのフィルファクタ値を減らすことを検討してください。これにより、更新時に新しいブロックのリクエストを減らすことができます。フィルファクタとは、テーブルページをパッキングするための最大容量を決定する、テーブルの格納パラメータです。これは、ページの総容量に対するパーセンテージで表されます。フィルファクタパラメータの詳細については、PostgreSQL ドキュメントの「CREATE TABLE
」を参照してください。 重要
この値を変更すると、ワークロードによってはパフォーマンスに悪影響を及ぼす可能性があるため、フィルファクタを変更する場合は、システムのテストを強くお勧めします。
ネットワーク帯域幅の増加
書き込みレイテンシーが増加しているかどうかを確認するには、WriteLatency
CloudWatch でメトリクスをチェックします。増加している場合は、Amazon CloudWatch のWriteThroughput
、ReadThroughput
メトリクスを使用し、DB クラスターのストレージに関するトラフィックをモニタリングしてください。これらのメトリックは、ネットワーク帯域幅がワークロードのストレージアクティビティに十分かどうかを判断するのに役立ちます。
ネットワーク帯域幅が不足している場合は、増加してください。DB インスタンスがネットワーク帯域幅の制限に達している場合、帯域幅を増やす唯一の方法は DB インスタンスのサイズを大きくすることです。
CloudWatch のメトリクスの詳細については、「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。DB インスタンスクラスごとの DB エンジンサポートについては、「Aurora 用の DB インスタンスクラスのハードウェア仕様」を参照してください。