PostgreSQL 監視の基本。 アレクセイ・レソフスキー

Data Egret の Alexey Lesovsky 氏によるレポート「PostgreSQL モニタリングの基礎」のトランスクリプトを読むことをお勧めします。

このレポートでは、Alexey Lesovsky が、post-gress 統計の重要なポイント、その意味、および監視に統計が存在する必要がある理由について説明します。 モニタリングにどのようなグラフを含めるべきか、それらを追加する方法、およびそれらを解釈する方法について。 このレポートは、Postgres のトラブルシューティングに関心のあるデータベース管理者、システム管理者、開発者にとって役立ちます。

私の名前は Alexey Lesovsky、Data Egret 社の代表です。

私自身について少し。 私はずっと前にシステム管理者として働き始めました。

私はあらゆる種類のさまざまな Linux システムを管理し、仮想化、監視、プロキシの操作など、Linux に関連するさまざまな作業に取り組みました。しかし、ある時点からデータベース、PostgreSQL をより多く使用し始めました。 私は彼のことが本当に好きでした。 そしてある時点から、勤務時間のほとんどを PostgreSQL で作業するようになりました。 そうして私は徐々に PostgreSQL DBA になりました。

そして、私のキャリアを通じて、私は常に統計、監視、遠隔測定のトピックに興味を持ってきました。 私がシステム管理者だったとき、Zabbix と非常に緊密に連携していました。 そして、次のような小さなスクリプトセットを書きました zabbix 拡張機能。 彼は当時かなり人気がありました。 そこでは、Linux だけでなく、さまざまなコンポーネントなど、非常に異なる重要なものを監視することができました。

今はPostgreSQLに取り組んでいます。 私はすでに、PostgreSQL 統計を操作できるようにする別の記事を書いています。 いわゆる pgCenter (ハブレに関する記事 - 緊張や緊張のない、試合後の統計).

ちょっとした紹介文。 私たちの顧客、クライアントはどのような状況にありますか？ データベースに関連して何らかの事故が発生しました。 そして、データベースがすでに復元されていると、部門の責任者または開発責任者がやって来て、「皆さん、私たちはデータベースを監視する必要があります。何か悪いことが起こったので、今後このようなことが起こらないようにする必要があります。」と言いました。 そしてここから、データベース (PostgreSQL、MySQL、またはその他) を監視できるように監視システムを選択するか、既存の監視システムを適応させるという興味深いプロセスが始まります。 そして同僚たちは次のように提案し始めます。「これこれのデータベースがあると聞きました。 使ってみましょう。」 同僚同士が口論を始めます。 そして最終的には、ある種のデータベースを選択することになりますが、その中での PostgreSQL 監視はかなり貧弱に表示され、常に何かを追加する必要があります。 GitHub からリポジトリをいくつか取得し、クローンを作成し、スクリプトを調整して、何らかの方法でカスタマイズします。 そして最終的にはある種の手作業になるのです。

したがって、この講演では、PostgreSQL だけでなくデータベースの監視を選択する方法についての知識を提供したいと思います。 また、監視を完了して何らかの利益を得ることができるようにするための知識を提供します。これにより、今後発生する可能性のある緊急事態を迅速に防ぐために、データベースを有益に監視できるようになります。

そして、このレポートに含まれるアイデアは、DBMS であっても noSQL であっても、あらゆるデータベースに直接適用できます。 したがって、PostgreSQL だけでなく、PostgreSQL でこれを行う方法については多くのレシピが存在します。 クエリの例、PostgreSQL が監視のために持つエンティティの例があります。 また、DBMS にモニタリングを可能にする同じ機能がある場合は、それらを調整して追加することもできます。

レポートには載ってないよ
メトリクスを配信および保存する方法について説明します。 データの後処理とユーザーへの提示については何も言いません。 警告については何も言いません。
しかし、ストーリーが進むにつれて、既存の監視のさまざまなスクリーンショットを見せて、何らかの形で批判します。 ただし、これらの製品に対する広告やアンチ広告を作成しないように、私はブランドの名前を出さないようにします。 したがって、すべての偶然はランダムであり、あなたの想像力に任されています。

まず、モニタリングとは何かを理解しましょう。 モニタリングは非常に重要なことです。 誰もがこれを理解しています。 しかし同時に、モニタリングはビジネス製品に関連しておらず、会社の利益に直接影響を与えるものではないため、常に残余ベースのモニタリングに時間が割り当てられます。 時間があればモニタリングを行いますが、時間がなければバックログに入れて、いつかこれらのタスクに戻ります。

したがって、私たちの実務から言えば、クライアントを訪問するときのモニタリングは不完全であることが多く、データベースをより適切に処理するのに役立つような興味深い内容が含まれていないことがよくあります。 したがって、監視は常に完了する必要があります。

データベースは情報のリポジトリであるため、データベースは非常に複雑であり、監視する必要もあります。 また、情報は企業にとって非常に重要であり、決して失うことはできません。 しかし同時に、データベースは非常に複雑なソフトウェアです。 これらは多数のコンポーネントで構成されています。 そして、これらのコンポーネントの多くは監視する必要があります。

