InterBase2009 и SMP

[kaplyaas]

Установлен сервер IB SMP.2009.v9.0.3.437, лицензия на 16 процесооров.
Как заявлено в документации: сервер с поддержкой многопроцессорной обраотки!
Реально на машине ОС Server 2008 R2 x64 грузится только одно ядро из 16 на 100%! и получаю общую загрузку сервера в 6%!

При параллельном запросе с другой машины, нагрузка ложится на другое ядро, таки образом общая загрузка получается 12% и т.д.

У меня же задача, всю вычислительную мощность бросить на одну задачу! Чтобы запрос не 7 минут общитывался, а в 16 раз быстрее!

Подскажите, пожалуйста, как можно этого добиться!

[kdv]

Реально на машине ОС Server 2008 R2 x64 грузится только одно ядро из 16 на 100%!

можно, конечно, совсем не читать документацию, но лучше так не делать.
В ibconfig параметр cpu_affinity выставьте.
Если после установки параметра (и рестарта IB) так и будет использоваться одно ядро, то значит, что
- у вас лицензия не smp
- лицензии на доп. процессоры не установлена.
серверная SMP-лицензия работает на 8 ядрах. Для еще 8 ядер нужно докупать процессорые лицензии. Если я правильно помню, у 2009 были только доп. лицензии по 2 ядра, соответственно, к серверной smp докупается 4 процессорных лицензии. Сверьтесь с тем, что куплено.

У меня же задача, всю вычислительную мощность бросить на одну задачу! Чтобы запрос не 7 минут общитывался, а в 16 раз быстрее!

ничего не выйдет. в smp распараллеливаются только конкурирующие запросы (коннекты), поэтому запрос как 7 минут обрабатывался, так и будет. Зато 2 и более клиентов будут так же выполнять запрос по 7 минут, а не 14, 21 минуту и т.д.

Вообще 7 минут на запрос - зависит и от запроса, и от дисковой подсистемы. Если у вас хреновые диски (или не настроены), то процессоры и ядра не помогут.

В общем, учиться и учиться.

[kaplyaas]

Смотрел я документацию перед теа как написать! Насколько я понял параметр cpu_affinity принудительно выставляет на каком ядре или ядрах будет работать ИБ сервер. Но опять же, как Вы сказали, именно для конкурирующих сессий.
Мне же, повторюсь, надо чтобы одна задача распаралеливалась желательно на все ядра сервера. Поясню почему: клиентов немного ~20, БД крошечная ~30 мб, все клиенты работают на регистрацию, им ресурсы практически не важны, достаточно было бы и целерончика древнего для комфорта! но есть одна процедурка с очень замудреным мат аппаратом, не важно каким, и надо чтобы один клиент мог эту процедурку переодически выполнять и как можно меньше времени ждать обсчета!
Вопросы оптимизации тут обсуждать не будем, отдельная тема и уже много чего по этому поводу было сделано.
Очень уж хочется заставить трудиться эту процедурку сразу на всей вычислительной мощи! В конце концов сервак для этого купили и не самый простой: два Xeon 5620 по 2.4гГц. А при таком раскладе смысла от него нет.

[kdv]

Но опять же, как Вы сказали, именно для конкурирующих сессий.

именно так. Распараллеливать запрос InterBase не умеет. Вообще не всякие задачи и запросы могут быть распараллелены даже на 2, не говоря про 16 ядер.

Мне же, повторюсь, надо чтобы одна задача распаралеливалась желательно на все ядра сервера.

купите Оракл с Parallel Query Option.

но есть одна процедурка с очень замудреным мат аппаратом, не важно каким, и надо чтобы один клиент мог эту процедурку переодически выполнять и как можно меньше времени ждать обсчета!

если база 30 мег, то она вся и всегда в памяти. я не верю, чтобы можно было по такой базе написать запрос, выполняющийся 7 минут (впрочем, верю, и могу сам постараться такое написать, но так писать не надо). Значит, речь идет не о запросе, а действительно о вычислениях. А СУБД, вообще-то, для вычислений не предназначена.
Пишите udf, в которой распараллеливайте вычисления сколько угодно, потом эту udf вызывайте.
Но вообще у вас смутные впечатления о распараллеливаемости. Даже если задача сугубо вычислительная, и ее УДАСТСЯ распараллелить, разведение ее по 16 ядрам не даст ускорения в 16 раз. Хорошо если в 8, а в реале и 6 было бы неплохо.

[kaplyaas]

Ясно, жаль что ИБ не могут научить это делать! Согласитесь, было бы здорово иметь возможность самому указывать какому запросу (или клиенту) на каких ресурсах работать!
Возможно, тогда бы, в моем случае, можно было бы все 20 клиентов-регистраторов обрабатывать на одном ядре, а остальные - 15 выделить именно под ту хитроумную процедурку Вип клиента!;)
Покупать Оракл не представляется возможным.
Писать УДФ, видимо - идея, но пока тоже смутно обозримая;) Процедурка эта выдает около 60ти параметров, и для ее работы - в ней же чз Селект запрашивается не меньше, причем, это получаются массивы данных. Как их передать в УДФ? (вот хотябы первая, как мне кажется трудность).
А про ускорение обработки в 16 раз - это же ИДЕАЛ!;) В 6-8 раз было бы не плохо!
Спасибо kdv!

[dimitr]

а откуда убеждение, что эту процедуру вообще можно распараллелить?

[kaplyaas]

Если внимательно прочитаешь, убеждений нет, есть одни желания!)

[kdv]

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