The OpenNET Project: Ускорение загрузки дампа PostgreSQL на многоядерных системах

Ускорение загрузки дампа PostgreSQL на многоядерных системах	[исправить]
В бета версии PostgreSQL 8.4 в утилите pg_restore появилась поддержка возможности загрузки дампа в несколько параллельных потоков. Например, загрузка дампа базы размером 300 Гб на 8-ядерном сервере занимала стандартным образом 12 часов, при распараллеливании процесса загрузки на 8 потоков, время загрузи сократилось до 3 часов. Полная перезагрузка дампа базы может понадобиться например при миграции с PostgreSQL 8.2 на 8.3 или при переходе с 32- на 64-разрядную сборку системы. Огромным плюсом является и то, что параллельный вариант pg_restore из ветки 8.4 прекрасно работает с ветками 8.2 и 8.3. Рассмотрим процесс миграции с 8.2 на 8.3. На рабочей машине дополнительно установим в отдельную директорию бета версию 8.4: ./configure --prefix=/usr/local/pgsql84 make make install Создаем дамп работающей базы PostgreSQL 8.2, использую утилиту pg_dump из состава PostgreSQL 8.3: /usr/local/pgsql83/bin/pg_dump -F c -v -f my_db.dump my_database В зависимости от конфигурации дополнительно может потребоваться сделать дамп ролей: /usr/local/pgsql83/bin/pg_dumpall -g -f my_roles.dump Восстанавливаем роли: /usr/local/pgsql83/bin/psql -f my_roles.dump postgres Запускаем процесс параллельного восстановления базы, число потоков задается через опцию -j, в нашем случае используется загрузка в 8 потоков. При указании большого числа потоков нужно быть уверенным, что система ввода/вывода не окажется узким местом, т.е. база размещена на высокопроизводительном хранилище: /usr/local/pgsql84/bin/pg_restore -F c -j 8 -v -C -f my_db.dump Дополнительно можно упомянуть, что в рамках проекта EnterpriseDB ведется разработка утилиты pg_migrator (http://pgfoundry.org/projects/pg-migrator/), позволяющей осуществлять перенос базы на новый сервер без остановки работы СУБД. Но pg_migrator к сожалению находится еще на стадии альфа тестирования. Некоторые советы по оптимизации процесса создания дампа и его восстановления: * Во время восстановления можно отключить fsync режим и autovacuum, значительно увеличить размер памяти (до 1 Гб если памяти много), заданный в параметрах конфигурации work_mem и maintenance_work_mem, при этом размер wal_buffers и checkpoint_segments также нужно увеличить до 16 или 32 Мб; * При наличии больших GIN или GiST индексов, время восстановления которых нередко занимает 75% от всего времени восстановления, если без этих индексов можно себе позволить немного поработать, имеет смысл разделить процесс восстановления на две стадии: восстановление первичных данных, запуск БД в продакшин, восстановление GIN или GiST индексов уже на работающей базе. * Всегда следует использовать pg_dump из более новой версии PostgreSQL, а не из старой, апгрейд которой производится. * Для продакшин систем, время и наличие возможных подводных камней стоит предварительно оценить, выполнив тестовые dump/restore без остановки первичной базы;


14.05.2009 , Источник: http://it.toolbox.com/blogs/databas... Ключи: postgresql, dump, restore, upgrade, tune, optimization, speed / Лицензия: CC-BY
Раздел: Корень / Программисту и web-разработчику / SQL и базы данных / PostgreSQL специфика / Оптимизация и администрирование PostgreSQL

Обсуждение

[ Линейный режим | Показать все | RSS ]

1.1, pavlinux (ok), 02:01, 14/05/2009 [ответить] [﹢﹢﹢] [ · · · ] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]

+/–

Звиняйте, но в исходниках написано

/*
03482  * Restore a single TOC item in parallel with others
03483  *
03484  * this is the procedure run as a thread (Windows) or a
03485  * separate process (everything else).
03486  */

Про cpu_affinity/irq_affinity/cpu_mask там ни слова.

Так что, многозадачность != многопроцессорность

2.3, Аноним (-), 12:35, 14/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
> Про cpu_affinity/irq_affinity/cpu_mask там ни слова. > Так что, многозадачность != многопроцессорность Ваша операционная система сама не в состоянии равномерно распределить нагрузку по процессорам ? как интересно... :)

3.4, pavlinux (ok), 16:24, 14/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]

+/–