特に PostgreSQL について話している場合、多数のコンポーネントで構成されるスキームの形式で表すことができます。 これらのコンポーネントは相互に作用します。 同時に、PostgreSQL には、いわゆる Stats Collector サブシステムがあり、これを使用すると、これらのサブシステムの動作に関する統計を収集し、管理者またはユーザーがこれらの統計を表示できるように、ある種のインターフェイスを提供できます。

これらの統計は、特定の関数とビューのセットの形式で表示されます。 テーブルと呼ぶこともできます。 つまり、通常の psql クライアントを使用してデータベースに接続し、これらの関数とビューを選択して、PostgreSQL サブシステムの動作に関する特定の数値を取得できます。

これらの数値をお気に入りの監視システムに追加し、グラフを描画し、機能を追加して、長期的な分析を取得できます。

ただし、丸一日かかる可能性があるため、このレポートではこれらすべての機能を完全に説明することはしません。 文字通り、XNUMX つ、XNUMX つ、または XNUMX つのことについて取り上げ、それらが監視をより良くするのにどのように役立つかを説明します。

データベースの監視について話す場合、何を監視する必要があるのでしょうか? まず第一に、可用性を監視する必要があります。データベースはクライアントにデータへのアクセスを提供するサービスであり、可用性を監視し、その定性的および定量的特性の一部も提供する必要があるためです。

また、データベースに接続するクライアントは通常のクライアントである場合もあれば、データベースに損害を与える可能性がある有害なクライアントである場合もあるため、監視する必要もあります。 また、彼らを監視し、その活動を追跡する必要もあります。

クライアントがデータベースに接続すると、クライアントがデータの操作を開始することは明らかなので、クライアントがどのようにデータを操作するか、つまりどのテーブルを操作するか、また程度は低いですがどのインデックスを操作するかを監視する必要があります。 つまり、クライアントによって作成されるワークロードを評価する必要があります。

ただし、ワークロードには、当然のことながらリクエストも含まれます。 アプリケーションはデータベースに接続し、クエリを使用してデータにアクセスします。そのため、データベース内にどのようなクエリがあるかを評価し、その適切性を監視し、クエリが不正に記述されていないこと、より高速に動作するようにいくつかのオプションを書き換えて作成する必要があることを監視することが重要です。そしてより良いパフォーマンスで。

ここで話しているのはデータベースであるため、データベースは常にバックグラウンド プロセスです。 バックグラウンド プロセスはデータベースのパフォーマンスを良好なレベルに維持するのに役立つため、バックグラウンド プロセス自体が動作するには一定量のリソースが必要です。 同時に、それらはクライアント要求のリソースと重複する可能性があるため、貪欲なバックグラウンド プロセスがクライアント要求のパフォーマンスに直接影響を与える可能性があります。 したがって、バックグラウンドプロセスに関して歪みが生じないように、それらを監視および追跡する必要もあります。

データベース監視に関するこれらすべては、システム メトリックに残ります。 しかし、インフラストラクチャのほとんどがクラウドに移行していることを考えると、個々のホストのシステム メトリクスは常に背景に消えてしまいます。 しかし、データベースではそれらは依然として関連しており、当然、システム メトリクスを監視することも必要です。

システム メトリクスに関しては、多かれ少なかれすべてが問題ありません。最新の監視システムはすべてこれらのメトリクスをすでにサポートしていますが、一般に、いくつかのコンポーネントはまだ十分ではなく、追加する必要があるものもあります。 それらについてもいくつかのスライドで説明しますので、触れておきます。

計画の第一のポイントはアクセシビリティです。 アクセシビリティとは何ですか? 私の理解では、可用性とは、ベースからサービス接続への能力です。つまり、ベースが向上し、サービスとしてクライアントからの接続を受け入れます。 そして、このアクセシビリティは特定の特性によって評価できます。 これらの特性をダッシュ​​ボードに表示すると非常に便利です。

ダッシュボードが何であるかは誰もが知っています。 必要な情報がまとめられた画面を一目見たときのことです。 また、データベースに問題があるかどうかをすぐに判断できます。
したがって、データベースの可用性やその他の重要な特性は常にダッシュボードに表示され、この情報が手元にあり、いつでも利用できるようにする必要があります。 インシデントの調査に既に役立つ追加の詳細情報は、一部の緊急事態を調査する場合、すでにセカンダリ ダッシュボードに配置するか、サードパーティの監視システムにつながるドリルダウン リンクに非表示にする必要があります。

よく知られた監視システムの一例。 これは非常に優れた監視システムです。 彼女は多くのデータを収集していますが、私から見ると、彼女はダッシュボードという奇妙な概念を持っています。 「ダッシュボードを作成する」というリンクがあります。 ただし、ダッシュボードを作成するときは、XNUMX つの列のリスト、つまりグラフのリストを作成します。 そして、何かを見る必要があるときは、マウスをクリックしてスクロールし、目的のチャートを探し始めます。 そして、これには時間がかかります。つまり、ダッシュボード自体がありません。 チャートのリストのみがあります。

