ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Задействование нескольких процессоров
21 сообщений из 21, страница 1 из 1
Задействование нескольких процессоров
    #38138374
primarykey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
primarykey
Гость
Здравствуйет!
Хочу уточнить.
При обычном SELECT * FROM table; запросе используется на 100% только одно ядро процессора, остальные не испльзуются. Сейчас у меня версия PostgreSQL9.0x64, Win7x64, на Ubuntu таже ситуация.
Возможно ли чтобы при одном SELECT-запросе использовались более чем одно ядро процессора или в PostgreSQL один SELECT-запрос может использоватль только одно ядро? Или существует настройка, которая может запустить несколько ядер на один SELECT-запрос
...
Рейтинг: 0 / 0
05.02.2013, 16:48
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38138525
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
primarykey,

ядро одно. и это одно из центральных архитектурных мест.

1) есть вот такая фича, но она достаточно узко специализированна

effective_io_concurrency
http://www.postgresql.org/docs/9.2/static/runtime-config-resource.html

2) вам можно посоветовать лишь руками параллелить что-нибудь

dblink
plproxy

+ експорт снепшота с версии 9.2

SELECT pg_export_snapshot()
http://www.postgresql.org/docs/9.2/static/sql-set-transaction.html
...
Рейтинг: 0 / 0
05.02.2013, 17:30
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38138538
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Misha Tyurin,

еще можно добавить, что реализовано разделение сексканов между сессиями. но эффеткивность этого механизма тоже довольно условна
...
Рейтинг: 0 / 0
05.02.2013, 17:34
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38138621
примерно так
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
примерно так
Гость
можно врукопашную
примерно так
http://blog.dezhin.net/2011/10/dblink.html
заранее определив быстрый способ сегментирования
(там правда реализована модификация, но то же можно с выборками)
...
Рейтинг: 0 / 0
05.02.2013, 18:09
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38138671
primarykey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
primarykey
Гость
Misha Tyurin,
Может что нибудь еще посоветуете.
У меня запись в база происходит один раз в день, т.е. она изменяется очень редко. Статичная база, если можно так сказать.
Цель моего вопроса, ускорить SELECT запросы которые обращаюся к базе, интересуют разные варианты, даже переконвертирование на другую базу, т.к. запись происходит только в PostgreSQL.
Недавно спрашивал о том, чтобы БД поместить в оперативную память, посоветовали поставить параметр shared_buffers равный величене самой БД. Сделал, как посоветовали, прирост есть, но не достаточно сильный. При выборке данных с оперативной памяти грузится только одно ядро.
Сами SELECT-запросы происход "тяжелые"(объединение нескольких больших таблиц, подсчет строк), и они пока еще не оптимизированные. Моя машина позволяет поместить всю базу в оперативную память, но вот только PostgreSQL не использует все ядра, что не очень хорошо. Мне база очень нужна для "добычи" нужных мне рабочих данных.
...
Рейтинг: 0 / 0
05.02.2013, 18:33
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38138679
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
тааак, ну тогда как говориться, запросы в студию)
...
Рейтинг: 0 / 0
05.02.2013, 18:37
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38139195
primarykey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
primarykey
Гость
примерно такможно врукопашную
примерно так
http://blog.dezhin.net/2011/10/dblink.html
заранее определив быстрый способ сегментирования
(там правда реализована модификация, но то же можно с выборками)
Очень хороший пример для того чтобы хорошо понять, что такое plpgsql. Благодарю! Давно искал пример такого уровня.
Misha Tyurinтааак, ну тогда как говориться, запросы в студию)
Ничего особенного в этих запросах нет.
Например один из запросов:
в базе две таблицы det, stat, "весят" 8949268480(~8,34гб), 9600090112(~8,94гб) соответсвенно.
Их "вес" определил через функцию
Код: plsql
1.
SELECT pg_total_relation_size('table');


shared...buffers установлен в 22Gb. оперативной помяти для этого параметра вагон и маленькая тележка, и когда делаю простенький запрос, в котором происходит объединение двух таблиц

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT 
 count(stat.idh)
FROM 
 det, 
 stat
WHERE
 det.idpl = stat.idp
  AND
 det.flg = true
;


count == 20825767