>> Про cpu_affinity/irq_affinity/cpu_mask там ни слова.
>> Так что, многозадачность != многопроцессорность
>
>Ваша операционная система сама не в состоянии равномерно распределить нагрузку по процессорам ? как интересно... :)

Процессы в SMP системе - стадо тупых мамонтов - идут равномерно, а не отдельно мелкие детишки, отдельно самцы с 5-метровыми бивнями, дабы случайно не придавили мелких.

К примеру, в последних RealTime патчах, все ядреные процессы работают на 0 CPU,
но остальные, так же, равномерно раскидываются.

Не изучал на предмет динамической балансировки, но по-моему, её в ядре нет.
Как при создании треда/форка/потока присвоился процессор/ядро, так он и не меняется до смерти. /* FIXME */

Есть утиль taskset - но это не динамика. :(

4.5, cubite (?), 18:19, 14/05/2009 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]

+/–

следует понимать, о linux-ядре идет речь?

Предположим, имеем 2 ядра и 2 процесса, каждый из которых работает на "своем" ядре и пожирает 100% процессорного времени.
Появляется 3-тий процесс, который в равной степени претендует на процессорное время. Т.е. на одном из ядер будем иметь load averages примерно 2.0.

Не верится, что при завершении процесса, который самолично занимает одно ядро, на освободившееся ядро не будет перекинут один из оставшихся процессов.

5.6, pavlinux (ok), 21:21, 14/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]

+/–

Чей-та я тебя не пойму, по сему сокращу

Не верится,... что не будет перекинут... .

То есть перекинется?

4.7, Вовчик (?), 23:14, 14/05/2009 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
Всё это звучит очень хорошо, но какое отношение оно имеет к данной теме? На многопроцессорной машине не будет прироста производительности при использовании многопоточности/многопроцессности в pg_restore?

5.8, Аноним (-), 23:38, 14/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
Да нет, народ просто выпендривается не понимая что они щас клоуны на весь рунет. Спорить про потоки любимая для многих тема, даже если они не понимают о каких потоках речь. Таких хлебом не корми, дай поспорить что круче-pthread_start или fork безотносительно к задаче. Для Ъ объясню: тут о потоках данных речь а не о scheduling entities ядра.

6.9, pavlinux (ok), 01:24, 15/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]

+/–

>Да нет, народ просто выпендривается не понимая что они щас клоуны на
>весь рунет. Спорить про потоки любимая для многих тема, даже если
>они не понимают о каких потоках речь. Таких хлебом не корми,
>дай поспорить что круче-pthread_start или fork безотносительно к задаче.
>
>Для Ъ объясню: тут о потоках данных речь а не о scheduling
>entities ядра.

Ну тогда 20 раз перечитай заголовок -
"Ускорение загрузки дампа PostgreSQL на многоядерных системах"

Прочёл? - Ни слова о многопоточности.

Собственно к чему это я, да к тому, что как фишка ляжет,
так ядро и распределит потоки/процессы, обычно равномерно,
но не уверен что тоже самое будет на системе, которая
дышит под нагрузкой в 64K соединений.

7.10, Аноним (-), 08:46, 15/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
64к соединений к постгресу? :) Сразу видно что ты с ним боевого опыта не имел. Спроси любого dba, он скажет что стока соединений держать нельзя, это неэффективно в силу целого ряда причин. Такому кол-ву транзакций постгрес точно не обрадуется.

7.11, Вовчик (?), 11:05, 15/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
Я перечитал заголовок... На многоядерной системе при восстановлении в один поток можно упереться в возможности одного ядра/процессора, а при многих потоках/процессах вероятно этого не произойдёт и нагрузка распределится более равномерно. Поправь меня, если я ошибаюсь, или прекрати разводить флейм.

8.12, pavlinux (ok), 15:12, 15/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
Все гораздо веселее В ядре есть так называемые Области планирования - логич... текст свёрнут, показать

9.13, Вовчик (?), 15:22, 15/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
Упоминание о linux я нашёл только в твоих сообщениях Есть другие ядра Почита... текст свёрнут, показать

9.14, Одмин (?), 15:28, 15/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
Если нет свободных ядер то облом в любом случае Даже ежу в этом топике ясно что... текст свёрнут, показать

10.15, pavlinux (ok), 15:39, 15/05/2009 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
А свободный может быть и один ... текст свёрнут, показать

1.2, pavlinux (ok), 02:04, 14/05/2009 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]	+/–
Тут http://doxygen.postgresql.org/pg__restore_8c.html и дальше по коду

игнорирование участников | лог модерирования

Добавить комментарий

Имя:
E-Mail:
Заголовок:
Текст: