大量のデータをPostgreSQLにテレポートする

今日は、PostgeSQLサーバーのパフォーマンスを大量に分析するためのツールの開発中に発生した、1,000を超えるホストの完全な監視と分析を同じハードウェアに「適合」させるのに役立ついくつかの有用なアーキテクチャソリューションを共有します。 ..。

イントロ

いくつかの紹介文を思い出させてください。

• PostgreSQLサーバーのログから情報を受け取るサービスを構築しています
• ログを収集し、オンラインで何か（解析、分析、追加情報の要求）を行いたい
• 収集および「分析」されたものはすべてどこかに保存する必要があります

最後のポイント、つまりこれらすべてをPostgreSQLストレージに配信する方法について説明しましょう。私たちの場合、このデータは元のデータの倍数です。特定のアプリケーションとプランテンプレートのコンテキストでの負荷統計、リソース消費、単一のプランノードに正確な派生問題の計算、ロックの監視などがあります。

サービスの原則の詳細については、ビデオレポートを参照し、記事「PostgreSQLクエリの一括最適化」を参照してください。

プッシュvsプル

ログまたはその他の常に到着するメトリックを取得するための2つの主要なモデルがあります。

• push-サービス上、監視対象サーバー上に多くのピアツーピアレシーバーがあります-一部のローカルエージェントは、蓄積された情報を定期的にサービスにダンプします
• プル-サービスでは、各プロセス/スレッド/ coroutine / ...は、1つの「独自の」ソースからの情報のみを処理し、データの受信はそれ自体で開始されます。

これらの各モデルには、プラス面とマイナス面があります。

押す

相互作用は、監視対象ノードによって開始されます。



...次の場合に有益です：

• あなたはたくさんの情報源を持っています（数十万）
• それらの負荷はそれらの間であまり差がなく、〜1rpsを超えません
• 複雑な処理は必要ありません

例：各クライアントのキャッシュレジスタから小切手を受け取るOFDオペレーターの受信者。



...問題を引き起こします：

• さまざまなストリームからの監視オブジェクトのコンテキストで辞書/分析/集計を書き込もうとしたときのロック/デッドロック
• 各BLプロセスのキャッシュの最悪の使用率/データベースへの接続-たとえば、データベースへの同じ接続を最初に1つのテーブルまたはインデックスセグメントに書き込み、すぐに別のセグメントに書き込む必要があります
• 各ソースに特別なエージェントを配置する必要があるため、ソースの負荷が増加します
• ネットワーク相互作用のオーバーヘッドが高い-ヘッダーは、ソースへの接続全体ではなく、各パケットの送信を「結び付ける」必要があります

引く

イニシエーターは、コレクターの特定のホスト/プロセス/スレッドであり、ノードをそれ自体に「バインド」し、「ターゲット」から独立してデータを取得します。



...次の場合に有益です：

• ソースがほとんどありません（数十万）
• ほとんどの場合、それらからの負荷があり、1Krpsに達することもあります
• ソースによるセグメンテーションを伴う複雑な処理が必要

例：各取引プラットフォームのコンテキストでの取引のローダー/アナライザー。



...問題を引き起こします：

• 2つの受信者間で「スミア」できないため、1つのソースを1つのプロセス（CPUコア）で処理するためのリソースの制限
• ソースからの負荷を既存のプロセス/スレッド/リソース全体に動的に再分散するコーディネーターが必要です

PostgreSQLを監視するときの負荷モデルは明らかにプルアルゴリズムに引き寄せられ、1つのプロセスのリソースと最新のCPUのカーネルは、1つのソースに対して十分であるため、そこで停止しました。

プルプルログ

サーバーとの通信は、非常に多くのネットワーク操作を提供し、slaboformatirovannymiテキスト文字列を処理するため、コレクターコアとしてJavaScriptはサーバーNode.jsとしての彼の化身で完璧になりました。



サーバーログからデータを取得するための最も簡単な解決策は、単純なlinuxコマンドを使用してログファイル全体をコンソールに「ミラーリング」することであることが判明しましたtail -F <current.log>。私たちのコンソールだけが単純ではありませんが、仮想です-SSHプロトコルを介して拡張されたサーバーへの安全な接続の内部。



したがって、SSH接続の2番目の側にあるコレクターは、すべてのログトラフィックの完全なコピーを入力として受け取ります。また、必要に応じて、サーバーに現在の状況に関する拡張システム情報を要求します。

なぜsyslogしないのですか

主な理由は2つあります。

1. syslogプッシュモデルで動作するため、受信ポイントで生成されたストリームの処理負荷を迅速に管理することはできません。つまり、ホストのペアが突然数千の遅い要求の計画を「注ぎ込み」始めた場合、それらの処理を異なるノード間で分離することは非常に困難です。
   
   
   
   ここでの処理は、ログの「ばかげた」受信/解析ではなく、計画を解析し、各ノードの実際のリソース強度を計算することを意味します。
