https://www.opennet.ru/openforum/vsluhforumID8/7746.html Прошу совета гуру по postgre - непонятная медленная работа pg_dump/pg_restore<br>Есть большая база на много гиг. Создание полного бэкапа занимает несколько суток. При расчете потраченного на бакап кол-ва времени на полученный объем бэкап-файла, получается, что скорость всего около 2Мб/с :(<br>Перерыл кучу док, мануалов, советов и т.д. - ничего не помогает, сейчас после небольшого шаманства с настройками bgwriter максимум что достиг - это около 4 Метров в сек создается бэкап (14 гиг бакап за 55 минут, но это не полный бакап базы - только малая часть).<br>Аппаратная начинка - рейд-1, скорость записи по тестам 120-130МБайт/с, памяти 16Гб, особо без нагрузки, винт не занят, io простаивает - т.е. упирания в производительность винтов нет. Т.е. во время бакапа можно легко что-то по сети (через ftp) на этот же рейд что-то залить со скоростью 80-90МБ/с или скачать с такой же скоростью. Соответственно, при поднятии из бакапа - тоже скорость создания новых файлов как-то не ахти совсем - т.е. вполне может очередной 1G-файл бол https://www.opennet.ru/openforum/vsluhforumID8/7746.html#8 Sat, 06 Jul 2013 16:57:11 GMT &gt;[оверквотинг удален]<br>&gt; BINARY, к сожалению, тут не поможет мне, но играние с уровнем компрессии <br>&gt; - то, что нужно, оказалось.<br>&gt; Теперь тяжелые таблицы с кучей блобов бэкаплю с -Z1, а все остальное <br>&gt; с -Z4. Результат налицо - судя по тому, что за час <br>&gt; сделалось уже 65гиг бэкапа тяжелой таблицы - где-то за 5 часов <br>&gt; все сделается, а не как раньше за 3 суток. А все <br>&gt; остальное теперь бакапится тоже - не час, а всего 30 минут. <br>&gt; Размер бакапов увеличился на 5-10%, что не так критично в данном <br>&gt; случае - главное, что времени съэкономлено море.<br>&gt; Спасибо большое еще раз :-) <br><br>Ok. Спасибо за информацию.<br> https://www.opennet.ru/openforum/vsluhforumID8/7746.html#7 Sat, 06 Jul 2013 16:45:08 GMT &gt; Если в Вашей базе блобы, то похоже, что не Вы один страдаете <br>&gt; - поробуйте погуглить <br>&gt; http://www.postgresql.org/message-id/4B9C97E1.40509@davidnewall.com <br>&gt; пишут, что использование COPY BINARY помогает <br><br>BINARY, к сожалению, тут не поможет мне, но играние с уровнем компрессии - то, что нужно, оказалось.<br>Теперь тяжелые таблицы с кучей блобов бэкаплю с -Z1, а все остальное с -Z4. Результат налицо - судя по тому, что за час сделалось уже 65гиг бэкапа тяжелой таблицы - где-то за 5 часов все сделается, а не как раньше за 3 суток. А все остальное теперь бакапится тоже - не час, а всего 30 минут. Размер бакапов увеличился на 5-10%, что не так критично в данном случае - главное, что времени съэкономлено море.<br><br>Спасибо большое еще раз :-)<br> https://www.opennet.ru/openforum/vsluhforumID8/7746.html#6 Sat, 06 Jul 2013 15:02:03 GMT &gt; Если в Вашей базе блобы, то похоже, что не Вы один страдаете <br>&gt; - поробуйте погуглить <br>&gt; postgresql blob pg_dump slow <br>&gt; есть соответствующие письма в списках рассылки PosqgreSQL.<br>&gt; Например <br>&gt; http://www.postgresql.org/message-id/4B9C97E1.40509@davidnewall.com <br>&gt; пишут, что использование COPY BINARY помогает <br><br>ОО. Спасибо! Очень интересные выводы в топике том. Да - в одной тяжелой таблице есть блобы. В целом там интересная выкладка по выбору степени компрессии - на размере итоговом не так сильно сказывается, а вот время выполнения - чуть ли не в два-три раза уменьшается.<br>Спасибо большое.<br> https://www.opennet.ru/openforum/vsluhforumID8/7746.html#5 Sat, 06 Jul 2013 14:05:31 GMT Если в Вашей базе блобы, то похоже, что не Вы один страдаете - поробуйте погуглить<br>postgresql blob pg_dump slow<br>есть соответствующие письма в списках рассылки PosqgreSQL.<br>Например<br>http://www.postgresql.org/message-id/4B9C97E1.40509@davidnewall.com<br>пишут, что использование COPY BINARY помогает<br> https://www.opennet.ru/openforum/vsluhforumID8/7746.html#4 Sat, 06 Jul 2013 12:20:44 GMT &gt; Из Вашего конфига не видно параметров autovacuum.<br>&gt; Еще не понятно, какая ФС под БД и с какими опциями смонтирована <br>&gt; (noatime)?<br><br>ext3, монтируется с noatime<br><br>&gt; В целом в Вашем конфиге есть практически все, что рекомендуют для быстрого <br>&gt; создания резервных копий: <br>&gt; autovacuum = off <br>&gt; fsync = off <br>&gt; full_page_writes = off <br><br>autovacuum у меня on, но я пробовал его отключать - ноль эмоций. Мало того, когда он включен, то просто он не запускается, если база сейчас занята - в логе появляется варнинг об этом, что мол автовакуум запустился, но ждет, так как сейчас база занята. По сути он и не мешается. Так как бакап я запускаю не во время активной работы, а когда полный штиль - никаких инсертов-удалений.<br><br>&gt; Если с ФС все в порядке, то я бы попробовал вернуть параметры <br>&gt; PostgreSQL к значениям по умолчанию (или рекомендациям, например, pgtune - http://pgfoundry.org/projects/pgtune/) <br>&gt; - не получится ли выявить проблемное значение параметра последовательно (если проблема <br>&gt; в этом).<br><br>Уже делал https://www.opennet.ru/openforum/vsluhforumID8/7746.html#3 Sat, 06 Jul 2013 12:08:53 GMT &gt;[оверквотинг удален]<br>&gt;&gt; остальные настройки вроде вообще никак не влияют на скорость создания бэкапов.<br>&gt;&gt; Вот пример как делается бэкап: <br>&gt;&gt; pg_dump --ignore-version --file=fulldump.pgdump --blobs --no-owner --superuser=postgres <br>&gt;&gt; --format=c --schema=\"$dbschema\" $dbname <br>&gt;&gt; а вот так рестор: <br>&gt;&gt; pg_restore --no-data-for-failed-tables --clean --jobs=7 --dbname=$dbname fulldump.pgdump <br>&gt;&gt; Что не так? :( <br>&gt; Хочешь быстро - делай http://www.postgresql.org/docs/8.4/static/continuous-archiving.html <br>&gt; , будет тебе "со скоростью диска". Только оно в 2-5-10 раз <br>&gt; больше по объёму, чем pg_dump-ом.<br><br>wal-логирование - интересный метод, но требуется просто немеряного места особенно в данном случае - база более 400гиг весит. Не подходит :( Я уже смотрел в его сторону, но есть минусы большие:<br>- требуется много места дополнительно<br>- забакапить только одну схему или одну таблицу нельзя<br>- много телодвижений при процессе восстановления и много что надо учесть, перенести<br><br>&gt; Если нет, ну дефрагментацию ба https://www.opennet.ru/openforum/vsluhforumID8/7746.html#2 Sat, 06 Jul 2013 08:56:08 GMT Из Вашего конфига не видно параметров autovacuum.<br>Еще не понятно, какая ФС под БД и с какими опциями смонтирована (noatime)?<br><br>В целом в Вашем конфиге есть практически все, что рекомендуют для быстрого создания резервных копий:<br>autovacuum = off<br>fsync = off<br>full_page_writes = off<br><br>Если с ФС все в порядке, то я бы попробовал вернуть параметры PostgreSQL к значениям по умолчанию (или рекомендациям, например, pgtune - http://pgfoundry.org/projects/pgtune/) - не получится ли выявить проблемное значение параметра последовательно (если проблема в этом).<br> https://www.opennet.ru/openforum/vsluhforumID8/7746.html#1 Sat, 06 Jul 2013 07:56:24 GMT &gt;[оверквотинг удален]<br>&gt; checkpoint_segments = 100 <br>&gt; checkpoint_completion_target = 0.9 <br>&gt; --- <br>&gt; остальные настройки вроде вообще никак не влияют на скорость создания бэкапов.<br>&gt; Вот пример как делается бэкап: <br>&gt; pg_dump --ignore-version --file=fulldump.pgdump --blobs --no-owner --superuser=postgres <br>&gt; --format=c --schema=\"$dbschema\" $dbname <br>&gt; а вот так рестор: <br>&gt; pg_restore --no-data-for-failed-tables --clean --jobs=7 --dbname=$dbname fulldump.pgdump <br>&gt; Что не так? :( <br><br>Хочешь быстро - делай http://www.postgresql.org/docs/8.4/static/continuous-archiving.html , будет тебе "со скоростью диска". Только оно в 2-5-10 раз больше по объёму, чем pg_dump-ом.<br><br>Если нет, ну дефрагментацию базы какую ни то сделай. Индексы, может быть...<br><br>pg_dump умеет выносить только таблицу целиком. Отсюда: дапмпить не все таблицы (только маленькие, если это допустимо) существенно быстрее (схему лучще сохранять целиком - взаимозависимости о частям могут не срастись по-лёгкому). Больую(-ие) тадлицы либо дампить _реже