これらのダッシュボードに何を追加する必要がありますか? 応答時間などの特性から始めることができます。 PostgreSQL には pg_stat_statements ビューがあります。 デフォルトでは無効になっていますが、常に有効にして使用する必要がある重要なシステム ビューの XNUMX つです。 データベース内で実行されたすべての実行クエリに関する情報が保存されます。

したがって、すべてのリクエストの合計実行時間を取得し、上記のフィールドを使用してリクエストの数で割ることができるという事実から始めることができます。 しかし、これは病院内の平均体温です。 他のフィールド (最小クエリ実行時間、最大値、中央値) から開始することもできます。 また、パーセンタイルを構築することもできます。PostgreSQL にはこれに対応する関数があります。 そして、すでに完了したリクエストに対するデータベースの応答時間を特徴付けるいくつかの数値を取得できます。つまり、偽のリクエスト「select 1」を実行して応答時間を調べるのではなく、すでに完了したリクエストの応答時間を分析して描画します。別の図を作成するか、それに基づいてグラフを作成します。

現在システムによって生成されているエラーの数を監視することも重要です。 このために、pg_stat_database ビューを使用できます。 xact_rollback フィールドに注目します。 このフィールドには、データベース内で発生したロールバックの数だけでなく、エラーの数も考慮されます。 相対的に言えば、この数値をダッシュ​​ボードに表示して、現在発生しているエラーの数を確認できます。 エラーが多数ある場合は、ログを調べてエラーの種類と発生理由を確認し、それらを解決するために投資するのが良い理由になります。

タコメーターなどを追加することも可能です。 これらは、XNUMX 秒あたりのトランザクション数と XNUMX 秒あたりのリクエスト数です。 相対的に言えば、これらの数値をデータベースの現在のパフォーマンスとして使用し、リクエストにピークがあるかどうか、トランザクションにピークがあるかどうか、あるいは逆に、バックエンドの障害によりデータベースが過負荷になっているかどうかを観察できます。 常にこの図を見て、私たちのプロジェクトではこの種のパフォーマンスは正常ですが、上と下の値はすでにある種の問題があり、理解できないものであることを覚えておくことが重要です。つまり、これらの数値がなぜそうなるのかを検討する必要があることを意味します。非常に高い。

トランザクション数を見積もるために、再度 pg_stat_database ビューを参照します。 コミット数とロールバック数を加算して、XNUMX 秒あたりのトランザクション数を取得できます。

複数のリクエストが XNUMX つのトランザクションに収まることを皆さんは理解していますか? したがって、TPS と QPS は若干異なります。

XNUMX 秒あたりのリクエスト数は pg_stat_statements から取得でき、完了したすべてのリクエストの合計を単純に計算できます。 現在の値を前の値と比較し、それを減算し、デルタを取得し、数量を取得することは明らかです。

必要に応じて追加のメトリクスを追加できます。これは、データベースの可用性を評価し、ダウンタイムが発生したかどうかを監視するのにも役立ちます。

これらの指標の XNUMX つは稼働時間です。 ただし、PostgreSQL の稼働時間は少し注意が必要です。 その理由をお話します。 PostgreSQL が起動すると、稼働時間のレポートが開始されます。 しかし、ある時点で、たとえば、あるタスクが夜間に実行されていた場合、OOM キラーが来て、PostgreSQL の子プロセスを強制的に終了します。この場合、PostgreSQL はすべてのクライアントの接続を終了し、シャード化されたメモリ領域をリセットして、リカバリを開始します。最後のチェックポイント。 そして、このチェックポイントからの回復が続く間、データベースは接続を受け入れません。つまり、この状況はダウンタイムとして評価される可能性があります。 ただし、稼働時間カウンタはリセットされません。これは、最初の瞬間からポストマスターの起動時間が考慮されるためです。 したがって、そのような状況はスキップできます。

また、バキューム作業員の数も監視する必要があります。 みなさんはPostgreSQLの自動バキュームとは何か知っていますか? これは PostgreSQL の興味深いサブシステムです。 彼女については多くの記事が書かれ、多くの報告がなされています。 真空とそれがどのように機能するかについては、多くの議論があります。 多くの人はそれを必要悪だと考えています。 しかし、それがそのようです。 これは、トランザクションで必要のない古いバージョンの行をクリーンアップし、新しい行用にテーブルとインデックスのスペースを解放するガベージ コレクターの一種です。

なぜ監視する必要があるのでしょうか? 掃除機は時々とても痛いからです。 大量のリソースが消費され、その結果、クライアントのリクエストに影響が生じ始めます。

そして、それは pg_stat_activity ビューを通じて監視する必要があります。これについては次のセクションで説明します。 このビューには、データベース内の現在のアクティビティが表示されます。 そして、このアクティビティを通じて、現在稼働している掃除機の数を追跡することができます。 バキュームを追跡し、制限を超えている場合は、PostgreSQL の設定を調べてバキュームの操作を最適化する必要があることがわかります。