2. PostgreSQL, , «» (relation/page/tuple/...).
   
   

   «DBA: ».

-

原則として、ログから解析されたデータを格納するためのDBMSとして他のソリューションを使用できますが、150〜200GB /日の受信情報の量は、操作の余地をあまり残しません。そのため、ストレージとしてP​​ostgreSQLも選択しました。



-ログを保存するためのPostgreSQL？真剣に？

-まず、さまざまな分析表現ほど多くのログはありません。第二に、「あなたはそれらを調理する方法がわからないだけです！」:)

サーバー設定

この点は主観的なものであり、ハードウェアに大きく依存しますが、アクティブな記録用にPostgreSQLホストを構成するために、次の原則を作成しました。



ファイルシステムの設定

書き込みパフォーマンスに影響を与える最も重要な要因は、データパーティションの[正しくない]マウントです。次のルールを選択しました。

• PGD​​ATAディレクトリはパラメータでマウントされます（ext4の場合）noatime,nodiratime,barrier=0,errors=remount-ro,data=writeback,nobh
• ディレクトリPGD​​ATA / pg_stat_tmpはに移動されますtmpfs
• PGD​​ATA / pg_walディレクトリがされて移動し、それが合理的である場合、他のメディアに

PostgreSQLファイルシステムのチューニング



を 参照してください。最適なI / Oスケジューラーの

選択デフォルトでは、多くのディストリビューションがcfq、RedHatおよびCentOSで「デスクトップ」用にシャープ化されたI / Oスケジューラーを選択していますnoop。しかし、それは私たちにとってより有用であることが判明しましたdeadline。PostgreSQLとを



参照してください。I / Oスケジューラー（cfq、noop、および期限）



「ダーティ」キャッシュのサイズの削減

このパラメーターvm.dirty_background_bytesは、キャッシュのサイズをバイト単位で設定します。このパラメーターに達すると、システムはキャッシュをディスクにフラッシュするバックグラウンドプロセスを開始します。同様ですが、相互に排他的なパラメータがあります。これは、vm.dirty_background_ratio合計メモリサイズのパーセンテージと同じ値を設定します。デフォルトでは、「...バイト」ではなく設定されます。



ほとんどのディストリビューションでは10％、CentOSでは5％です。これは、合計サーバーメモリが16GBの場合、システムが一度に850MBを超えるデータをディスクに書き込もうとする可能性があることを意味し、その結果、IOpsの負荷がピークになります。



記録のピークが滑らかになり始めるまで、実験的に減少させます。経験上、スパイクを回避するために、サイズは最大メディアスループット（IOps単位）にメモリページサイズを掛けた値よりも小さくする必要があります。つまり、たとえば、7K IOps（〜7000 x 4096）の場合-約28MBです。postgresql.confのPostgreSQL最適化設定用のLinuxカーネルオプションの構成を



参照してください。





記録をスピードアップするためにねじれた、どのパラメータを表示する必要がありますか。ここにあるものはすべて純粋に個人的なものなので、このトピックについていくつか考えます。

• shared_buffers -特に重複する「共通」データを対象に記録すると、プロセスが発生しないため、小さくする必要があります。
• synchronous_commit = off -RAIDコントローラーのバッテリーを信頼している場合は、いつでもコミット書き込みの待機を無効にできます
• fsync-データがまったく重要でない場合は、オフにすることができます-「制限内」でメモリ内DBを取得することもできます

データベーステーブルの構造

物理データストレージの最適化に関するいくつかの記事をすでに公開しています。

• テーブルのパーティション分割について- 「サブライトでPostgreSQLに書き込みます：1ホスト、1日、1TB」
• TOAST設定について- 「PostgreSQLの大容量で多くのお金を節約する」

しかし、データ内のさまざまなキーについては、まだありませんでした。それらについてお話しします。



外部キーは、書き込みが多いシステムにとっては悪です。実際、これらは「不注意」であり、不注意なプログラマーがデータベースにあるべきではないものをデータベースに書き込むことを許可しません。



多くの開発者は、データベーステーブルを記述するレベルで論理的に関連するビジネスエンティティをFKを介してリンクする必要があるという事実に慣れています。しかし、そうではありません！



もちろん、この点は、データベースにデータを書き込むときに設定した目標に大きく依存します。あなたが銀行ではない場合（そしてあなたが銀行でもある場合は処理していません！）、ヘビーライトデータベースでのFKの必要性は疑わしいです。