этот обычный запрос выполняется очено долго(5мин), в диспетчере задач "потребление" оперативной памяти (при выставленном параметре random_page_cost = 2.0) показывает не более 7,3Гб.
Затем начал менять параметр random_page_cost, который при увеличинии с 2.0 до 20.0 начал занимать при этом же запросе 15гб оперативной памяти, этот параметр настраивал по этому руководству http://postgresmen.ru/articles/view/38.
При первом запуске запрос выполняет 5мин, при повторном запуске 25секунд и используется все время только одно ядро процессора.
У меня таких SELECT запросов будет несколько десятков тысяч, с разными параметрами. Генерируются эти запросы с php. Для выборки существует 60гб оперативной памяти, 12ядер(потоков). База при выборке будет иметь размер ~56гб. И тут такая задача с одним ядром.
...
Рейтинг: 0 / 0
06.02.2013, 01:03
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38139201
primarykey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
primarykey
Гость
primarykey,

и что самое главное, что происходит очень частые запросы к базе данных.
...
Рейтинг: 0 / 0
06.02.2013, 01:07
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38139238
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
primarykeyprimarykey,

и что самое главное, что происходит очень частые запросы к базе данных.

count(*) без условий... большая таблица... и частые запросы - вещи несовместимые и вам тут никаких ядер не хватит...
на практике я еще не видел задачу где count(*) подобный тому что вы написали был бы реально нужен в актуальном виде...
если же можно приблизительное значение выводить - считайте его и кешируйте... или поддерживаейте отдельно в базе в отдельной таблице триггерами.
...
Рейтинг: 0 / 0
06.02.2013, 02:46
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38139310
примерно так
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
примерно так
Гость
primarykey <>
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT 
 count(stat.idh)
FROM 
 det, 
 stat
WHERE
 det.idpl = stat.idp
  AND
 det.flg = true
;


count == 20825767


этот обычный запрос выполняется очено долго(5мин), в диспетчере задач "потребление" оперативной памяти (при выставленном параметре random_page_cost = 2.0) показывает не более 7,3Гб.
Затем начал менять параметр random_page_cost, который при увеличинии с 2.0 до 20.0 начал занимать при этом же запросе 15гб оперативной памяти, этот параметр настраивал по этому руководству http://postgresmen.ru/articles/view/38.
При первом запуске запрос выполняет 5мин, при повторном запуске 25секунд и используется все время только одно ядро процессора.
У меня таких SELECT запросов будет несколько десятков тысяч, с разными параметрами. Генерируются эти запросы с php. Для выборки существует 60гб оперативной памяти, 12ядер(потоков). База при выборке будет иметь размер ~56гб. И тут такая задача с одним ядром.
ну как бе это обычный долгоиграющий запрос практически для любых субд, не говоря о пж, где он долгоиграющ по определению. посчитайте 20лямов рэндом чтений - увидите, что всё правильно. и если все запросы будут именно "такими" - руки надо пилить архитектору, чтобы на место сталобыть приделать.


далее, если у вас не приложение для одного полтзователя - то ничего страшного. пж поднимает по процессу на сессию, и скажем 24 сессии уже вполне равномерно нагрузят ваши камни.

далее, вы не написали, сколько у вас записей в самих табличках (это у вас почти полное произведение, или сильно частичная выборка). если в таблицах записей таки изрядно больше - то есть ли соответствующие (условию связи) индексы для merge -join-a по фк. ну и т.п. (т.е. чем именно занят камень при подсчёте ).


ну и последнее - такие запросы на каунт теоретически неплохо параллелятся (адитивные, перестановочные агрегаты) , сегментировние можно закладывать по тем же индексам, по которым идёт связывание. вот только если сессий у вас и так дофига - смысла в этом нет (присоединяюст к МБ, кстати).
...
Рейтинг: 0 / 0
06.02.2013, 08:26
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38139523
primarykey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
primarykey
Гость
примерно так посчитайте 20лямов рэндом чтений


Что необходимо сделать, для того чтобы было последовательное чтение, а не рандомное. Это насколько сейчас понимаю необходимо отключить парметр random_page_cost(пока сейчас этот параметр протестировать не могу).
Немного информации о базе: базой пользуюсь только я один, локально, т.е. могу делать с ней что хочу.
...
Рейтинг: 0 / 0
06.02.2013, 10:59
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38139831
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
primarykey,

