В бета версии 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 без остановки первичной базы;
URL: http://it.toolbox.com/blogs/database-soup/using-84-parallel-...
Обсуждается: http://www.opennet.ru/tips/info/2067.shtml
Звиняйте, но в исходниках написано/*
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 там ни слова.
Так что, многозадачность != многопроцессорность
> Про cpu_affinity/irq_affinity/cpu_mask там ни слова.
> Так что, многозадачность != многопроцессорностьВаша операционная система сама не в состоянии равномерно распределить нагрузку по процессорам ? как интересно... :)
>> Про cpu_affinity/irq_affinity/cpu_mask там ни слова.
>> Так что, многозадачность != многопроцессорность
>
>Ваша операционная система сама не в состоянии равномерно распределить нагрузку по процессорам ? как интересно... :)Процессы в SMP системе - стадо тупых мамонтов - идут равномерно, а не отдельно мелкие детишки, отдельно самцы с 5-метровыми бивнями, дабы случайно не придавили мелких.
К примеру, в последних RealTime патчах, все ядреные процессы работают на 0 CPU,
но остальные, так же, равномерно раскидываются.Не изучал на предмет динамической балансировки, но по-моему, её в ядре нет.
Как при создании треда/форка/потока присвоился процессор/ядро, так он и не меняется до смерти. /* FIXME */Есть утиль taskset - но это не динамика. :(
следует понимать, о linux-ядре идет речь?Предположим, имеем 2 ядра и 2 процесса, каждый из которых работает на "своем" ядре и пожирает 100% процессорного времени.
Появляется 3-тий процесс, который в равной степени претендует на процессорное время. Т.е. на одном из ядер будем иметь load averages примерно 2.0.Не верится, что при завершении процесса, который самолично занимает одно ядро, на освободившееся ядро не будет перекинут один из оставшихся процессов.
Чей-та я тебя не пойму, по сему сокращуНе верится,... что не будет перекинут... .
То есть перекинется?
Всё это звучит очень хорошо, но какое отношение оно имеет к данной теме?
На многопроцессорной машине не будет прироста производительности при использовании многопоточности/многопроцессности в pg_restore?
Да нет, народ просто выпендривается не понимая что они щас клоуны на весь рунет. Спорить про потоки любимая для многих тема, даже если они не понимают о каких потоках речь. Таких хлебом не корми, дай поспорить что круче-pthread_start или fork безотносительно к задаче.Для Ъ объясню: тут о потоках данных речь а не о scheduling entities ядра.
>Да нет, народ просто выпендривается не понимая что они щас клоуны на
>весь рунет. Спорить про потоки любимая для многих тема, даже если
>они не понимают о каких потоках речь. Таких хлебом не корми,
>дай поспорить что круче-pthread_start или fork безотносительно к задаче.
>
>Для Ъ объясню: тут о потоках данных речь а не о scheduling
>entities ядра.Ну тогда 20 раз перечитай заголовок -
"Ускорение загрузки дампа PostgreSQL на многоядерных системах"Прочёл? - Ни слова о многопоточности.
Собственно к чему это я, да к тому, что как фишка ляжет,
так ядро и распределит потоки/процессы, обычно равномерно,
но не уверен что тоже самое будет на системе, которая
дышит под нагрузкой в 64K соединений.
64к соединений к постгресу? :) Сразу видно что ты с ним боевого опыта не имел. Спроси любого dba, он скажет что стока соединений держать нельзя, это неэффективно в силу целого ряда причин. Такому кол-ву транзакций постгрес точно не обрадуется.
Я перечитал заголовок...На многоядерной системе при восстановлении в один поток можно упереться в возможности одного ядра/процессора, а при многих потоках/процессах вероятно этого не произойдёт и нагрузка распределится более равномерно. Поправь меня, если я ошибаюсь, или прекрати разводить флейм.
>На многоядерной системеВсе гораздо веселее :)
В ядре есть так называемые "Области планирования" - логическое множество процессоров.
Например на 4-х процессорной системе - это множество с двумя подмножествами, по два CPU в каждом.С ними работает функция schedule() далее schedule_tick(), которая вызывает rebalance_tick()
та смотрит флаги SCHED_IDLE или NOT_IDLE и на основании их вызывает load_balance();Вывод: Планировщику на...ать на процессы, он присвоит процессу первый свободный CPU
P.S. Если процесс не запускать со специально сформированым флагом CPU_MASK,
который явно ограничит область планирования для процесса, вплоть до одного CPU.
P.P.S.1. Утиль pg_restore с флагом -j n - создаст n процессов для работы с базой.
2. Эти процессы равномерно распределятся относительно ОБЩЕЙ нагрузки системы
3. Но не обязательно, распределятся, раздельно на каждый процессор.
Упоминание о linux я нашёл только в твоих сообщениях. Есть другие ядра...
Почитай статью, она не о планировщике.Все твои твои сообщения в этом треде выглядят как "я видел исходники, но не понимаю о чем все здесь пишут".
Если нет свободных ядер то облом в любом случае. Даже ежу в этом топике ясно что ускорение будет только если есть свободные ресурсы сразу на нескольких ядрах.Ну и что что первый свободный присвоит. Главное что свободный.
>Ну и что что первый свободный присвоит. Главное что свободный.А свободный может быть и один :)
Тут http://doxygen.postgresql.org/pg__restore_8c.html и дальше по коду