Postgresで大量のデータを処理する速度が遅くなりクラッシュする

Question

Luigiフレームワークを使用してPythonスクリプトを使用して大量のデータ（それぞれ1,500万行の100個のcsvファイルを取り込みます）を取り込みしようとしました。

2016-08-18 13:14:31.714 UTC,,,8508,,57b5b2ec.213c,1,,2016-08-18 13:06:52 UTC,13/109,0,PANIC,53100,"could not write to file ""pg_xlog/xlogtemp.8508"": No space left on device",,,,,"writing block 49526 of relation base/16384/22811",,,, ""

摂取が（WAL）メカニズムをログ控え書くによるPOSTGRESによってブロックされているように思え：私は最も重要な部分があり、そのうちの（Postgresのログから）次のエラーに達するまで細かいです。 10日分のファイルを摂取してデータベースをリセットした後、私はより多くの日を摂取しようとしました。 2回目の試みでは、1日のデータが摂取されるのはわずか1日です。 3回目の試みは完全に失敗します。

pg_xlogがクリーニングされていない場合はありますか？私は彼らがどのように管理され、正確な目的が分からないので、私の直感は、WALはPOSTGRESがデータベースに挿入される行を書き込むメカニズムだと言います。

私は欠けているデータベースの設定はありますか？私のテーブルのインデックスには問題がありますか？ほかに何か？これらの.csvファイルのGBでの全体的なサイズ、である何

2016-08-18 12:57:45.255 UTC,,,8342,,57b5a460.2096,96,,2016-08-18 12:04:48 UTC,,0,LOG,00000,"checkpoints are occurring too frequently (25 seconds apart)",,"Consider increasing the configuration parameter ""max_wal_size"".",,,,,,,"" 2016-08-18 12:57:45.255 UTC,,,8342,,57b5a460.2096,97,,2016-08-18 12:04:48 UTC,,0,LOG,00000,"checkpoint starting: xlog",,,,,,,,,"" 2016-08-18 12:58:13.609 UTC,,,8342,,57b5a460.2096,98,,2016-08-18 12:04:48 UTC,,0,LOG,00000,"checkpoint complete: wrote 349100 buffers (16.6%); 0 transaction log file(s) added, 143 removed, 0 recycled; write=15.550 s, sync=12.677 s, t otal=28.354 s; sync files=51, longest=2.304 s, average=0.248 s; distance=2641771 kB, estimate=2641771 kB",,,,,,,,,"" 1038 2016-08-18 12:58:13.610 UTC,,,8342,,57b5a460.2096,99,,2016-08-18 12:04:48 UTC,,0,LOG,00000,"checkpoints are occurring too frequently (28 seconds apart)",,"Consider increasing the configuration parameter ""max_wal_size"".",,,,,,,"" 1039 2016-08-18 12:58:13.610 UTC,,,8342,,57b5a460.2096,100,,2016-08-18 12:04:48 UTC,,0,LOG,00000,"checkpoint starting: xlog",,,,,,,,,""

おかげ

Answer 1

：

関連するかもしれないログの

他のセクション？ .csvファイルの最大サイズは？ それは私にとって貴重な情報です。

はまた、あなたの実行環境を知ることが重要である：

• オペレーティングシステム：Linux、...
• ストレージ：NAS、SAN、HDD、SSD、使用可能な記憶領域、...
RAM
• プロセッサの
• 量：スピード、...
• PGバージョン：9.5、...

https://github.com/spotify/luigiと表示されていますが、 では問題ありません。 "copy"コマンド（https://www.postgresql.org/docs/9.5/static/sql-copy.html,https://www.postgresql.org/docs/9.5/static/app-psql.html）コマンドを使用して、.csvファイルをPGテーブルにコピーしていると仮定する必要がありますか？

問題の原因は明らかです。 ファイルに書き込むことができません。デバイスに空きがないため、格納するデータの量が であるためディスクがいっぱいです。要するに https://www.postgresql.org/docs/9.5/static/wal-intro.html ：WALの深い説明について

は、このPGドキュメントの章を参照してください WALは、データの整合性を確保するための方法です。 WALでは、データファイル （テーブルとインデックスが存在する場所）の変更は、 が変更された（変更を説明する一連のメタ命令として）変更された後にのみ書き込まれ、 が永続ストレージにフラッシュされました。 データページに適用されていないすべての変更は、ログレコードからやり直すことができます（これは「ロールフォワードリカバリです：だから、クラッシュ時に、我々は、ログを使用してデータベースを復旧 できるようになります"、 、REDOとも呼ばれます）。

あなたは「pg_resetxlogは、」プログラムとWALをリセットすることができます。これは、ここで説明されています http://www.hivelogik.com/blog/?p=513 PostgreSQLの：きれいにする方法をpg_xlog内のPostgresのディスク領域の問題のうち、pg_xlog内解く http://blog.endpoint.com/2014/09/pgxlog-disk-space-problem-on-postgres.html
https://www.postgresql.org/docs/9.5/static/app-pgresetxlog.html pg_resetxlog - PostgreSQLデータベースクラスタの先行書き込みログやその他の制御情報をリセット

ここでも、ログトレースに 「チェックポイントが頻繁に発生しているが（25秒間隔）」、 は「max_wal_size 『』設定パラメータを増やすことを検討してください」「」 はソリューションを指しています 構成パラメータ "max_wal_size"を に変更してください。 https://dba.stackexchange.com/questions/117479/checkpoints-are-occurring-too-frequently-during-pg-restore 同じ問題が発生した場合の詳細情報があります。そのリンクで は、それが「...通常のチェックポイントの頻度よりも頻繁に発生する チェックポイントが発生します大量のデータをPostgreSQLにロード」と述べています。最後に

、私はPGにいくつかの経験摂取のデータファイル（CSVやプレーンテキストファイル） を持っていると私はあなたに次のパイプラインをお勧めします：データbecaseログに記録されないよう、「MyTargetTmpTableを」一時テーブルを作成します

1. を未ログインのテーブルに書き込まれます は、先取りログに書き込まれません。
2. テーブル "MyTargetTmpTable" を切り捨てます。
3. Linuxのコマンド "cat"、 "head"などの "tail"を使用して入力データを制限された最大サイズのバッチに分割し、 "psql"コマンドに入力して "copy 。800000 -nヘッド| | $猫hugefile.csv PSQL ... -c "\（形式のcsv）でpstdinからMyTargetTmpTableをコピー"
4. はファイナルテーブルに "MyTargetTmpTable" からすべての行を移動し
5. 。残りのCSV行のバッチを使用して、前の手順をすべて繰り返します。