Как сделать pg_dump менее жадным по ресурсам

Я настроил cron для ежедневного вызова pg_dump, используя следующее правило:

# xyz database backups:
00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz

В принципе, это работает. База данных растет относительно быстро и экспоненциально (однако показатель не очень велик). В настоящее время сжатый дамп занимает около 160 МБ. Когда база данных сбрасывается, система начинает сканировать. Средняя загрузка, которую я видел с помощью topкоманды, была около 200, 200, 180. В основном сервер вряд ли отзывчив.

Первый вопрос в том , как определить , где узкое место . Низкая производительность вызвана интенсивными операциями ввода-вывода? Это вызвано проблемами с блокировкой таблицы? Может быть, это проблема с памятью? Выходные данные pg_dumpкоманды передаются в gzipкоманду. Является ли он последовательным, то есть весь дамп помещается в память (проблема обмена?), А затем сжимается или одновременно (то есть, gzip сжимает то, что получает, и ждет большего)? Может ли это быть вызвано каким-то другим фактором?

Второй вопрос , как сделать демпинг операции менее навязчивой для основных функций системы. Насколько я понимаю, дамп не может занять слишком много времени из-за целостности базы данных. Есть блокировки записи таблиц и т. Д. Что я могу сделать, чтобы ограничить проблемы (или отложить их, учитывая рост базы данных).

Третий вопрос : Есть ли уже время , чтобы узнать о более сложных конфигурациях баз данных? Система работает нормально, когда резервные копии базы данных не выполняются, но, возможно, проблема с дампом БД является первым симптомом входящих проблем?

Ух ты. Удивительное количество вопросов. Я постараюсь обратиться к некоторым, но этот ответ еще не завершен.

как определить, где находится узкое место.

Используйте topсначала, чтобы увидеть, что происходит во время свалки. Проверьте использование процессора процесс, статус процесса. Dозначает «ожидание ввода / вывода».

Низкая производительность вызвана интенсивными операциями ввода-вывода?

Да, скорее всего.

Это вызвано проблемами с блокировкой таблицы?

Может быть. Вы можете использовать pg_stat_activityсистемный вид, чтобы увидеть, что происходит в postgres во время дампа.

Может быть, это проблема с памятью?

Маловероятно.

Выходные данные команды pg_dump передаются в команду gzip. Это последовательно, то есть весь дамп помещается в память (проблема обмена?)

Нет. Gzip - это блочный компрессор, работающий в потоковом режиме, он не сохраняет все данные в памяти.

и затем сжатый или одновременный (то есть gzip сжимает то, что получает и ждет большего)?

Да, он сжимает блок за блоком, выводит и ждет большего.

Может ли это быть вызвано каким-то другим фактором?

Да.

Насколько я понимаю, дамп не может занять слишком много времени из-за целостности базы данных. Есть блокировки записи таблиц и т. Д. Что я могу сделать, чтобы ограничить проблемы (или отложить их, учитывая рост базы данных).

Продолжительность дампа не влияет на целостность дампа. Целостность обеспечивается использованием одной транзакции с повторяемым уровнем изоляции для чтения всем процессом pg_dump. НЕТ блокировок записи таблицы.

Пришло ли время узнать о более сложных конфигурациях баз данных? Система работает нормально, когда резервные копии базы данных не выполняются, но, возможно, проблема с дампом БД является первым симптомом входящих проблем?

Никогда не поздно. Начните с http://wiki.postgresql.org/wiki/Performance_Optimization .

Я рекомендую вам посмотреть на непрерывное архивирование postgresql. Вот преимущества перед использованием pg_dump:

1. Нет необходимости делать полное резервное копирование каждый раз. В начале достаточно одной полной резервной копии, но рекомендуется, например, иметь полную резервную копию каждые несколько дней.
2. Очень быстро восстанавливается при увеличении размера БД.
3. Возможность восстановления в какую-то другую точку (Point-In-Time Recovery).
4. Вы будете делать инкрементное резервное копирование каждый час (30 минут или около того). Это можно настроить и зависит также от активности обновления.

Однако есть некоторые недостатки (которые в большинстве случаев могут не быть проблемой):

1. Обычно требуется больше места, потому что это бинарные резервные копии. Папка БД может быть сжата.
2. Вы не можете восстановить их на другой архитектуре (двоичные данные).