新ツール Postgres Workload Report によるパフォーマンス診断～データベース管理の未来を共に創る！～

本記事は、エンタープライズDB社のブログ記事を翻訳した内容をご紹介しています。

アプリケーションを Oracle Database から PostgreSQL に正常に移行するためには、これらの変更の影響を最も受けるチーム（DBA、開発者）に適切なツールを提供する必要があります。

EnterpriseDB社は Postgres Workload Report（PWR）をリリースし、お客様のオープンソースデータベースへの移行をさらに容易にするために、大きな一歩を踏み出しました。Automatic Workload Repository（AWR）のフォーマットを実装することで、Oracle Database ユーザーに親しみやすさを提供するだけでなく、PWR はデータベースパフォーマンス分析を進化させ、問題発生時の診断とトラブルシューティングを改善します。

PWR 機能は、EnterpriseDB社とサブスクリプション締結をした、PostgreSQL(Standard Plan)およびEDB Postgres Advanced Server(Enterprise Plan)をご利用のお客様にてご利用いただけます。

Oracle Database の AWR レポートは、データベースパフォーマンスの診断とチューニングに関する詳細な情報を提供するため、エンタープライズデータベース環境における標準的で信頼できるパフォーマンス監視および最適化ツールです。Oracle DBA にとって、同様の PostgreSQL ツールが存在しない場合、PostgreSQL への移行時に追加のスキル習得が必要になる可能性があります。

管理者が Oracle Database と PostgreSQL の両方のデータベースを監視する混合データベース環境では、AWR の特定の形式とデータの詳細レベルが PostgreSQL レポートには再現されないため、移行の課題はさらに深刻になる可能性があります。

この情報を要約、表示、共有できないことは、単なる機能のギャップではなく、PostgreSQL でのデータベースパフォーマンスの診断に対する大きな障壁です。これらの課題は、PostgreSQL 環境における DBA の生産性に影響を及ぼし、結果としてビジネスアプリケーションのダウンタイムにつながる可能性があります。

EnterpriseDB社は、PWR の開発において、Oracle Database の AWR の機能と詳細さを反映しながらも、最新の PostgreSQL 環境向けに特別に構築されたツールを提供することで、Oracle Database と PostgreSQL の診断品質のギャップを埋めました。PWR により、EDB は、詳細なメトリック、わかりやすいレポート、組織での採用を促進する AWR のようなユーザーインターフェースを備えた、PostgreSQL エコシステム向けの最善のパフォーマンス診断を提供します。PWR は、DBA に高性能な PostgreSQL を確保するために必要なツールを提供し、重要なビジネスアプリケーションの中断のない運用をサポートします。

PWR で待機イベントの情報を提供することは DBA にとって貴重な機能であり、これらのレポートでは上位の SQL ステートメントと PostgreSQL 構成情報に関する洞察も提供されます。その結果、PWR を使用すると、DBA と開発者は Markdown、PDF、または HTML のいずれかの単一のレポートを評価することで、データベースで発生しているパフォーマンスの問題を簡単に理解して解決できます。

必要に応じて、PWR をより経験豊富な DBA や専門家に送信してさらに分析し、組織の PostgreSQL 診断とトラブルシューティングの能力を強化できます。

PWR には多くの機能がありますが、他の多くの PostgreSQL パフォーマンスツールと比較して新しくユニークなのは、特定の時間枠でどのクエリが待機していたかを評価できることです。これらの分析は、edb_wait_states 拡張機能によって可能になります。たとえば、HammerDB を使用して PostgreSQL サーバーに対して実行されたワークロードを PWR レポートから分析してみます。

まず、レポートのサーバー情報（Server information）セクションを見てみましょう。

サーバーに関する一般的な情報をすぐに確認できます。

ここでは actual_start_snap_ts（2024-02-15 07:44:18.588779+00）と actual_end_snap_ts（2024-02-15 07:54:16.587401+00）の 2 つの項目に注目してみましょう。これらのタイムスタンプから 10 分間のワークロードを評価していることがわかります。また、サーバー情報セクションには dbtime が表示されており、この期間中の dbtime は 184 秒であることを確認しています。つまり、この 10 分間のスナップショット中に、データベースサーバーでは 184 秒間のクエリ実行や待機が発生したことが分かります。

この時、PostgreSQL のパフォーマンストラブルシューティングに取り組む方々を困惑させてきた質問は次のとおりです。

PWR は、「Top wait events」のセクションに示されている内容から、これら 2 つの質問に答えることができます。

画像2：トップ待機イベント

評価された 184 秒のうち、124 秒は ClientRead イベントの待機に費やされました。PostgreSQL ドキュメントの セクション 28.2 を参照すると、このメトリックはシステムがクライアントからのデータの読み取りを待機していたことを示しています。

では、これは何を意味するのでしょうか？様々なことが考えられますが、例えば次のようなことが考えられます。

これは明らかに、サーバー上の何かがシステムのスループットに影響を与えているのではなく、問題はクライアントにあると考えられます。

「Top SQL statements」のセクションを確認すると、次のことがわかります。

　
　COPY order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info, ol_delivery_d) FROM STDIN WITH (FORMAT CSV)
　

これは、この期間中のボトルネックとして、クライアントマシン上の標準入力（STDIN）からの CSV ファイルの読み取りが含まれていたことを示しています。

これまで、サーバーが何を待機しているかに関する情報を取得することは非常に困難でした。PWR を使用すると、それが簡単になります。任意の期間の待機イベントを評価し、システムが直面している可能性のある問題を判断できます。

上位の SQL イベント、待機イベント、セッションアクティビティに関する情報を要約、表示、共有できないことが、PostgreSQL でのデータベースパフォーマンスの診断に大きな障害となっていました。この PostgreSQL の機能ギャップは DBA の生産性に悪影響を及ぼし、結果としてビジネスアプリケーションのダウンタイムにつながる可能性があります。現在、PWR は、DBA に PostgreSQL の高パフォーマンスを確保するために必要なツールを提供し、重要なビジネスアプリケーションでの安定した運用をサポートしています。

PWR は、他の PostgreSQL ツールでは把握しにくいシステムの動作を DBA が理解するのに役立ちます。この詳細な情報は、複雑なデータベースパフォーマンスの問題を診断し、解決するために非常に重要です。PWR を使用することで、収益を生み出すデータベースの状況を深く理解し、PostgreSQL データベースを積極的に最適化することができます。これにより、コストのかかるダウンタイムを回避することが可能になります。

本ブログ記事で PWR の魅力とその活用方法について、少しでもご理解いただけたなら幸いです。

PWR は複数の国内ユーザーからの要望を受け、EnterpriseDB社で実装したツールです。私たちは、このツールが皆様のデータベース運用において大いに役立つと信じています。しかし、さらに優れたツールにするためには、実際にご利用いただく皆様のフィードバックが欠かせません。ぜひ、PWR を実際に使っていただき、ご意見やご感想をお寄せください。

EnterpriseDB社はユーザーの声を基にこのツールをより一層改善し、皆様の期待に応えるものにしていきたいと考えています。一緒により良いデータベース管理の未来を築いていきましょう。

　資料をダウンロードする