Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
 Задействование нескольких процессоров  [new]
primarykey
Member

Откуда:
Сообщений: 21
Здравствуйет!
Хочу уточнить.
При обычном SELECT * FROM table; запросе используется на 100% только одно ядро процессора, остальные не испльзуются. Сейчас у меня версия PostgreSQL9.0x64, Win7x64, на Ubuntu таже ситуация.
Возможно ли чтобы при одном SELECT-запросе использовались более чем одно ядро процессора или в PostgreSQL один SELECT-запрос может использоватль только одно ядро? Или существует настройка, которая может запустить несколько ядер на один SELECT-запрос
5 фев 13, 16:48    [13879109]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2243
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
5 фев 13, 17:30    [13879541]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2243
Misha Tyurin,

еще можно добавить, что реализовано разделение сексканов между сессиями. но эффеткивность этого механизма тоже довольно условна
5 фев 13, 17:34    [13879590]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
примерно так
Guest
можно врукопашную
примерно так
http://blog.dezhin.net/2011/10/dblink.html
заранее определив быстрый способ сегментирования
(там правда реализована модификация, но то же можно с выборками)
5 фев 13, 18:09    [13879818]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
primarykey
Member

Откуда:
Сообщений: 21
Misha Tyurin,
Может что нибудь еще посоветуете.
У меня запись в база происходит один раз в день, т.е. она изменяется очень редко. Статичная база, если можно так сказать.
Цель моего вопроса, ускорить SELECT запросы которые обращаюся к базе, интересуют разные варианты, даже переконвертирование на другую базу, т.к. запись происходит только в PostgreSQL.
Недавно спрашивал о том, чтобы БД поместить в оперативную память, посоветовали поставить параметр shared_buffers равный величене самой БД. Сделал, как посоветовали, прирост есть, но не достаточно сильный. При выборке данных с оперативной памяти грузится только одно ядро.
Сами SELECT-запросы происход "тяжелые"(объединение нескольких больших таблиц, подсчет строк), и они пока еще не оптимизированные. Моя машина позволяет поместить всю базу в оперативную память, но вот только PostgreSQL не использует все ядра, что не очень хорошо. Мне база очень нужна для "добычи" нужных мне рабочих данных.
5 фев 13, 18:33    [13879914]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2243
тааак, ну тогда как говориться, запросы в студию)
5 фев 13, 18:37    [13879931]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
primarykey
Member

Откуда:
Сообщений: 21
примерно так
можно врукопашную
примерно так
http://blog.dezhin.net/2011/10/dblink.html
заранее определив быстрый способ сегментирования
(там правда реализована модификация, но то же можно с выборками)

Очень хороший пример для того чтобы хорошо понять, что такое plpgsql. Благодарю! Давно искал пример такого уровня.
Misha Tyurin
тааак, ну тогда как говориться, запросы в студию)

Ничего особенного в этих запросах нет.
Например один из запросов:
в базе две таблицы det, stat, "весят" 8949268480(~8,34гб), 9600090112(~8,94гб) соответсвенно.
Их "вес" определил через функцию
SELECT pg_total_relation_size('table');

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

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гб. И тут такая задача с одним ядром.
6 фев 13, 01:03    [13881379]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
primarykey
Member

Откуда:
Сообщений: 21
primarykey,

и что самое главное, что происходит очень частые запросы к базе данных.
6 фев 13, 01:07    [13881388]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 3984
primarykey
primarykey,

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


count(*) без условий... большая таблица... и частые запросы - вещи несовместимые и вам тут никаких ядер не хватит...
на практике я еще не видел задачу где count(*) подобный тому что вы написали был бы реально нужен в актуальном виде...
если же можно приблизительное значение выводить - считайте его и кешируйте... или поддерживаейте отдельно в базе в отдельной таблице триггерами.
6 фев 13, 02:46    [13881497]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
примерно так
Guest
primarykey
<>
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 по фк. ну и т.п. (т.е. чем именно занят камень при подсчёте ).


ну и последнее - такие запросы на каунт теоретически неплохо параллелятся (адитивные, перестановочные агрегаты) , сегментировние можно закладывать по тем же индексам, по которым идёт связывание. вот только если сессий у вас и так дофига - смысла в этом нет (присоединяюст к МБ, кстати).
6 фев 13, 08:26    [13881678]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
primarykey
Member

Откуда:
Сообщений: 21
примерно так
посчитайте 20лямов рэндом чтений


Что необходимо сделать, для того чтобы было последовательное чтение, а не рандомное. Это насколько сейчас понимаю необходимо отключить парметр random_page_cost(пока сейчас этот параметр протестировать не могу).
Немного информации о базе: базой пользуюсь только я один, локально, т.е. могу делать с ней что хочу.
6 фев 13, 10:59    [13882477]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2243
primarykey,

Misha Tyurin
тааак, ну тогда как говориться, запросы в студию)
6 фев 13, 13:10    [13883792]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
Misha Tyurin
Member

Откуда: Тюмень
Сообщений: 2243
запросы то надо всегда с планами (лучше explain (analyze, buffers) )
6 фев 13, 13:11    [13883809]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2888
primarykey
Что необходимо сделать, для того чтобы было последовательное чтение, а не рандомное.
кластеризовать таблицу. но это будет работать только для запросов такого типа, под который кластеризовали. и в вашем случае кажется не сработает, потому что фильтр по одной таблице и джоин со второй. то есть первую кластеризовать получится, вторую - под вопросом.
6 фев 13, 14:22    [13884589]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
Ы
Guest
primarykey
У меня запись в база происходит один раз в день.

Так посчитайте нужные вам параметры (которые все равно за сутки не изменятся) сразу после обновления и сохраните в отдельной табличке. Можно все распараллелить, если пустить запросы в разных соединениях.
7 фев 13, 03:32    [13888118]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
Warstone
Member

Откуда:
Сообщений: 4896
Блог
Можно еще на IOS'ах поиграть.
7 фев 13, 11:34    [13889358]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
primarykey
Member

Откуда:
Сообщений: 21
Ы
primarykey
У меня запись в база происходит один раз в день.

Так посчитайте нужные вам параметры (которые все равно за сутки не изменятся) сразу после обновления и сохраните в отдельной табличке. Можно все распараллелить, если пустить запросы в разных соединениях.


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

INSERT INTO tempDet
 SELECT stat.idh, stat.idp, stat.c1, stat.c2
 FROM stat;
7 фев 13, 13:30    [13890453]     Ответить | Цитировать Сообщить модератору
 Re: Задействование нескольких процессоров  [new]
primarykey
Member

Откуда:
Сообщений: 21
LeXa NalBat
primarykey
Что необходимо сделать, для того чтобы было последовательное чтение, а не рандомное.
кластеризовать таблицу. но это будет работать только для запросов такого типа, под который кластеризовали. и в вашем случае кажется не сработает, потому что фильтр по одной таблице и джоин со второй. то есть первую кластеризовать получится, вторую - под вопросом.


Пока это не мой уровень, но к этому стремлюсь)))
7 фев 13, 13:34    [13890486]     Ответить | Цитировать Сообщить модератору
Все форумы / PostgreSQL Ответить