PostgreSQL に関するもう XNUMX つの点は、PostgreSQL は長いトランザクションに非常にうんざりしているということです。 特に、何もせずに長時間滞留するトランザクションの場合はそうです。 これはいわゆるトランザクション中のアイドル状態の統計です。 このようなトランザクションはロックを保持し、バキュームが機能しなくなります。 その結果、テーブルが膨張してサイズが大きくなります。 また、古いバージョンの行をすべてメモリからディスクに移動し、またメモリからディスクに戻す必要があるため、これらのテーブルを操作するクエリの動作が遅くなります。 したがって、最長トランザクションの時間、期間、最長バキューム要求も監視する必要があります。 また、非常に長時間実行されているプロセス (OLTP の負荷にすでに 10 ～ 20 ～ 30 分を超えている) が見つかった場合は、それらに注意を払って強制的に終了するか、アプリケーションを最適化して、は呼び出されず、それほど長くハングしません。 分析ワークロードの場合、10、20、30 分は通常ですが、それより長い場合もあります。

次に、接続されたクライアントを使用するオプションがあります。 すでにダッシュボードを作成し、そこに主要な可用性メトリックを投稿している場合は、接続されているクライアントに関する追加情報をそこに追加することもできます。

PostgreSQL の観点から見ると、クライアントは異なるため、接続されたクライアントに関する情報は重要です。 良いクライアントもいれば悪いクライアントもいます。

簡単な例です。 クライアントによるアプリケーションの理解。 アプリケーションはデータベースに接続し、すぐにリクエストの送信を開始します。データベースはリクエストを処理して実行し、結果をクライアントに返します。 これらは善良で正しいクライアントです。

クライアントが接続し、接続は保持しているが何もしない状況があります。 アイドル状態です。

しかし、悪いクライアントもいます。 たとえば、同じクライアントが接続し、トランザクションを開き、データベース内で何かを実行した後、コードに入り、たとえば外部ソースにアクセスしたり、そこで受信したデータを処理したりします。 しかし、彼は取引を成立させなかった。 そして、トランザクションはデータベース内でハングし、回線上のロックに保持されます。 これは悪い状態です。 また、アプリケーション内部のどこかで突然例外が発生して障害が発生した場合、トランザクションは非常に長い間開いたままになる可能性があります。 そして、これは PostgreSQL のパフォーマンスに直接影響します。 PostgreSQL は遅くなります。 したがって、そのようなクライアントをタイムリーに追跡し、作業を強制的に終了することが重要です。 そして、そのような状況が起こらないようにアプリケーションを最適化する必要があります。

他の悪いクライアントは待機中のクライアントです。 しかし、それらは状況によって悪くなります。 たとえば、単純なアイドル トランザクションです。トランザクションを開いていくつかの行をロックすると、コードのどこかで失敗し、トランザクションがハングしたままになります。 別のクライアントが来て同じデータを要求しますが、そのハングしたトランザクションがすでに必要な行のロックを保持しているため、ロックが発生します。 そして XNUMX 番目のトランザクションは、最初のトランザクションが完了するまで待機するか、管理者によって強制的に閉じられます。 したがって、保留中のトランザクションが蓄積され、データベース接続制限を超える可能性があります。 そして、制限がいっぱいになると、アプリケーションはデータベースを操作できなくなります。 これはプロジェクトにとってすでに緊急事態です。 したがって、悪質なクライアントを追跡し、タイムリーに対応する必要があります。

モニタリングの別の例。 そして、ここにはすでにまともなダッシュボードがあります。 上記に接続に関する情報があります。 DB接続 – 8個。 そしてそれだけです。 どのクライアントがアクティブで、どのクライアントがアイドル状態で何もしていないのかについての情報はありません。 保留中のトランザクションや保留中の接続に関する情報はありません。つまり、これは接続数を示す図であり、それだけです。 そして、自分で推測してください。

したがって、この情報を監視に追加するには、pg_stat_activity システム ビューにアクセスする必要があります。 PostgreSQL に多くの時間を費やしている場合、これは非常に優れたビューであり、PostgreSQL での現在のアクティビティ、つまり PostgreSQL で何が起こっているかが表示されるため、非常に便利です。 プロセスごとに、このプロセスに関する情報を示す個別の行があります。つまり、接続が行われたホスト、ユーザー、名前、トランザクションの開始日、現在実行中のリクエスト、最後に実行されたリクエストです。 したがって、stat フィールドを使用してクライアントの状態を評価できます。 相対的に言えば、このフィールドでグループ化し、現在データベースにある統計と、データベースにこの統計がある接続の数を取得できます。 そして、すでに受信した数値をモニタリングに送信し、それらに基づいてグラフを描画することができます。
トランザクションの期間を評価することも重要です。 バキュームの期間を評価することが重要であるとすでに述べましたが、トランザクションも同様に評価されます。 xact_start フィールドと query_start フィールドがあります。 これらは、相対的に、トランザクションの開始時間とリクエストの開始時間を示します。 現在のタイムスタンプを表示する now() 関数を使用し、トランザクションとリクエストのタイムスタンプを減算します。 そして、トランザクションの期間、つまりリクエストの期間を取得します。

長いトランザクションが見つかった場合は、すでに完了している必要があります。 OLTP ロードの場合、長いトランザクションはすでに 1、2、3 分を超えています. OLAP ワークロードの場合、トランザクションが長いのは正常ですが、完了までに XNUMX 時間以上かかる場合は、どこかにスキューがあることを示しています。

