Поглощение большого количества данных в Postgres замедляется и в конечном итоге приводит к сбоям

Я пытался проглотить большое количество данных (около 100 csv-файлов с 15 миллионами строк каждый) с помощью скрипта Python с использованием фреймворка Luigi, и проглатывание шло нормально, пока я не достиг следующей ошибки (из журналов Postgres), из которых наиболее важной частью является:




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",,,, ""



Похоже, что проглатывание блокируется POSTGRES из-за механизма записи вперед (WAL). После того, как я проглотил файл на 10 дней и сбросил базу данных, я попытался проглотить еще несколько дней. Вторая попытка, в результате только 1 дополнительный день Ворт данных заглатывания. Третья попытка просто полностью проваливается.



Это тот случай, когда pg_xlog не очищается? Я понятия не имею, как ими управляют и какова точная цель, моя интуиция говорит, что WAL-это механизм, с помощью которого POSTGRES пишет строки, которые будут вставлены в базу данных.



Есть ли какая-либо конфигурация базы данных, которую я пропускаю? Это проблема с индексами на моей таблице? Что еще что-нибудь?



Другие разделы журнала, которые могут иметь отношение к делу:




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",,,,,,,,,""



Спасибо

477   1  

1 ответ:

Каков общий размер, в ГБ, из них .файлы csv? Каков максимальный размер а .csv-файл? Это ценная информация для меня.

Также важно знать среду выполнения:

  • операционная система: Linux, ...
  • хранение: NAS, SAN, HDD, SSD, доступное место для хранения,...
  • Объем оперативной памяти
  • Процессор: скорость,...
  • версия PG: 9.5, ...

Я вижу, что такое https://github.com/spotify/luigi , но я думаю, что это не имеет значения в твоя проблема. Я должен предположить, что вы справляетесь с этим .csv-файлы в таблицы PG с помощью "копия" (https://www.postgresql.org/docs/9.5/static/sql-copy.html , https://www.postgresql.org/docs/9.5/static/app-psql.html ) командование?

Причина проблемы ясна: невозможно записать в файл потому что на устройстве не осталось места, потому что диск заполнен из-за к объему данных, предназначенных для хранения.

Для глубокого объяснения WAL, смотрите эту главу PG doc: https://www.postgresql.org/docs/9.5/static/wal-intro.html Вкратце: WAL-это метод обеспечения целостности данных. С WAL, изменения в файлах данных (где находятся таблицы и индексы) записываются только после внесения этих изменений. регистрируются (как последовательность мета-инструкций, описывающих изменения) и были смывается на постоянное хранение. Таким образом, в случае аварии мы сможем восстановление базы данных с помощью журнала: любые изменения которые не были применены к страницы данных можно переделать из записей журнала (это " ролл-форвардное восстановление", также известный как REDO).

Вы можете сбросить WAL с помощью программы "pg_resetxlog". Это объясняется здесь: http://www.hivelogik.com/blog/?p=513 Postgresql: как очистить pg_xlog http://blog.endpoint.com/2014/09/pgxlog-disk-space-problem-on-postgres.html Решение проблемы pg_xlog из дискового пространства на Postgres
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 вызовет контрольные точки будут появляться чаще, чем обычная частота контрольных точек".

Наконец, у меня есть некоторый опыт приема файлов данных (CSV и простые текстовые файлы) в PG и я рекомендую вам следующее трубопровод:

  1. Создайте временную таблицу "MyTargetTmpTable" в виде незарегистрированных данных, записанных в незарегистрированные таблицы не записывается в журнал предварительной записи.
  2. Усеките таблицу "MyTargetTmpTable".
  3. разделите входные данные на пакеты ограниченного максимального размера (используйте команды Linux "кошка", "голова" и т. д. "хвост") и передать его в команду "psql", которая выполнит "копировать. $ кот hugefile.csv / head-n 800000 / psql ... -с "\копия MyTargetTmpTable от pstdin с (формат csv) "
  4. переместите все строки из "MyTargetTmpTable" в конечную таблицу.
  5. повторите всю предыдущую процедуру с оставшимися пакетами строк CSV.
2  
2017-04-13 15:42:36

Comments

    Ничего не найдено.
Click here to cancel reply.