「技術的に」各FKは、レコードを挿入するときに個別のSELECTを作成します参照されるテーブルから。ここで、アクティブに作成しているテーブルを見て、2〜3個のFKがぶら下がっていて、特定のタスクがパフォーマンスを3〜4倍低下させるような整合性を提供する価値があるかどうかを評価します...または値による論理接続で十分ですか？ここですべてのFKを削除しました。



UUIDキーは良いです。無関係な異なるポイントで生成されたUUIDの衝突の可能性は非常に小さいため、この負荷（いくつかの代理IDを生成することによる）は、データベースから「消費者」に安全に取り除くことができます。UUIDの使用は、接続された非同期分散システムでは良い習慣です。

PostgreSQLの一意の識別子の他のバリエーションについては、「PostgreSQLアンチパターン：一意の識別子」の記事を参照してください。

複数のフィールドで構成されている場合でも、ナチュラルキーも適しています。複合キーではなく、追加の代理PKフィールドと、ロードされたテーブル内のそのインデックスを恐れる必要があります。これは、なくても簡単に実行できます。



同時に、アプローチの組み合わせを禁止する人は誰もいません。例えば、我々が持っているに割り当てられた代理UUID 1元のトランザクションに関連するシーケンシャルログエントリの「バッチ」が、ペアはPKとして使用されている（存在しない単なる自然キーであるため）(pack::uuid, recno::int2)、recnoあるの「自然な」シーケンス番号バッチ内のレコード。

「エンドレス」COPYストリーム

OCと同様に、PostgreSQLは、データが大量のバッチ（INSERT1000行など）で書き込まれる場合、「気に入らない」のです。ただしCOPY、バランスの取れた書き込みストリーム（から）に対してははるかに耐性があります。しかし、彼らは非常に注意深く調理できなければなりません。

1. 前の段階ですべてのFKを削除したので、今では、それ自体packと関連するFKのセットに関する情報をreord任意の順序で非同期に書き込むことができます。この場合、各ターゲットテーブルに対して常にアクティブなCOPYチャネルを維持することが最も効果的です。
2. , , «», ( — COPY-) . , — 100, .
3. , , . . .
   
   
   
   , , «» , . , .
4. , node-pg, PostgreSQL Node.js, API — stream.write(data) COPY- true, , false, .
   
   
   
   
   
   
   
   , , « », COPY .
5. COPY- LRU «». .

ここで、ログの読み取りと書き込みのこのスキームで得られた主な利点に注意する必要があります。データベースでは、数秒後に「事実」がほぼオンラインで分析できるようになります。

ファイルによる絞り込み

すべてが良いようです。前のスキームの「レーキ」はどこにありますか？簡単に始めましょう...

オーバーシンク

ロードされたシステムの大きな問題の1つは、それを必要としない一部の操作の過剰同期です。「彼らが気づかなかったため」、「その方が簡単だった」場合もありますが、遅かれ早かれそれを取り除く必要があります。



これは簡単に実現できます。監視用に約1000台のサーバーをすでに設定しており、各サーバーは個別の論理スレッドによって処理され、各スレッドは次のように特定の頻度でデータベースに送信するために蓄積された情報をダンプします。

setInterval(writeDB, interval)

ここでの問題は、すべてのストリームがほぼ同時に開始するという事実に正確にあります。そのため、ストリームを送信する瞬間は、ほとんどの場合、「ポイントに」一致します。





幸いなことに、これは簡単に修正できます。開始時刻と間隔の両方に「ランダムな」時間間隔を追加することで、次のようになります。