クライアントがデータベースに接続すると、データの操作が開始されます。 彼らはテーブルにアクセスし、インデックスにアクセスしてテーブルからデータを取得します。 そして、クライアントがこのデータをどのように扱うかを評価することが重要です。

これは、ワークロードを評価し、どのテーブルが最も「ホット」であるかを大まかに理解するために必要です。 たとえば、これは、ある種の高速 SSD ストレージに「ホット」テーブルを配置したい状況で必要になります。 たとえば、長期間使用していないアーカイブ テーブルを、ある種の「コールド」アーカイブ、つまり SATA ドライブに移動し、そこに常駐させておくと、必要に応じてアクセスできるようになります。

これは、リリースや展開後の異常の検出にも役立ちます。 プロジェクトが何らかの新機能をリリースしたとします。 たとえば、データベースを操作するための新しい機能を追加しました。 また、テーブルの使用状況グラフをプロットすると、これらのグラフ上の異常を簡単に検出できます。 たとえば、バーストを更新したり、バーストを削除したりします。 とても目立つでしょう。

「変動」統計の異常を検出することもできます。 それはどういう意味ですか？ PostgreSQL には、非常に強力で優れたクエリ プランナーが備わっています。 そして開発者はその開発に多くの時間を費やしています。 彼はどうやって働いているのですか？ 適切な計画を立てるために、PostgreSQL はテーブル内のデータの分布に関する統計を特定の時間間隔と頻度で収集します。 これらは最も一般的な値です。一意の値の数、テーブル内の NULL に関する情報、多くの情報です。

これらの統計に基づいて、プランナーはいくつかのクエリを構築し、最も最適なものを選択し、このクエリ プランを使用してクエリ自体を実行し、データを返します。

そして、統計が「浮く」ことが起こります。 テーブル内の質と量のデータが何らかの理由で変更されましたが、統計は収集されませんでした。 そして、策定された計画が最適ではない可能性もあります。 そして、テーブルに基づいて収集されたモニタリングに基づいて計画が最適ではないことが判明した場合、これらの異常を確認できるようになります。 たとえば、どこかでデータが質的に変化し、インデックスの代わりにテーブルを介したシーケンシャル パスが使用され始めました。 クエリが 100 行のみを返す必要がある場合 (100 行という制限があります)、このクエリに対して完全な検索が実行されます。 そして、これは常にパフォーマンスに非常に悪い影響を与えます。

これはモニタリングでも確認できます。 そして、すでにこのクエリを確認し、Explain を実行し、統計を収集し、新しい追加のインデックスを構築します。 そしてすでにこの問題に対応しています。 だからこそ重要なのです。

モニタリングの別の例。 とても人気があるので知っている人も多いと思います。 プロジェクトでそれを使用する人 プロメテウス? この製品を Prometheus と組み合わせて使用​​するのは誰ですか? 実際、この監視の標準リポジトリには、PostgreSQL を操作するためのダッシュボードがあります。 postgres_exporter プロメテウス。 しかし、悪い点が XNUMX つあります。

いくつかのグラフがあります。 そしてバイトは 5 として示されます。つまり、XNUMX つのグラフがあります。 これらは、データの挿入、データの更新、データの削除、データのフェッチ、データの返却です。 単位はバイトです。 しかし、問題は、PostgreSQL の統計はデータをタプル (行) で返すということです。 したがって、タプルはバイトではなく文字列であり、多くのバイトがあり、常に可変長であるため、これらのグラフはワークロードを数倍、数十倍過小評価する非常に良い方法となります。 つまり、タプルを使用してワークロードをバイト単位で計算することは非現実的なタスクであるか、非常に困難です。 したがって、ダッシュボードまたは組み込みの監視を使用する場合は、それが正しく動作し、正しく評価されたデータが返されることを理解することが常に重要です。

これらのテーブルの統計を取得するにはどうすればよいでしょうか? この目的のために、PostgreSQL には特定のビューのファミリーがあります。 そして主な視点は、 pg_stat_user_tables。 User_tables - ユーザーに代わって作成されたテーブルを意味します。 対照的に、PostgreSQL 自体によって使用されるシステム ビューがあります。 また、システムとユーザーの両方を含むサマリー テーブル Alltables があります。 その中で最も気に入ったものから始めることができます。

上記のフィールドを使用すると、挿入、更新、削除の数を推定できます。 私が使用したダッシュボードの例では、これらのフィールドを使用してワークロードの特性を評価しています。 したがって、それらを基にして構築することもできます。 ただし、これらはバイトではなくタプルであるため、バイト単位で実行することはできないことを覚えておく価値があります。

このデータに基づいて、いわゆる TopN テーブルを構築できます。 たとえば、トップ 5、トップ 10 などです。 また、他のテーブルよりも多くリサイクルされているホット テーブルを追跡できます。 たとえば、5 つの「ホット」テーブルを挿入します。 これらの TopN テーブルを使用してワークロードを評価し、リリース、更新、展開後のワークロードのバーストを評価できます。

テーブルのサイズを評価することも重要です。開発者が新しい機能を展開すると、追加のデータ量を追加することを決定したが、それがどのようになるかを予測していなかったために、テーブルのサイズが大きくなり始めることがあるためです。データベースのサイズに影響します。 このようなケースは私たちにとっても驚きです。

