Postgresql, многоядерность.

1 запрос == 1 поток. Если ты запустишь 10 запросов, будет 10 потоков и 10 ядер.

а как 1 SELECT будет занимать больше 1 ядра?

А как он делает это на МСsql?

Смотря на чем висит процесс если на ожидании I/O то какая разница сколько у тебя ядер.

а вот чудесный вопрос. я даже запросил бы пруф с 1 жирненьким селектом, который распараллелится.

Если ядро в 100% уходит, очевидно что его производительности не достаточно для этого селекта.

а я и не спорю. как параллелить то? если на 100 процентов грузит, то либо ждать, либо руки из задницы пересаживать и переписывать запрос.

Этот же запрос отрабатывает в 8-10 раз быстрее на слабом железе.

Индексные ключи выставлены по таблицам?

https://wiki.postgresql.org/wiki/Parallel_Query_Execution

Постгрес тюнил на использование памяти?

Ну немного. Сейчас занимаюсь конкретно. Из-за не настроенной памяти могут быть траблы описанные мной в начале поста?

ммммм. а кто-нибудь ваще переписывал БД под MT ? :)

А постгря с патчами от 1С?

Сделай этот же селект, только руками, будет разница ?
Еще как вариант тупит винт, посмотри может идет ребилд массива или есть битые сектора, пройдись викторией.

Версия PostgreSQL (1C-патченая?)? Версия платформы? Разрядность? Что за конфигурация и какой объем БД? Какое железо? Тест Гилёва на сервере проводили?

Вот еще можете попробовать потюнить сам PostgreSQL. Но этот скрипт у меня рассчитан на сервер, где крутиться один PostgreSQL, сам кластер 1С на соседнем работает.

Нужно профайлером посмотреть что за запросы бегут на сервер. Хорошая книжка по тюнингу слона тут.

Нужно профайлером посмотреть что за запросы бегут на сервер

абсолютно бесполезно, увидев хоть раз запрос 1С сразу хочется их развидеть...

LOG: duration: 15998.049 ms statement: DELETE FROM _CRgActP657 WHERE EXISTS( SELECT 1 FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL INNER JOIN (SELECT T4._RecorderTRef AS RecorderTRef, T4._RecorderRRef AS RecorderRRef, T4._LineNo AS LineNo_ FROM _CRgActP657 T4 INNER JOIN tt2967 T5 ON T4._RecorderTRef = T5._RecorderTRef AND T4._RecorderRRef = T5._RecorderRRef AND T4._LineNo = T5._LineNo LIMIT 100000) T3 ON _CRgActP657._RecorderTRef = T3.RecorderTRef AND _CRgActP657._RecorderRRef = T3.RecorderRRef AND _CRgActP657._LineNo = T3.LineNo_ WHERE _CRgActP657._RecorderTRef = T3.RecorderTRef AND _CRgActP657._RecorderRRef = T3.RecorderRRef AND _CRgActP657._LineNo = T3.LineNo_)

и это еще не самый страшный... причем как заметно выполнялся 16сек, после установки серверного ключа выполняется намного быстрее.

для проверки скорости можно запускать тест гилева, как уже много раз писалось на всяких 1С ресурсах: 1С гоняет большие объемы не оптимизированных данных в памяти, так что берите процессор ++3.5Гц + память DDR4-2100 и выше и 40 попугаев вам будет обеспечено.

С дефолтной установкой у меня, насколько помню, тоже еле шевелилось.

postgreSQL с сайта 1С, 8.3.6, x64, Конфигурация почти самопал, размер .dt файла 110 Гб, Железо - 2x6 ядер Xeon (какой точно не скажу, но не старый), все стоит на 10 аппаратном RAID.

На хосте только pg или всё скопом с сервером 1С?

Все скопом. Но проц в простое, память свободна, диск в простое. По этому мануалу произвел настройку. Разница есть, но не большая. Все равно все очень медленно. Запользовал pgtune - так же, разницы почти никакой. При любом тыке в интерфейс С-ки в процессах висит SELECT и жрет одно ядро в 100%

При любом тыке в интерфейс С-ки в процессах висит SELECT и жрет одно ядро в 100%

Блжад. Неужели сложно сделать explain analyze?

У тебя сервер с ключём?
Сколько процессов?

Ключ по сети раздает другая машина. Процессов 1с приложения? Я один сейчас сижу, по разному от 2 до ~20

Гилев показывает 12.9 G1C тест в процессе.

Ключ по сети раздает другая машина.

Ключ серверный может быть установлен только локально.
В сервер со всем этим добром HASP воткнут?
Программных лицензий на него раньше не было.

Нет, не воткнут.

Тогда там у тебя ОДИН рабочй процесс.
А учитывая что 8.3 не даёт регулировать рабочие потоки, ещё и ОДИН рабочий поток.
Втыкай ключ.

Если будет ключ, будет несколько рабочих процессов, соотв будет несколько процессов которые будут инициировать несколько одновременных запросов в БД? Где можно почитать о том, что Вы говорите? Про процесс и поток?

Кстати сервер 1С приложения стоит в LXC контейнере. Нормально ключ работает, не в курсе?

Я не знаю как туда USB прокидывать, на XEN'е 8.2 сервер работал нормально.

Если будет ключ, будет несколько рабочих процессов, соотв будет несколько процессов которые будут инициировать несколько одновременных запросов в БД?

Вестимо, да.
Не стоит забывать, что 1С пилят, в первую очередь под M$SQL, с грехом-пополам переводя это на pg, и полуая в результате откровенную наркоманию в запросах.

Где можно почитать о том, что Вы говорите? Про процесс и поток?

Я читал кучу мелких источников, в том числе гилёва, мисту и вот тут кастовал вопросы.
Думаю, поиск в любимом se по запросу «сервер 1с процесс поток linux» поможет сориентироваться.

Ну про наркоманию не спорю, но живых примеров удачных внедрений уже очень много.

если у тебя конфа не дефолтная, там запросы могут быть сильно на T-SQL завязаны.

Торговля но переделанная на 90%. T-SQL вроде не использовали.

Была похожая проблема. Возможно проц не на полную работает. Попробуй CPU frequency scaling на performance переключить. В убунте пакет cpufrequtils.