setInterval(writeDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

この方法では、記録の負荷を統計的に「分散」させて、ほぼ均一にすることができます。

CPUコアによるスケーリング

負荷全体に対して1つのプロセッサコアでは明らかに不十分ですが、クラスタモジュールはここで役立ちます。これにより、子プロセスの作成を簡単に管理し、IPCを介してそれらと通信できます。



これで、16個のプロセッサコアに対して16個の子プロセスができました。これで、CPU全体を使用できます。ただし、各プロセスで16個のターゲットプレートに書き込み、ピーク負荷が発生すると、追加のCOPYチャネルも開きます。つまり、常に256以上のアクティブな書き込みスレッドに基づいています...ああ！このような混乱はディスクのパフォーマンスに良い影響を与えず、ベースが燃え始めました。



これは、いくつかの一般的な辞書（たとえば、異なるノードから送信された同じ要求テキスト）を書き留めようとしたときに特に悲しかったです。不要なロック、待機中...





状況を「裏返し」ましょう。つまり、子プロセスがソースから情報を収集して処理するようにしますが、データベースには書き込まないでください。代わりに、IPCを介してマスターにメッセージを送信させてください。彼はすでに必要な場所に何かを書いています。





前の段落のスキームで問題をすぐに見た人は誰でも-よくやった。マスターが限られたリソースを持つプロセスでもあるのはまさにその瞬間です。したがって、ある時点で、彼がすでに書き込みを開始していることを発見しました。これは、1つのCPUコアのリソースによっても制限されていたため、すべてのスレッドをデータベースにシフトすることへの対処を停止しただけです。その結果、最も負荷の少ない「辞書」ストリームのほとんどをマスターを介して書き込むようにし、最も負荷の高いが追加の処理を必要としないものをワーカーに返しました。

マルチコレクター

ただし、1つのノードでも、使用可能なすべての負荷を処理するには不十分です。線形スケーリングについて考えるときが来ました。解決策は、ヘッドにコーディネーターを配置した負荷に応じたマルチコレクターの自動バランシングでした。





各マスターは、すべてのワーカーの現在の負荷を自分にダンプし、それに応じて、どのノードの監視を別のワーカーまたは別のコレクターに転送するかについての推奨事項を受け取ります。このようなバランシングアルゴリズムに関する別の記事があります。

プーリングとキュー制限

次の正しい質問は、突然のピーク負荷が発生したときに書き込みストリームをどうするかです。



結局のところ、ベースへの新しい接続を際限なく開くことはできません。効果がなく、役に立ちません。簡単な解決策-ターゲットテーブルごとに同時にアクティブなスレッドが16個を超えないように制限しましょう。しかし、まだ「書き込む時間がなかった」データをどうするか？..



この負荷の「急増」が正確にピーク、つまり短期である場合、コレクター自体のメモリーのキューにデータを一時的に保存できます。ベースへのチャネルが解放されるとすぐに、キューからレコードを取得してストリームに送信します。



はい、これには、コレクターにキューを格納するためのバッファーが必要ですが、それはかなり小さく、すぐに解放されます。

キューの優先順位

前の写真を見ていた注意深い読者は、「メモリが完全に使い果たされたときに何が起こるのか？..」と再び戸惑いました。すでにいくつかの選択肢があります-誰かを犠牲にする必要があります。



しかし、データベースに配信したいすべてのレコードが「同等に役立つ」わけではありません。それらをできるだけ多く、定量的に書き留めることは私たちの利益です。書かれた文字列のサイズによる原始的な「指数優先順位付け」は、これに役立ちます。

let priority = Math.trunc(Math.log2(line.length));
queue[priority].push(line);

したがって、チャネルに書き込むときは、常に「下位」のキューからすくい上げ始めます。つまり、各行が短くなっているだけで、より定量的に送信できます。

let qkeys = Object.keys(queue);
qkeys.sort((x, y) => x.valueOf() - y.valueOf()); // - - !

閉塞を打ち負かす

それでは、2つのステップに戻りましょう。その時までに、1つのテーブルのアドレスに最大16のスレッドを残すことにしました。ターゲットテーブルが「ストリーミング」である場合、つまりレコードが相互に相関していない場合、すべてが正常です。最大-ディスクレベルで「物理的」ロックがあります。



ただし、これが集計のテーブルまたは「辞書」である場合、異なるストリームから同じPKを使用して行を書き込もうとすると、ロックの待機、またはデッドロックが発生します。それは悲しいです...



しかし、結局のところ、何を書くべきか-私たちは自分自身を定義します！重要な点は、異なる場所から1つのPKを書き込もうとしないことです。



つまり、キューを渡すと、そのようなPKを使用して、あるスレッドがすでに同じテーブルに書き込んでいるかどうかをすぐに確認します（すべてが1つのプロセスの共通ア​​ドレススペースにあることを覚えています）。そうでない場合は、自分で取得してメモリ内の辞書に「自分で」書き込みます。すでに他の人のものである場合は、キューに入れます。



トランザクションの最後に、辞書から添付ファイルを「自分自身に」「クリーンアップ」するだけです。

少しの証拠

まず、LRUを使用すると、「最初の」接続とそれらを提供するPostgreSQLプロセスは、ほとんどの場合、常に実行されます。これは、OSがCPUコア間でそれらを切り替える頻度がはるかに少なく、ダウンタイムを最小限に抑えることを意味します。





次に、サーバー側でほぼ常に同じプロセスを操作している場合、2つのプロセスが同時にアクティブになる可能性が大幅に減少します。したがって、CPU全体のピーク負荷が減少します（左から2番目のグラフの灰色の領域）。 ）そしてLAは、順番を待っているプロセスが少ないために低下します。





それが今日のすべてです。



また、explain.tensor.ruを使用すると、クエリ実行計画を視覚化するためのさまざまなオプションを確認できることを思い出してください。これは、問題のある領域を視覚的に確認するのに役立ちます。