それでは、ちょっとした質問です。 データベース サーバーの負荷に気づいたとき、どのような疑問が生じますか? 次の質問は何ですか?

しかし実際には次のような疑問が生じます。 負荷によってどのようなリクエストが発生しますか? つまり、負荷によって引き起こされるプロセスを観察することは面白くありません。 ホストにデータベースがある場合、そのデータベースはそこで実行されており、データベースのみがそこで破棄されることは明らかです。 「トップ」を開くと、PostgreSQL で何かを実行しているプロセスのリストが表示されます。 彼らが何をしているのかはトップからは明らかではありません。

したがって、最も高い負荷を引き起こすクエリを見つける必要があります。これは、クエリのチューニングは、一般に、PostgreSQL やオペレーティング システムの構成をチューニングしたり、ハードウェアをチューニングしたりするよりも大きな利益が得られるためです。 私の推定によると、これは約 80-85-90% です。 そして、これははるかに高速に実行されます。 特にデータベースを再起動できない場合は、構成を修正したり、再起動をスケジュールしたり、ハードウェアを追加したりするよりも、要求を修正する方が高速です。 このクエリからより良い結果を得るには、クエリをどこかに書き直すか、インデックスを追加する方が簡単です。

したがって、要求とその適切性を監視する必要があります。 モニタリングの別の例を見てみましょう。 そしてここでも優れた監視が行われているようです。 レプリケーションに関する情報、スループット、ブロッキング、リソース使用率に関する情報があります。 すべて問題ありませんが、リクエストに関する情報はありません。 データベース内でどのようなクエリが実行されているのか、実行時間、クエリの数は不明です。 モニタリングでは常にこの情報が必要です。

この情報を取得するには、pg_stat_statements モジュールを使用します。 これに基づいて、さまざまなグラフを作成できます。 たとえば、最も頻繁に実行されるクエリ、つまり最も頻繁に実行されるクエリに関する情報を取得できます。 はい、デプロイ後にそれを見て、リクエストが急増しているかどうかを理解することも非常に役立ちます。

最長のクエリ、つまり完了までに最も時間がかかるクエリを監視できます。 これらはプロセッサ上で実行され、I/O を消費します。 total_time、mean_time、blk_write_time、blk_read_time フィールドを使用してこれを評価することもできます。

リソース使用量の観点から最も重いリクエスト、ディスクから読み取るリクエスト、メモリを操作するリクエスト、または逆に何らかの書き込み負荷を引き起こすリクエストを評価および監視できます。

最も寛大なリクエストを評価することができます。 これらは、大量の行を返すクエリです。 たとえば、制限の設定を忘れたリクエストが考えられます。 そして、クエリされたテーブル全体でテーブルまたはクエリの内容全体を返すだけです。

また、一時ファイルまたは一時テーブルを使用するクエリを監視することもできます。

そしてバックグラウンドプロセスもまだあります。 バックグラウンド プロセスは主にチェックポイント、またはチェックポイントとも呼ばれ、自動バキュームとレプリケーションです。

モニタリングの別の例。 左側に [メンテナンス] タブがあるので、そこに移動すると、役立つものが表示されることを期待します。 しかし、ここではバキューム操作と統計収集の時間だけがあり、それ以上のことはありません。 これは非常に貧弱な情報なので、バックグラウンド プロセスがデータベース内でどのように動作するか、またその動作によって問題が発生するかどうかについての情報を常に入手する必要があります。

チェックポイントを見るときは、チェックポイントがダーティ ページをシャード メモリ領域からディスクにフラッシュしてから、チェックポイントを作成することを覚えておく必要があります。 そして、このチェックポイントは、緊急時に PostgreSQL が突然終了した場合の回復の場所として使用できます。

したがって、すべての「ダーティ」ページをディスクにフラッシュするには、ある程度の量の書き込みを行う必要があります。 そして、一般に、大量のメモリを搭載したシステムでは、これは大量になります。 また、チェックポイントを短い間隔で頻繁に実行すると、ディスクのパフォーマンスが大幅に低下します。 そして、クライアントのリクエストはリソース不足によって困難になります。 彼らはリソースをめぐって競争し、生産性が欠如します。

したがって、指定されたフィールドを使用する pg_stat_bgwriter を通じて、発生するチェックポイントの数を監視できます。 また、特定の期間 (10、15、20 分、または 3 分) に多数のチェックポイントがある場合 (たとえば、4-5-XNUMX)、これはすでに問題になる可能性があります。 そして、データベースと構成を調べて、何がこのような大量のチェックポイントの原因となっているのかを調べる必要があります。 もしかしたら大規模なレコーディングが行われているのかもしれない。 すでにワークロード グラフを追加しているため、ワークロードを評価することができます。 すでにチェックポイント パラメーターを微調整して、クエリのパフォーマンスに大きな影響を与えないことを確認できます。

自動バキュームに再び戻ります。なぜなら、前述したように、自動バキュームはディスクとクエリの両方のパフォーマンスを簡単に加算できるためです。そのため、自動バキュームの量を見積もることは常に重要です。

