PostgreSQL をチューニングするための産業的アプローチ: データベースを使った実験。」 ニコライ・サモクバロフ

Nikolai Samokhvalov 氏のレポート「PostgreSQL のチューニングに対する業界のアプローチ: データベースの実験」の転写を読むことをお勧めします。

Shared_buffers = 25% – それは多いですか、それとも少ないですか? それともちょうどいいですか？ この (かなり時代遅れの) 推奨事項があなたの特定のケースに適切かどうかをどうやって判断するのでしょうか?

postgresql.conf パラメータを「大人のように」選択する問題に取り組む時が来ました。 盲目的な「自動チューナー」や記事やブログからの時代遅れのアドバイスの助けを借りずに、次のことに基づいています。

1. データベース上で厳密に検証された実験は、「戦闘」実験にできるだけ近い条件下で自動的に大量に実行され、
2. DBMSやOSの機能を深く理解する。

Nancy CLI の使用 (https://gitlab.com/postgres.ai/nancy)、さまざまな状況、さまざまなプロジェクトで、特定の例である悪名高いshared_buffersを見て、インフラストラクチャ、データベース、負荷に最適な設定を選択する方法を見つけていきます。

データベースを使った実験についてお話します。 これは半年ほど続く物語です。

私のことを少し。 Postgres を 14 年以上使用した経験。 多くのソーシャルネットワーキング企業が設立されました。 Postgres は今も昔もあらゆる場所で使用されています。

Meetup の RuPostgres グループも世界 2 位です。 徐々に2人に近づいてきました。 RuPostgres.org。

そして、Highload を含むさまざまなカンファレンスの PC では、最初からデータベース、特に Postgres を担当しています。

そしてここ数年、私はここから 11 のタイムゾーンで Postgres コンサルティングの実践を再開しました。

そして、数年前にこれを行ったとき、おそらく 2010 年以来、Postgres を使用したアクティブな手動作業からしばらく中断していました。 DBA の作業ルーチンがほとんど変わっていないこと、そして依然として多くの手作業が必要であることに驚きました。 そしてすぐに、ここで何かが間違っている、すべてをもっと自動化する必要があると思いました。

また、すべてリモートであったため、クライアントのほとんどはクラウド上にありました。 そして明らかに、多くのことはすでに自動化されています。 これについては後で詳しく説明します。 つまり、これらすべての結果として、多数のツール、つまり、多数のデータベースを管理できるように、ほとんどすべての DBA アクションを自動化するある種のプラットフォームが必要であるという考えが生まれました。

このレポートには以下は含まれません。

• 「特効薬」と次のようなステートメント - 8 GB または 25% のshared_buffers を設定すれば問題ありません。 共有バッファについてはあまり説明しません。
• ハードコアの「内臓」。

どうなるの？

• 私たちが適用し開発する最適化原則があります。 その過程であらゆる種類のアイデアが生まれ、さまざまなツールがほとんどオープンソースで作成されます。つまり、オープンソースで基礎を作ります。 さらに、チケットもあり、すべてのコミュニケーションは事実上オープンソースです。 私たちが現在行っていること、次のリリースで何が行われるかなどを確認できます。
• また、小規模な新興企業から大企業まで、多くの企業でこれらの原則やツールを使用した経験も必要です。

これはどのように発展しているのでしょうか？

まず、DBA の主なタスクは、インスタンスの作成やバックアップの展開などを確実に行うことに加えて、ボトルネックを見つけてパフォーマンスを最適化することです。

今はこんな感じで設置されています。 モニタリングを見ると何かが見えますが、詳細がいくつか欠けています。 私たちは、通常は手でより慎重に掘り始め、何らかの方法でそれをどうすればよいかを理解します。

そして、アプローチはXNUMXつあります。 Pg_stat_statements は、遅いクエリを識別するためのデフォルトのソリューションです。 そして、pgBadgerを使用したPostgresログの分析。

どのアプローチにも重大な欠点があります。 最初のアプローチでは、すべてのパラメータを破棄しました。 そして、列が「?」に等しいグループ SELECT * FROM テーブルを見ると、 Postgres 10 以降は「$」です。これがインデックス スキャンなのかシーケンス スキャンなのかはわかりません。 それはパラメータに大きく依存します。 そこにまれに出現する値を代入すると、インデックス スキャンになります。 そこにテーブルの 90% を占める値を代入すると、Postgres は統計情報を認識しているため、シーケンス スキャンが明らかになります。 いくつかの作業が進行中ですが、これは pg_stat_statements の大きな欠点です。

ログ分析の最大の欠点は、原則として「log_min_duration_statement = 0」を許容できないことです。 そして、これについても話します。 したがって、全体像は見えません。 また、非常に高速な一部のクエリは大量のリソースを消費する可能性がありますが、しきい値を下回っているため表示されません。

DBA は見つけた問題をどのように解決しますか?

たとえば、ある問題が見つかりました。 通常は何が行われますか? あなたが開発者であれば、同じサイズではないインスタンスで何かを行うことになるでしょう。 DBA であれば、ステージングがあります。 そして、それは XNUMX つだけです。 そして彼はXNUMXか月遅れていました。 そして本番に進むと思います。 さらに、経験豊富な DBA であっても、本番環境のレプリカでチェックインします。 そして、一時的なインデックスを作成し、それが役立つことを確認して削除し、移行ファイルに入れることができるように開発者に渡すことが起こります。 これは今起こっている一種のナンセンスです。 そして、これは問題です。

• 構成を調整します。
• インデックスのセットを最適化します。
• SQL クエリ自体を変更します (これは最も困難な方法です)。
• 容量を追加します (ほとんどの場合、最も簡単な方法)。

これらについては多くのことが起こっています。 Postgres にはハンドルがたくさんあります。 知るべきことがたくさんあります。 このカンファレンスの主催者のおかげでもあり、Postgres には多くのインデックスがあります。 そして、これらすべてを知っておく必要があり、これが非 DBA が黒魔術を実践しているように感じる原因です。 つまり、これらすべてを普通に理解できるようになるには、10年間勉強する必要があります。

そして私はこの黒魔術と戦う戦士です。 私はテクノロジーが存在するようにすべてをやりたいと思っていますが、これらすべてに直感はありません。

人生の例

私自身のプロジェクトを含め、少なくとも 1 つのプロジェクトでこれを観察しました。 別のブログ投稿では、default_statistict_target の値は 000 が適切であると述べています。 さて、本番環境で試してみましょう。

そして、XNUMX 年後、私たちは今日話しているデータベースの実験の助けを借りて、私たちのツールを使用して、かつてのものと現在どうなったかを比較できるようになりました。

このためには実験を作成する必要があります。 XNUMX つの部分から構成されます。

• XNUMXつ目は環境です。 ハードウェアが必要です。 そして、私がどこかの会社に来て契約を結ぶときは、本番環境と同じハードウェアを提供するように言います。 あなたのマスターごとに、このようなハードウェアが少なくとも XNUMX つ必要です。 これは Amazon または Google のインスタンス仮想マシンであるか、まったく同じハードウェアが必要です。 つまり、環境を再構築したいのです。 そして、環境の概念には、Postgres のメジャー バージョンが含まれます。
• XNUMX 番目の部分が私たちの研究の対象です。 これはデータベースです。 いくつかの方法で作成できます。 その方法を説明します。
• XNUMX 番目の部分は負荷です。 これが最も難しい瞬間です。
• そして XNUMX 番目の部分は何をチェックするか、つまり何を何と比較するかです。 構成内の XNUMX つ以上のパラメータを変更したり、インデックスを作成したりできるとします。

私たちは実験を開始しています。 これが pg_stat_statements です。 左側は何が起こったのかです。 右側 - 何が起こったのか。

左側では、default_statistics_target = 100、右側では =1 これが役に立ったことがわかります。 全体として、すべてが 000% 改善されました。

しかし、下にスクロールすると、pgBadger または pg_stat_statements からのリクエストのグループが表示されます。 選択肢は 88 つあります。 一部のリクエストが XNUMX% 減少したことがわかります。 ここでエンジニアリングのアプローチが登場します。 なぜ沈んだのか疑問に思うので、さらに内部を掘り下げることができます。 統計で何が起こったのかを理解する必要があります。 統計のバケットが増えると結果が悪くなる理由。

または、掘ることはできませんが、「ALTER TABLE ... ALTER COLUMN」を実行して、この列の統計に 100 バケットを返します。 そして、別の実験を行って、このパッチが役に立ったことを確認します。 全て。 これは、直感ではなくデータに基づいて全体像を把握し、意思決定を行うのに役立つエンジニアリング アプローチです。

他の分野の例をいくつか。 テストでは長年にわたりCIテストが行​​われてきました。 そして、正しい考えを持っているプロジェクトは、自動テストなしでは存続しません。

他の業界、つまり航空業界や自動車業界では、空気力学をテストするときに実験を行う機会もあります。 私たちは、図面から何かを直接宇宙に打ち上げたり、すぐに車をトラックに乗せたりしません。 たとえば、風洞があります。

他の業界の観察から結論を導き出すことができます。

まず、私たちには特別な環境があります。 本番に近づいていますが、それに近いわけではありません。 その主な特徴は、安価で再現性があり、可能な限り自動化されている必要があることです。 また、詳細な分析を行うための特別なツールも必要です。

おそらく、飛行機を打ち上げて飛行するとき、翼の表面を XNUMX ミリメートル単位で研究する機会は、風洞実験よりも少ないでしょう。 さらに多くの診断ツールがあります。 私たちは空の飛行機に乗せることができないような、より重い荷物を運ぶ余裕があります。 Postgresも同様です。 場合によっては、実験中に完全なクエリ ログを有効にすることがあります。 そして、本番環境ではこれを行いたくありません。 auto_explain を使用してこれを有効にすることも計画しているかもしれません。

先ほども述べたように、高度な自動化とは、ボタンを押して繰り返すことを意味します。 これは、多くの実験が行われ、配信されるようになるためです。

Nancy CLI - 「データベース研究所」の基礎

そこで私たちはこのことを行いました。 つまり、私はほぼ XNUMX 年前の XNUMX 月にこれらのアイデアについて話しました。 そして、いわゆる Nancy CLI がすでにオープンソースで提供されています。 これはデータベースラボを構築するための基礎です。

ナンシー — Gitlab 上のオープンソースです。 言ってもいいし、試してみてもいい。 スライド内にリンクを記載しました。 それをクリックするとそこに表示されます 助けます あらゆる点で。

もちろん、まだ開発中のものもたくさんあります。 そこにはたくさんのアイデアがあります。 しかし、これは私たちがほぼ毎日使用しているものです。 そして、アイデアがあれば、40 行を削除すると、すべてが IO に帰着するのはなぜでしょうか。その後、実験を実施して詳細を調べて何が起こっているのかを理解し、外出先で修正を試みることができます。 つまり、実験を行っているのです。 たとえば、何かを微調整して、最終的に何が起こるかを確認します。 そして、本番環境ではこれを行いません。 これがアイデアの本質です。

これはどこで機能しますか? これはローカルで動作します。つまり、どこでも実行でき、MacBook 上でも実行できます。 港湾労働者が必要です、行きましょう。 それだけです。 ハードウェア上の一部のインスタンスまたは仮想マシン上で、どこにでも実行できます。

また、EC2 インスタンスの Amazon でスポット的にリモートで実行する機会もあります。 そして、これはとても素晴らしい機会です。 たとえば、昨日、私たちは i500 インスタンスで最も若いものから始めて i3-3-xlarge までの 16 以上の実験を実施しました。 500 回の実験には 64 ドルかかりました。 それぞれ15分間続きました。 つまり、そこではスポットが使用されているため、非常に安くなります - 70% 割引、Amazon の秒単位の請求です。 たくさんのことができます。 本格的な研究ができます。

また、Postgres の 12 つのメジャー バージョンがサポートされています。 いくつかの古いバージョンと新しい第 XNUMX バージョンを完成させるのはそれほど難しくありません。

オブジェクトは XNUMX つの方法で定義できます。 これ：

• ダンプ/SQL ファイル。
• 主な方法は、PGDATA ディレクトリのクローンを作成することです。 原則として、バックアップサーバーから取得されます。 通常のバイナリ バックアップがある場合は、そこからクローンを作成できます。 クラウドを使用している場合は、Amazon や Google などのクラウド オフィスがこれを行ってくれます。 これは、実際のプロダクションのクローンを作成する最も重要な方法です。 このようにして展開していきます。
• 最後の方法は、Postgres で何かがどのように動作するかを理解したい場合の研究に適しています。 これはpgベンチです。 pgbenchを使用して生成できます。 これは「db-pgbench」オプションの XNUMX つです。 あなたは彼にスケールを伝えます。 そして、前述したように、すべてはクラウドで生成されます。

そしてロードします:

• ロードは XNUMX つの SQL スレッドで実行できます。 これは最も原始的な方法です。
• そして、負荷をエミュレートすることができます。 そして、まず次の方法でそれをエミュレートできます。 すべてのログを収集する必要があります。 そして、それは痛いです。 その理由を説明します。 そして、Nancy に組み込まれている pgreplay を使用してプレイします。
• または別のオプション。 いわゆるクラフトロードで、ある程度の労力をかけて行います。 戦闘システムの現在の負荷を分析し、リクエストの上位グループを抽出します。 そして、pgbench を使用すると、実験室でこの負荷をエミュレートできます。

• 何らかの SQL を実行する必要があります。つまり、ある種の移行をチェックし、そこにインデックスを作成し、そこで ANALAZE を実行します。 そして、真空化の前と後に何が起こったのかを見てみましょう。 一般に、あらゆる SQL。
• 設定内の 100 つ以上のパラメータを変更します。 たとえば、Amazon でテラバイト データベースの XNUMX 個の値をチェックするように指示できます。 そして数時間以内に結果が得られます。 通常、テラバイト規模のデータベースを展開するには数時間かかります。 ただし、開発中のパッチがあり、シリーズ化が可能です。つまり、同じサーバー上で同じ pgdata を一貫して使用して確認できます。 Postgres が再起動され、キャッシュがリセットされます。 そして、負荷を駆動することができます。

• pg スナップショットから始まるさまざまなファイルの束がディレクトリに到着します。STAT***。 そして最も興味深いのは pg_stat_statements と pg_stat_kcacke です。 これらはリクエストを分析する XNUMX つの拡張機能です。 また、pg_stat_bgwriter には、pgwriter の統計だけでなく、チェックポイントや、バックエンド自体がダーティ バッファを置き換える方法も含まれています。 そして、それを見るのはどれも興味深いです。 たとえば、shared_buffers を設定するときに、全員がどれだけ置換したかを見るのは非常に興味深いです。
• Postgres ログも到着しています。 準備ログとロード再生ログの XNUMX つのログ。
• 比較的新しい機能は FlameGraphs です。
• また、ロードの再生に pgreplay または pgbench オプションを使用した場合、それらの出力はネイティブになります。 そして、レイテンシーとTPSが表示されます。 彼らがそれをどのように見たのかを理解することができるでしょう。
• システムインフォメーション。
• 基本的な CPU と IO チェック。 これは Amazon の EC2 インスタンスに当てはまります。100 つのスレッドで 100 個の同一のインスタンスを起動し、そこで 10 個の異なる実行を実行したい場合、000 回の実験が必要になります。 そして、すでに誰かによって抑圧されている欠陥のあるインスタンスに遭遇しないようにする必要があります。 他のハードウェアがこのハードウェア上でアクティブになっており、リソースがほとんど残っていない。 そのような結果は捨てたほうがよいでしょう。 また、Alexey Kopytov の sysbench の助けを借りて、他のものと比較できるいくつかの短いチェックを実行します。つまり、CPU がどのように動作し、IO がどのように動作するかを理解できます。

さまざまな企業の例に基づく技術的な困難は何ですか?

ログを使用して実際のロードを繰り返したいとします。 オープンソースの pgreplay で書かれていれば素晴らしいアイデアです。 私たちはそれを使っています。 ただし、正常に機能するには、パラメーターとタイミングを使用して完全なクエリ ログを有効にする必要があります。

期間とタイムスタンプにはいくつかの複雑な問題があります。 このキッチン全体を空にします。 一番の問題は、それを買う余裕があるかどうかです。

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

問題は、それが利用できない可能性があることです。 まず、どのようなストリームがログに書き込まれるかを理解する必要があります。 pg_stat_statements がある場合は、このクエリ (リンクはスライド内にあります) を使用して、XNUMX 秒あたりに書き込まれるバイト数をおおよそ把握できます。

リクエストの長さを見てみましょう。 パラメータがないという事実は無視していますが、リクエストの長さと、リクエストが XNUMX 秒あたりに何回実行されたかはわかっています。 このようにして、XNUMX 秒あたりのおおよそのバイト数を推定できます。 二度間違えるかもしれませんが、こうすれば必ず順番がわかります。

このリクエストは 802 秒あたり 300 回実行されることがわかります。 そして、bytes_per sec – XNUMX KB/s がプラスまたはマイナスで書き込まれることがわかります。 そして、原則として、私たちはそのような流れを受け入れることができます。

しかし！ 実際には、さまざまなログ システムが存在します。 そして、人々のデフォルトは通常「syslog」です。

syslog がある場合は、次のような画像が表示される可能性があります。 pgbench を使用し、クエリ ログを有効にして、何が起こるかを見てみましょう。

ログなし - これは左側の列です。 161 TPS を獲得しました。 syslog を使用すると、これは Amazon の Ubuntu 000 で、16.04 TPS が得られます。 そして、他の 37 つのロギング方法に変更すると、状況ははるかに良くなります。 つまり、低下すると予想していましたが、同程度ではありませんでした。

また、CentOS 7 では、journald も参加しており、検索しやすいようにログをバイナリ形式に変換しますが、TPS で 44 回も低下するという悪夢がありました。

そして、これが人々が生きていくことなのです。 そして多くの場合、企業、特に大企業では、これを変えるのは非常に困難です。 syslog から離れられる場合は、syslog から離れてください。

• IOPS と書き込みフローを評価します。
• ログ システムを確認してください。
• 予測される負荷が過度に大きい場合は、サンプリングを検討してください。

pg_stat_statements があります。 私が言ったように、それはそこにあるに違いありません。 そして、リクエストの各グループを特別な方法でファイルに取り込んで記述することができます。 そして、pgbench の非常に便利な機能を使用できます。これは、「-f」オプションを使用して複数のファイルを挿入する機能です。

多くの「-f」を理解します。 また、末尾の「@」を使用すると、各ファイルにどのような共有が必要かを知ることができます。 つまり、10% の場合はこれを実行し、20% の場合はこれを実行すると言えます。 これにより、本番環境で見られるものにさらに近づくことができます。

本番環境にあるものをどうやって理解するのでしょうか? どのようなシェアをどのようにして? これはちょっとした余談です。 もうXNUMXつの製品があります postgres-チェックアップ。 オープンソースの拠点でもあります。 そして私たちは現在それを積極的に開発しています。

彼は少し異なる理由で生まれました。 監視だけでは十分ではないという理由からです。 つまり、あなたは来て、根本を見て、存在する問題を見てください。 そして、原則として、health_check を実行します。 経験豊富な DBA であれば、health_check を実行します。 インデックスの使用法などを検討しました。OKmeter をお持ちであれば、それは素晴らしいことです。 これは Postgres の優れた監視です。 OKmeter.io – インストールしてください。すべてがうまく行われています。 有料です。

持っていない場合は、通常はあまり持っていません。 監視には通常、CPU、IO、そして予約があり、それだけです。 そして、さらに必要があります。 自動バキュームがどのように機能するか、チェックポイントがどのように機能するかを確認する必要があります。IO では、チェックポイントを bgwriter やバックエンドなどから分離する必要があります。

問題は、大企業を支援する場合、何かをすぐに実行できないことです。 OKmeterをすぐに買うことはできません。 もしかしたら半年以内に買うかもしれない。 一部の荷物はすぐに配達できません。

そして、何もインストールする必要のない特別なツールが必要である、つまり本番環境では何もインストールする必要がないという考えに至りました。 これをラップトップ、またはそれを実行する監視サーバーにインストールします。 そして、オペレーティング システム、ファイル システム、Postgres 自体など、多くのことを分析し、実稼働環境で直接実行できるいくつかの軽いクエリを作成し、何も失敗しません。

私たちはこれを Postgres チェックアップと呼びました。 医学的に言えば定期健康診断です。 自動車をテーマにしたものであれば、メンテナンスのようなものです。 ブランドにもよりますが、車のメンテナンスは半年またはXNUMX年ごとに行います。 拠点のメンテナンスは行っていますか？ つまり、定期的に深い調査を行っていますか? それは必ず行われなければなりません。 バックアップを作成してから検査を行う場合、これも同様に重要です。

そして、私たちはそのようなツールを持っています。 活発に出現し始めたのはわずか XNUMX か月ほど前です。 彼はまだ若いですが、たくさんのことがあります。

最も「影響力のある」クエリ グループの収集 - Postgres-checkup のレポート K003

そして、報告グループ K があります。これまでに 003 つの報告があります。 そして、そのようなレポートKXNUMXがあります。 pg_stat_statements を total_time でソートしたものがトップです。

リクエスト グループを total_time で並べ替えると、システムに最も負荷をかけている、つまりより多くのリソースを消費しているグループが一番上に表示されます。 クエリグループに名前を付けるのはなぜですか? パラメーターを破棄したためです。 これらはもはやリクエストではなく、リクエストのグループです。つまり、抽象化されています。

また、上から下まで最適化すると、リソースが軽減され、アップグレードが必要になる時期が遅れることになります。 これはお金を節約するのにとても良い方法です。

おそらくこれは、ユーザーをケアするにはあまり良い方法ではありません。ユーザーが 15 秒待つという、まれではあるものの非常に迷惑なケースは見られないかもしれないからです。 全体として、それらは非常にまれであるため目にすることはありませんが、私たちは資源を扱っています。

このテーブルで何が起こったのでしょうか? スナップショットを1枚撮りました。 Postgres_checkup は、合計時間、コール数、行数、shared_blks_read などの各メトリクスのデルタを提供します。これで、デルタの計算は完了です。 pg_stat_statements の大きな問題は、いつリセットされたかを覚えていないことです。 pg_stat_database が記憶している場合、pg_stat_statements は記憶しません。 000 という数字があることがわかりますが、どこから数えたのかわかりません。

そして、ここに 56 つのスナップショットがあることがわかります。 この場合の差分は XNUMX 秒であることがわかります。 非常に短いギャップ。 total_time で並べ替えられます。 そして、微分することができます。つまり、すべてのメトリクスを期間で分割します。 各メトリクスを期間で割ると、XNUMX 秒あたりの呼び出し数が得られます。

次に、XNUMX 秒あたりの total_time が私のお気に入りの指標です。 これは、XNUMX 秒あたりの秒数、つまりシステムが XNUMX 秒あたりこのリクエストのグループを実行するのに何秒かかったかを測定します。 XNUMX 秒あたり XNUMX 秒を超える場合は、複数のコアを提供する必要があったことを意味します。 これは非常に優れた指標です。 たとえば、この友人には少なくとも XNUMX つのコアが必要であることがわかります。

これは私たちのノウハウであり、このようなものはどこにも見たことがありません。 注意してください - これは非常に単純なことです - 毎秒。 場合によっては、CPU が 100% の場合、XNUMX 秒あたり XNUMX 分、つまり、このリクエストだけを行うのに XNUMX 分を費やしたことになります。

次に、XNUMX 秒あたりの行数を確認します。 XNUMX 秒あたりに返された行数がわかります。

それから、面白いこともあります。 共有バッファ自体から XNUMX 秒あたりに読み取る共有バッファの数。 ヒットはすでに存在していたので、オペレーティング システムのキャッシュまたはディスクから行を取得しました。 最初のオプションは高速ですが、XNUMX 番目のオプションは状況に応じて高速である場合とそうでない場合があります。

101 番目の差別化方法は、このグループ内のリクエストの数を分割することです。 XNUMX 番目の列には、常に XNUMX つのクエリがクエリごとに分割されます。 そして興味深いのは、このリクエストに何ミリ秒が含まれていたかということです。 このクエリが平均してどのように動作するかはわかっています。 各リクエストには XNUMX ミリ秒が必要でした。 これは私たちが理解する必要がある伝統的な指標です。

各クエリは平均して何行を返しましたか? このグループからは 8 人が戻ってくることがわかります。 平均して、キャッシュから取得されて読み取られた量。 すべてが適切にキャッシュされていることがわかります。 最初のグループでは堅実なヒット。

各行の 1 番目の部分文字列は全体の何パーセントかを表します。 電話があります。 000 とすると、このグループがどのような貢献をしているかがわかります。 この場合、最初のグループの寄与は 000% 未満であることがわかります。 つまり、全体像が見えないほど遅いということです。 そして 0,01 番目のグループは通話で 5% です。 つまり、すべてのコールの 5% が XNUMX 番目のグループです。

Total_time も興味深いです。 最初のグループのリクエストに総作業時間の 14% を費やしました。 そして11番目についてはXNUMX％などです。

詳細には触れませんが、微妙な点があります。 上部にエラーを表示します。これは、比較するとスナップショットがフローティングになる可能性があるためです。つまり、一部のリクエストが抜け落ちて 0 番目のリクエストに存在できなくなる一方で、新しいリクエストがいくつか表示される可能性があります。 そしてそこで誤差を計算します。 20 が表示されていれば問題ありません。 間違いはありません。 エラー率が XNUMX% までであれば問題ありません。

それから本題に戻ります。 ワークロードを作成する必要があります。 上から下まで進めて、80% または 90% に達するまで進めます。 通常、これは 10 ～ 20 のグループです。 そして、pgbench 用のファイルを作成します。 そこでランダムを使用します。 残念ながら、これがうまくいかない場合もあります。 Postgres 12 では、このアプローチを使用する機会がさらに増えるでしょう。

そして、このようにして total_time が 80 ～ 90% 増加します。 「@」の次に何を入れればいいでしょうか？ 私たちは電話を見て、どれだけの関心があるかを見て、ここで非常に多くの関心を負っていることを理解します。 これらのパーセンテージから、各ファイルのバランスをとる方法がわかります。 その後、pgbench を使用して作業に進みます。

K001、K002もございます。

K001 は 75 つの部分文字列を持つ 10 つの大きな文字列です。 これは負荷全体の特徴です。 XNUMX 番目の列と XNUMX 番目の下位行を参照してください。 XNUMX 秒あたり約 XNUMX 秒であることがわかります。つまり、コアが XNUMX つある場合は良好です。 容量は約 XNUMX% になります。 そして、それはこのように機能します。 コアが XNUMX 個あれば、通常は落ち着いています。 このようにしてリソースを評価できます。

K002 は、私がクエリ クラスと呼んでいるものです。つまり、SELECT、INSERT、UPDATE、DELETE です。 それはロックなので、別途 SELECT FOR UPDATE を実行します。

そしてここで、SELECT は通常のリーダー (全呼び出しの 82%) であるが、同時に total_time の 74% であると結論付けることができます。 つまり、頻繁に呼び出されますが、消費するリソースは少なくなります。

そして、「正しい共有バッファを選択するにはどうすればよいでしょうか?」という質問に戻ります。 ほとんどのベンチマークは、スループットがどのくらいになるかを見てみましょう、つまりスループットがどのくらいになるかを見てみましょうという考えに基づいていることがわかります。 通常、TPS または QPS で測定されます。

そして、チューニング パラメーターを使用して、車両から 311 秒あたりのトランザクションをできるだけ多く絞り出そうとします。 ここでは、選択の場合はちょうど XNUMX 秒あたり XNUMX です。

しかし、全速力で通勤して帰宅する人はいません。 これはばかげています。 データベースも同様です。 全速力で運転する必要はありませんし、そんな人はいません。 CPU が 100% ある本番環境には誰も住んでいません。 ただし、誰かが住んでいる可能性がありますが、これは良くありません。

通常は容量の 20%、できれば 50% 以下で運転するという考えです。 そして、私たちは何よりもユーザーの応答時間を最適化するよう努めています。 つまり、条件付きで 20% の速度での遅延が最小になるようにノブを回す必要があります。 これは私たちの実験でも使用しようとしているアイデアです。

そして最後に、推奨事項:

• データベースラボは必ず行ってください。
• 可能であれば、オンデマンドで実行して、しばらく展開して、遊んで捨ててください。 雲がある場合は、言うまでもなく、つまり、立っている時間がたくさんあります。
• 好奇心を持ってください。 そして、何かが間違っている場合は、それがどのように動作するかを実験で確認します。 ナンシーは、基地がどのように機能するかを確認するために自分自身を訓練するために使用できます。
• そして、応答時間を最小限にすることを目指します。
• Postgres ソースを恐れる必要はありません。 情報源を扱うときは、英語を理解する必要があります。 そこにはたくさんのコメントがあり、すべてがそこで説明されています。
• また、データベースの健全性を定期的に (少なくとも XNUMX か月に XNUMX 回)、手動または Postgres チェックアップでチェックしてください。

質問

どうもありがとう！ とても興味深いことです。

二枚。

はい、XNUMX個です。 ただ私にはよく分かりませんでした。 ナンシーと私が作業するとき、XNUMX つのパラメータだけを微調整することはできますか、それともグループ全体を微調整することはできますか?

デルタ設定パラメータがあります。 一度に好きなだけそこを曲がることができます。 ただし、多くのことを変更すると、誤った結論が導き出される可能性があることを理解する必要があります。

はい。 なぜ私が尋ねたのでしょうか？ パラメーターが XNUMX つしかない場合、実験を行うのは難しいからです。 締めて、どのように機能するかを見てください。 私は彼を外に出しました。 それから次のことを始めます。

同時に締めることもできますが、もちろん状況によります。 しかし、XNUMX つのアイデアを試してみる方が良いでしょう。 私たちは昨日アイデアを思いつきました。 非常に近い状況でした。 構成は XNUMX つありました。 そして、なぜ大きな違いがあるのか​​理解できませんでした。 そして、違いが何であるかを一貫して理解し見つけるためには、二分法を使用する必要があるという考えが生まれました。 パラメータの半分をすぐに同じにし、次に XNUMX 分の XNUMX にするなど、すべてが柔軟です。

そして、もう一つ質問があります。 このプロジェクトはまだ若く、発展途上です。 ドキュメントはすでに準備されていますが、詳細な説明はありますか?

特にパラメータの説明へのリンクをそこに作成しました。 それはそこにあります。 しかし、多くのことはまだそこにはありません。 私は同じ考えの人を探しています。 そして、演奏するときにそれらを見つけます。 これはとてもクールです。 誰かがすでに私と一緒に働いており、誰かがそこで助けて何かをしてくれました。 このトピックに興味がある場合は、何が欠けているかについてフィードバックを送ってください。

研究室を建てたら、フィードバックがあるかもしれません。 見てみましょう。 ありがとう！

こんにちは！ ご報告ありがとうございます！ Amazonのサポートがあることがわかりました。 GSP をサポートする予定はありますか?

良い質問。 それをやり始めたんです。 お金を節約したいので、今のところ凍結しました。 つまり、localhost での実行の使用がサポートされています。 自分でインスタンスを作成し、ローカルで作業することができます。 ちなみに、それが私たちのやっていることです。 私はこれを Getlab と GSP で行っています。 しかし、Google には安価なスポットがないため、このようなオーケストレーションを行う意味はまだわかりません。 がある ？？？ インスタンスがありますが、制限があります。 まず、常に 70% の割引しかなく、その価格で遊ぶことはできません。 スポットの場合は、キックされる可能性を減らすために価格を 5 ～ 10% 引き上げます。 つまり、スポットは保存されますが、いつでも奪われる可能性があります。 他の人より少しでも高く入札すると、後で殺されることになります。 Google はまったく異なる仕様を持っています。 そして、もう 24 つの非常に悪い制限があります。彼らは 5 時間しか生きられません。 また、XNUMX 日間実験を実行したい場合もあります。 ただし、これはスポット的に行うことができ、スポットは数か月続くこともあります。

こんにちは！ ご報告ありがとうございます！ 検査について言及しましたね。 stat_statements エラーはどのように計算しますか?

とても良い質問です。 とても詳しく見せてお伝えすることができます。 つまり、一連のリクエスト グループがどのように変動したか、つまり、いくつが脱落し、いくつが新しいリクエスト グループが出現したかを調べます。 次に、total_time と calls という XNUMX つのメトリクスを調べます。そのため、XNUMX つのエラーが存在します。 そして、浮動グループの貢献に注目します。 出発者と到着者という XNUMX つのサブグループがあります。 全体像に対する彼らの貢献を見てみましょう。

撮影の合間にXNUMX、XNUMX回曲がってしまうのではないかと心配ではありませんか？

つまり、彼らは再度登録したのか、それとも何なのか？

たとえば、このリクエストはすでに XNUMX 回プリエンプトされており、その後送信されて再びプリエンプトされ、さらに再度送信されて再度プリエンプトされました。 ここで何かを計算しましたが、それはどこにあるのでしょうか?

良い質問ですね、調べてみます。

私も同じようなことをしました。 もちろん、私が一人でやったほうが簡単でした。 しかし、stat_statements をリセットし、リセットし、スナップショットの時点で stat_statements が蓄積できる上限に達していない一定の割合未満であることを確認する必要がありました。 そして私の理解では、おそらく何も置き換えられなかったと思います。

はい、はい。

しかし、他に確実に実行する方法がわかりません。

残念ながら、そこでクエリテキストを使用したのか、pg_stat_statements でクエリ ID を使用してそれに焦点を当てたのか、正確には覚えていません。 queryid に注目すると、理論上は同等のものを比較することになります。

いいえ、スナップショットの間に数回強制的に退場させられ、また戻ってくる可能性があります。

同じIDで？

はい。

これを勉強してみます。 良い質問。 私たちはそれを勉強する必要があります。 しかし今のところ、私たちが見ているものは 0 と書かれています...

もちろん、これはまれなケースですが、stat_statemetns がそこで置き換えられる可能性があることを知ったときはショックを受けました。

Pg_stat_statements には多くのものを含めることができます。 track_utility = on にすると、セットも追跡されるという事実に遭遇しました。

はい、もちろんです。

Java Hibernate を使用している場合 (これはランダムです)、ハッシュ テーブルがそこに配置され始めます。 そして、非常に負荷の高いアプリケーションをオフにすると、すぐに 50 ～ 100 のグループができてしまいます。 そして、そこではすべてが多かれ少なかれ安定しています。 これに対処する XNUMX つの方法は、pg_stat_statements.max を増やすことです。

はい、しかし、その量を知る必要があります。 そして、どういうわけか私たちは彼から目を離さない必要があります。 それが私がやっていることです。 つまり、pg_stat_statements.max があります。 そして、スナップショットの時点では 70% に達していなかったことがわかります。 よし、何も失っていない。 リセットしましょう。 そしてまた保存します。 次のスナップショットが 70 未満の場合は、再び何も失われていない可能性が高くなります。

はい。 現在のデフォルトは 5 ですが、多くの人にとってはこれで十分です。

通常はそうです。

ビデオ：

PS 私自身の代わりに、Postgres に機密データが含まれており、それをテスト環境に含めることができない場合は、次のコマンドを使用できることを付け加えておきます。 PostgreSQL アノニマイザー。 スキームはおおよそ次のとおりです。

出所： habr.com