https://www.opennet.ru/openforum/vsluhforumID3/54305.html В бета версии PostgreSQL 8.4 в утилите pg_restore появилась поддержка возможности загрузки дампа <br>в несколько параллельных потоков. Например, загрузка дампа базы размером 300 Гб на 8-ядерном сервере <br>занимала стандартным образом 12 часов, при распараллеливании процесса загрузки на 8 потоков, <br>время загрузи сократилось до 3 часов. Полная перезагрузка дампа базы может понадобиться например при миграции <br>с PostgreSQL 8.2 на 8.3 или при переходе с 32- на 64-разрядную сборку системы.<br><br>Огромным плюсом является и то, что параллельный вариант pg_restore <br>из ветки 8.4 прекрасно работает с ветками 8.2 и 8.3.<br><br>Рассмотрим процесс миграции с 8.2 на 8.3. На рабочей машине дополнительно установим в отдельную директорию бета версию 8.4:<br><br> ./configure --prefix=/usr/local/pgsql84<br> make<br> make install <br><br>Создаем дамп работающей базы PostgreSQL 8.2, использую утилиту pg_dump из состава PostgreSQL 8.3:<br><br> /usr/local/pgsql83/bin/pg_dump -F c -v -f my_db.dump my_database<br><br>В зависимости от конфигурации доп https://www.opennet.ru/openforum/vsluhforumID3/54305.html#15 Fri, 15 May 2009 11:39:06 GMT &gt;Ну и что что первый свободный присвоит. Главное что свободный. <br><br>А свободный может быть и один :)<br><br> <br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/54305.html#14 Fri, 15 May 2009 11:28:01 GMT Если нет свободных ядер то облом в любом случае. Даже ежу в этом топике ясно что ускорение будет только если есть свободные ресурсы сразу на нескольких ядрах.<br><br>Ну и что что первый свободный присвоит. Главное что свободный.<br> https://www.opennet.ru/openforum/vsluhforumID3/54305.html#13 Fri, 15 May 2009 11:22:17 GMT Упоминание о linux я нашёл только в твоих сообщениях. Есть другие ядра...<br>Почитай статью, она не о планировщике.<br><br>Все твои твои сообщения в этом треде выглядят как "я видел исходники, но не понимаю о чем все здесь пишут".<br> https://www.opennet.ru/openforum/vsluhforumID3/54305.html#12 Fri, 15 May 2009 11:12:00 GMT &gt;На многоядерной системе <br><br>Все гораздо веселее :)<br><br>В ядре есть так называемые "Области планирования" - логическое множество процессоров.<br>Например на 4-х процессорной системе - это множество с двумя подмножествами, по два CPU в каждом.<br><br>С ними работает функция schedule() далее schedule_tick(), которая вызывает rebalance_tick()<br>та смотрит флаги SCHED_IDLE или NOT_IDLE и на основании их вызывает load_balance();<br><br>Вывод: Планировщику на...ать на процессы, он присвоит процессу первый свободный CPU<br><br>P.S. Если процесс не запускать со специально сформированым флагом CPU_MASK,<br> который явно ограничит область планирования для процесса, вплоть до одного CPU.<br> <br>P.P.S. <br><br>1. Утиль pg_restore с флагом -j n - создаст n процессов для работы с базой. <br>2. Эти процессы равномерно распределятся относительно ОБЩЕЙ нагрузки системы<br>3. Но не обязательно, распределятся, раздельно на каждый процессор.<br> https://www.opennet.ru/openforum/vsluhforumID3/54305.html#11 Fri, 15 May 2009 07:05:44 GMT Я перечитал заголовок...<br><br>На многоядерной системе при восстановлении в один поток можно упереться в возможности одного ядра/процессора, а при многих потоках/процессах вероятно этого не произойдёт и нагрузка распределится более равномерно. Поправь меня, если я ошибаюсь, или прекрати разводить флейм.<br> https://www.opennet.ru/openforum/vsluhforumID3/54305.html#10 Fri, 15 May 2009 04:46:35 GMT 64к соединений к постгресу? :) Сразу видно что ты с ним боевого опыта не имел. Спроси любого dba, он скажет что стока соединений держать нельзя, это неэффективно в силу целого ряда причин. Такому кол-ву транзакций постгрес точно не обрадуется.<br> https://www.opennet.ru/openforum/vsluhforumID3/54305.html#9 Thu, 14 May 2009 21:24:07 GMT &gt;Да нет, народ просто выпендривается не понимая что они щас клоуны на <br>&gt;весь рунет. Спорить про потоки любимая для многих тема, даже если <br>&gt;они не понимают о каких потоках речь. Таких хлебом не корми, <br>&gt;дай поспорить что круче-pthread_start или fork безотносительно к задаче. <br>&gt;<br>&gt;Для Ъ объясню: тут о потоках данных речь а не о scheduling <br>&gt;entities ядра. <br><br>Ну тогда 20 раз перечитай заголовок - <br>"Ускорение загрузки дампа PostgreSQL на многоядерных системах" <br><br>Прочёл? - Ни слова о многопоточности.<br> <br>Собственно к чему это я, да к тому, что как фишка ляжет, <br>так ядро и распределит потоки/процессы, обычно равномерно, <br>но не уверен что тоже самое будет на системе, которая <br>дышит под нагрузкой в 64K соединений.<br><br> <br> <br> https://www.opennet.ru/openforum/vsluhforumID3/54305.html#8 Thu, 14 May 2009 19:38:31 GMT Да нет, народ просто выпендривается не понимая что они щас клоуны на весь рунет. Спорить про потоки любимая для многих тема, даже если они не понимают о каких потоках речь. Таких хлебом не корми, дай поспорить что круче-pthread_start или fork безотносительно к задаче.<br><br>Для Ъ объясню: тут о потоках данных речь а не о scheduling entities ядра.<br> https://www.opennet.ru/openforum/vsluhforumID3/54305.html#7 Thu, 14 May 2009 19:14:42 GMT Всё это звучит очень хорошо, но какое отношение оно имеет к данной теме?<br>На многопроцессорной машине не будет прироста производительности при использовании многопоточности/многопроцессности в pg_restore?<br>