データベース内の自動バキューム ワーカーの数は制限されています。 デフォルトでは XNUMX つのワーカーが存在するため、データベース内で常に XNUMX 人のワーカーが作業している場合、これは自動バキュームが構成されていないことを意味するため、制限を引き上げ、自動バキューム設定を修正して構成を開始する必要があります。
どの掃除機作業員がいるかを評価することが重要です。 ユーザーが起動したか、DBA が来て手動で何らかのバキュームを起動したため、負荷が発生しました。 何らかの問題が発生しています。 または、これはトランザクションカウンターのネジを外す掃除機の数です。 PostgreSQL の一部のバージョンでは、これらは非常に重いバキュームになります。 また、テーブル全体を読み取り、そのテーブル内のすべてのブロックをスキャンするため、パフォーマンスを簡単に加算できます。

そしてもちろん、掃除機の持続時間もです。 非常に長時間稼働する長持ちする掃除機がある場合、これは再び掃除機の構成に注意を払い、おそらくその設定を再検討する必要があることを意味します。 テーブル上でバキュームが長時間 (3 ～ 4 時間) 実行されると、状況が発生する可能性がありますが、バキュームが動作している間に、大量のデッド行が再びテーブルに蓄積されてしまうためです。 そして、掃除機が完了したらすぐに、もう一度このテーブルに掃除機をかける必要があります。 そして私たちは、無限の真空状態という状況に到達します。 そしてこの場合、バキュームはその仕事に対応できず、テーブル内の有用なデータの量は同じままですが、テーブルのサイズが徐々に大きくなり始めます。 したがって、長いバキューム中は、常に構成を確認して最適化を試みますが、同時に、クライアント要求のパフォーマンスが低下しないようにします。

現在、ストリーミング レプリケーションを備えていない PostgreSQL インストールは事実上ありません。 レプリケーションは、マスターからレプリカにデータを移動するプロセスです。

PostgreSQL のレプリケーションはトランザクション ログを通じて行われます。 ウィザードはトランザクション ログを生成します。 トランザクション ログはネットワーク接続を介してレプリカに送信され、レプリカ上で複製されます。 それは簡単です。

したがって、レプリケーションラグを監視するには、pg_stat_replication ビューが使用されます。 しかし、彼女にとってすべてが単純なわけではありません。 バージョン 10 では、ビューにいくつかの変更が加えられました。 まず、いくつかのフィールドの名前が変更されました。 いくつかのフィールドが追加されました。 バージョン 10 では、レプリケーションの遅延を秒単位で推定できるフィールドが表示されました。 とても快適です。 バージョン 10 より前では、レプリケーション ラグをバイト単位で見積もることができました。 このオプションはバージョン 10 にも残ります。つまり、ラグをバイト単位で推定するか、ラグを秒単位で推定するか、都合のよい方を選択できます。 多くの人は両方を行っています。

ただし、レプリケーションの遅延を評価するには、トランザクション内のログの位置を知る必要があります。 これらのトランザクション ログの位置は、正確に pg_stat_replication ビュー内にあります。 相対的に言えば、pg_xlog_location_diff() 関数を使用して、トランザクション ログ内の XNUMX つのポイントを取得できます。 それらの間の差分を計算し、レプリケーション ラグをバイト単位で取得します。 とても便利でシンプルです。

バージョン 10 では、この関数の名前が pg_wal_lsn_diff() に変更されました。 一般に、「xlog」という単語が出現するすべての関数、ビュー、ユーティリティでは、値「wal」に置き換えられました。 これはビューと関数の両方に当てはまります。 これはまさにイノベーションです。

さらに、バージョン 10 では、ラグを具体的に示す行が追加されました。 これらは、書き込みラグ、フラッシュ ラグ、リプレイ ラグです。 つまり、これらを監視することが重要です。 レプリケーションに遅延があることがわかった場合は、その遅延が発生した理由と発生場所を調査し、問題を解決する必要があります。

システムメトリクスに関しては、ほぼすべてが正常に行われています。 監視が開始されるときは、システム メトリックから始まります。 これは、プロセッサ、メモリ、スワップ、ネットワーク、ディスクの廃棄です。 ただし、多くのパラメータはデフォルトでは存在しません。

リサイクル プロセスがすべて順調であれば、ディスクのリサイクルに問題があります。 通常、監視開発者はスループットに関する情報を追加します。 iops またはバイト単位で指定できます。 しかし、彼らはレイテンシーとディスクデバイスの使用率を忘れています。 これらは、ディスクの負荷と速度を評価できる、より重要なパラメータです。 遅延が長い場合は、ディスクに何らかの問題があることを意味します。 使用率が高い場合は、ディスクが対応していないことを意味します。 これらはスループットよりも優れた特性です。

さらに、これらの統計は、プロセッサのリサイクルと同様に、/proc ファイル システムからも取得できます。 なぜこの情報が監視に追加されないのかわかりません。 しかし、それにもかかわらず、これをモニタリングに含めることは重要です。

ネットワークインターフェースにも同じことが当てはまります。 パケット単位やバイト単位のネットワーク スループットに関する情報はありますが、待ち時間や使用率に関する情報はありません。これも有益な情報ではありますが、

