Я настроил 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:
Однако есть некоторые недостатки (которые в большинстве случаев могут не быть проблемой):