Misha Tyurinтааак, ну тогда как говориться, запросы в студию)
...
Рейтинг: 0 / 0
06.02.2013, 13:10
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38139838
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
запросы то надо всегда с планами (лучше explain (analyze, buffers) )
...
Рейтинг: 0 / 0
06.02.2013, 13:11
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38140038
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
primarykeyЧто необходимо сделать, для того чтобы было последовательное чтение, а не рандомное.кластеризовать таблицу. но это будет работать только для запросов такого типа, под который кластеризовали. и в вашем случае кажется не сработает, потому что фильтр по одной таблице и джоин со второй. то есть первую кластеризовать получится, вторую - под вопросом.
...
Рейтинг: 0 / 0
06.02.2013, 14:22
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38141000
Ы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ы
Гость
primarykeyУ меня запись в база происходит один раз в день.
Так посчитайте нужные вам параметры (которые все равно за сутки не изменятся) сразу после обновления и сохраните в отдельной табличке. Можно все распараллелить, если пустить запросы в разных соединениях.
...
Рейтинг: 0 / 0
07.02.2013, 03:32
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38141336
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Warstone
Участник
Можно еще на IOS'ах поиграть.
...
Рейтинг: 0 / 0
07.02.2013, 11:34
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38141625
primarykey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
primarykey
Гость
ЫprimarykeyУ меня запись в база происходит один раз в день.
Так посчитайте нужные вам параметры (которые все равно за сутки не изменятся) сразу после обновления и сохраните в отдельной табличке. Можно все распараллелить, если пустить запросы в разных соединениях.

Да вчера так и делал, создал две таблицы tempDet, tempStat и занес данные в них вот таким способом

Код: plsql
1.
2.
3.
INSERT INTO tempDet
 SELECT stat.idh, stat.idp, stat.c1, stat.c2
 FROM stat;
...
Рейтинг: 0 / 0
07.02.2013, 13:30
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #38141635
primarykey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
primarykey
Гость
LeXa NalBatprimarykeyЧто необходимо сделать, для того чтобы было последовательное чтение, а не рандомное.кластеризовать таблицу. но это будет работать только для запросов такого типа, под который кластеризовали. и в вашем случае кажется не сработает, потому что фильтр по одной таблице и джоин со второй. то есть первую кластеризовать получится, вторую - под вопросом.

Пока это не мой уровень, но к этому стремлюсь)))
...
Рейтинг: 0 / 0
07.02.2013, 13:34
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
Задействование нескольких процессоров
    #39890863
alltox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alltox
Гость
Добрый день! у меня в работе postgresql 11, выполняю бэкап при помощи pg_dump утилизируется всего 30%ЦП, как можно увеличить использование ЦП чтобы бэкап выполнялся быстрее?
выполняю командой
pg_dump --username=postgres --format=c --compress=9 --create my_db > my_db_${DATE}.backup
...
Рейтинг: 0 / 0
19.11.2019, 05:48
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #39890941
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
alltox
Добрый день! у меня в работе postgresql 11, выполняю бэкап при помощи pg_dump утилизируется всего 30%ЦП, как можно увеличить использование ЦП чтобы бэкап выполнялся быстрее?
выполняю командой
pg_dump --username=postgres --format=c --compress=9 --create my_db > my_db_${DATE}.backup


1)Использовать --format=d в сочетании с --jobs= (2-4-сколько надо чтобы загрузить процессоры)

2)если вы будете даже в 1 поток (т.е. как у вас) снимать бэкап с ключам --compress=2 (или 3) скорее всего он будет сниматься раза в 2-3-4 быстрее

3)если у вас старая версия базы и многопоточный backup не умеет (путь 1) - можно попробоватьс сделать фокус вида -compress=0 | pbzip2 с соответствующим ключами чтобы переделать сжатие на многопоточное внешней утилитой.

Даже с --jobs - использование --compress=9 вредно... оно делает процесс по cpu раз в 5 тяжелее за небольшой выйгрыш в сжатии... делайте --compress=2 (или 3) всегда кроме создания архивных копий которые "хранить вечно" и потому размер важен.

Вот такие 3 варианта у вас есть.
...
Рейтинг: 0 / 0
19.11.2019, 10:41
| Ответить | Цитировать | Написать  
Задействование нескольких процессоров
    #39892239
alltox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alltox
Гость
Maxim Boguk,

Спасибо за совет, попробую 1 вариант
...
Рейтинг: 0 / 0
21.11.2019, 11:19
| Ответить | Цитировать | Написать  
21 сообщений из 21, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Задействование нескольких процессоров
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38138671&tid=1994929]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 38ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 276ms
total:  415ms
созд. / загр.: 415ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]