どのような監視にも欠点はあります。 そして、どのような種類のモニタリングを行っても、常に何らかの基準を満たさないことがあります。 それでも、開発は進んでおり、新しい機能や新しいものが追加されているので、何かを選択して完了してください。

そして、完了するには、提供される統計が何を意味するのか、そしてそれらを問​​題解決にどのように使用できるのかを常に理解しておく必要があります。

そしていくつかの重要なポイント:

• 可用性を常に監視し、データベースですべてが正常であることをすぐに評価できるようにダッシュボードを用意する必要があります。
• 悪いクライアントを排除して撃墜するには、どのクライアントがデータベースを操作しているかを常に把握する必要があります。
• これらのクライアントがデータをどのように扱うかを評価することが重要です。 自分のワークロードについてのアイデアを持っておく必要があります。
• どのようなクエリを使用して、このワークロードがどのように形成されるかを評価することが重要です。 クエリを評価し、最適化し、リファクタリングし、インデックスを構築することができます。 それは非常に重要です。
• バックグラウンド プロセスはクライアントのリクエストに悪影響を与える可能性があるため、リソースの使用量が多すぎないことを監視することが重要です。
• システム メトリクスを使用すると、サーバーのスケーリングと容量の増加に関する計画を立てることができるため、システム メトリクスを追跡して評価することも重要です。

このトピックに興味がある場合は、次のリンクを参照してください。
http://bit.do/stats_collector - これは統計コレクターによる公式ドキュメントです。 すべての統計ビューとすべてのフィールドの説明があります。 それらを読んで理解して分析することができます。 そしてそれらに基づいてグラフを作成し、モニタリングに追加します。

リクエストの例：
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

これは私たちの企業リポジトリであり、私自身のリポジトリです。 クエリの例が含まれています。 そこには select* from シリーズからのクエリはありません。 結合を備えた既製のクエリがすでに存在しており、生の数値を読み取り可能な便利な値 (バイトや時間など) に変換できる興味深い関数を使用しています。 それらを拾い上げ、観察し、分析し、モニタリングに追加し、それらに基づいてモニタリングを構築することができます。

質問

質問: ブランドの宣伝はしないとおっしゃいましたが、それでも気になります。プロジェクトではどのようなダッシュボードを使用していますか?
回答: それは異なります。 私たちが顧客のところに行くと、その顧客はすでに独自のモニタリングを行っていることがあります。 そして、監視に何を追加する必要があるかについてお客様にアドバイスします。 最悪の状況はZabbixの場合です。 TopN グラフを構築する機能がないためです。 私たち自身も使っています オクメーター、監視についてこの人たちと相談していたからです。 彼らは、当社の技術仕様に基づいて PostgreSQL を監視しました。 私は、Prometheus 経由でデータを収集し、それをレンダリングする独自のペット プロジェクトを作成しています。 グラファナ。 私のタスクは、Prometheus で独自のエクスポーターを作成し、すべてを Grafana でレンダリングすることです。

質問: AWR レポートや集計に類似したものはありますか? このようなことについてご存知ですか？
回答: はい、AWR が何であるかは知っています。素晴らしいものです。 現時点では、ほぼ次のモデルを実装したさまざまな自転車があります。 一定の間隔で、いくつかのベースラインが同じ PostgreSQL または別のストレージに書き込まれます。 インターネットでグーグルで検索すると、そこにあります。 このようなものの開発者の XNUMX 人は、PostgreSQL スレッドの sql.ru フォーラムに参加しています。 そこで彼を捕まえることができます。 はい、そういうものもあります、使えます。 さらにその中に pgCenter 同じようなことができるようにする記事も書いています。

PS1 postgres_exporter を使用している場合、どのダッシュボードを使用していますか? それらはいくつかあります。 それらはすでに時代遅れです。 おそらくコミュニティが更新されたテンプレートを作成するでしょうか?

PS2 pganalyze は、パフォーマンスの監視と自動チューニングの提案に重点を置いた独自の SaaS 製品であるため、削除されました。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

どの自己ホスト型 postgresql モニタリング (ダッシュボード付き) が最適だと思いますか?

• 視聴者の３８%がZabbix + Alexey Lesovsky からの追加、zabbix 4.4、または libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 視聴者の３８%がhttps://github.com/lesovsky/pgcenter0

• 視聴者の３８%がhttps://github.com/pg-monz/pg_monz0

• 視聴者の３８%がhttps://github.com/cybertec-postgresql/pgwatch22

• 視聴者の３８%がhttps://github.com/postgrespro/mamonsu2

• 視聴者の３８%がhttps://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 視聴者の３８%がpganalyze は独自の SaaS - 削除できません1

• 視聴者の３８%がhttps://github.com/powa-team/powa1

• 視聴者の３８%がhttps://github.com/darold/pgbadger0

• 視聴者の３８%がhttps://github.com/darold/pgcluu0

• 視聴者の３８%がhttps://github.com/zalando/PGObserver0

• 視聴者の３８%がhttps://github.com/spotify/postgresql-metrics1

10 人のユーザーが投票しました。 26名のユーザーが棄権した。

出所： habr.com