The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Ускорение загрузки дампа PostgreSQL..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Ускорение загрузки дампа PostgreSQL..."  +/
Сообщение от auto_tips (ok) on 14-Май-09, 02:01 
В бета версии 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

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от pavlinux (ok) on 14-Май-09, 02:01 
Звиняйте, но в исходниках написано

/*
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 там ни слова.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от Аноним (??) on 14-Май-09, 12:35 
> Про cpu_affinity/irq_affinity/cpu_mask там ни слова.
> Так что, многозадачность != многопроцессорность

Ваша операционная система сама не в состоянии равномерно распределить нагрузку по процессорам ? как интересно... :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от pavlinux (ok) on 14-Май-09, 16:24 
>> Про cpu_affinity/irq_affinity/cpu_mask там ни слова.
>> Так что, многозадачность != многопроцессорность
>
>Ваша операционная система сама не в состоянии равномерно распределить нагрузку по процессорам ? как интересно... :)

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от cubite on 14-Май-09, 18:19 
следует понимать, о linux-ядре идет речь?

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от pavlinux (ok) on 14-Май-09, 21:21 
Чей-та я тебя не пойму, по сему сокращу

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от Вовчик on 14-Май-09, 23:14 
Всё это звучит очень хорошо, но какое отношение оно имеет к данной теме?
На многопроцессорной машине не будет прироста производительности при использовании многопоточности/многопроцессности в pg_restore?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от Аноним (??) on 14-Май-09, 23:38 
Да нет, народ просто выпендривается не понимая что они щас клоуны на весь рунет. Спорить про потоки любимая для многих тема, даже если они не понимают о каких потоках речь. Таких хлебом не корми, дай поспорить что круче-pthread_start или fork безотносительно к задаче.

Для Ъ объясню: тут о потоках данных речь а не о scheduling entities ядра.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от pavlinux (ok) on 15-Май-09, 01:24 
>Да нет, народ просто выпендривается не понимая что они щас клоуны на
>весь рунет. Спорить про потоки любимая для многих тема, даже если
>они не понимают о каких потоках речь. Таких хлебом не корми,
>дай поспорить что круче-pthread_start или fork безотносительно к задаче.
>
>Для Ъ объясню: тут о потоках данных речь а не о scheduling
>entities ядра.

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

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

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



Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от Аноним (??) on 15-Май-09, 08:46 
64к соединений к постгресу? :) Сразу видно что ты с ним боевого опыта не имел. Спроси любого dba, он скажет что стока соединений держать нельзя, это неэффективно в силу целого ряда причин. Такому кол-ву транзакций постгрес точно не обрадуется.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от Вовчик on 15-Май-09, 11:05 
Я перечитал заголовок...

На многоядерной системе при восстановлении в один поток можно упереться в возможности одного ядра/процессора, а при многих потоках/процессах вероятно этого не произойдёт и нагрузка распределится более равномерно. Поправь меня, если я ошибаюсь, или прекрати разводить флейм.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от pavlinux (ok) on 15-Май-09, 15:12 
>На многоядерной системе

Все гораздо веселее :)

В ядре есть так называемые "Области планирования" - логическое множество процессоров.
Например на 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. Но не обязательно, распределятся, раздельно на каждый процессор.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от Вовчик on 15-Май-09, 15:22 
Упоминание о linux я нашёл только в твоих сообщениях. Есть другие ядра...
Почитай статью, она не о планировщике.

Все твои твои сообщения в этом треде выглядят как "я видел исходники, но не понимаю о чем все здесь пишут".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от Одмин on 15-Май-09, 15:28 
Если нет свободных ядер то облом в любом случае. Даже ежу в этом топике ясно что ускорение будет только если есть свободные ресурсы сразу на нескольких ядрах.

Ну и что что первый свободный присвоит. Главное что свободный.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Ускорение загрузки дампа PostgreSQL на многоядерных системах"  +/
Сообщение от pavlinux (ok) on 15-Май-09, 15:39 
>Ну и что что первый свободный присвоит. Главное что свободный.

А свободный может быть и один :)


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Раздел полезных советов: Ускорение загрузки дампа PostgreSQL..."  +/
Сообщение от pavlinux (ok) on 14-Май-09, 02:04 
Тут  http://doxygen.postgresql.org/pg__restore_8c.html и дальше по коду
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру