InterBase2009 и SMP
InterBase2009 и SMP
Установлен сервер IB SMP.2009.v9.0.3.437, лицензия на 16 процесооров.
Как заявлено в документации: сервер с поддержкой многопроцессорной обраотки!
Реально на машине ОС Server 2008 R2 x64 грузится только одно ядро из 16 на 100%! и получаю общую загрузку сервера в 6%!
При параллельном запросе с другой машины, нагрузка ложится на другое ядро, таки образом общая загрузка получается 12% и т.д.
У меня же задача, всю вычислительную мощность бросить на одну задачу! Чтобы запрос не 7 минут общитывался, а в 16 раз быстрее!
Подскажите, пожалуйста, как можно этого добиться!
Как заявлено в документации: сервер с поддержкой многопроцессорной обраотки!
Реально на машине ОС Server 2008 R2 x64 грузится только одно ядро из 16 на 100%! и получаю общую загрузку сервера в 6%!
При параллельном запросе с другой машины, нагрузка ложится на другое ядро, таки образом общая загрузка получается 12% и т.д.
У меня же задача, всю вычислительную мощность бросить на одну задачу! Чтобы запрос не 7 минут общитывался, а в 16 раз быстрее!
Подскажите, пожалуйста, как можно этого добиться!
Re: InterBase2009 и SMP
можно, конечно, совсем не читать документацию, но лучше так не делать.Реально на машине ОС Server 2008 R2 x64 грузится только одно ядро из 16 на 100%!
В ibconfig параметр cpu_affinity выставьте.
Если после установки параметра (и рестарта IB) так и будет использоваться одно ядро, то значит, что
- у вас лицензия не smp
- лицензии на доп. процессоры не установлена.
серверная SMP-лицензия работает на 8 ядрах. Для еще 8 ядер нужно докупать процессорые лицензии. Если я правильно помню, у 2009 были только доп. лицензии по 2 ядра, соответственно, к серверной smp докупается 4 процессорных лицензии. Сверьтесь с тем, что куплено.
ничего не выйдет. в smp распараллеливаются только конкурирующие запросы (коннекты), поэтому запрос как 7 минут обрабатывался, так и будет. Зато 2 и более клиентов будут так же выполнять запрос по 7 минут, а не 14, 21 минуту и т.д.У меня же задача, всю вычислительную мощность бросить на одну задачу! Чтобы запрос не 7 минут общитывался, а в 16 раз быстрее!
Вообще 7 минут на запрос - зависит и от запроса, и от дисковой подсистемы. Если у вас хреновые диски (или не настроены), то процессоры и ядра не помогут.
В общем, учиться и учиться.
Re: InterBase2009 и SMP
Смотрел я документацию перед теа как написать! Насколько я понял параметр cpu_affinity принудительно выставляет на каком ядре или ядрах будет работать ИБ сервер. Но опять же, как Вы сказали, именно для конкурирующих сессий.
Мне же, повторюсь, надо чтобы одна задача распаралеливалась желательно на все ядра сервера. Поясню почему: клиентов немного ~20, БД крошечная ~30 мб, все клиенты работают на регистрацию, им ресурсы практически не важны, достаточно было бы и целерончика древнего для комфорта! но есть одна процедурка с очень замудреным мат аппаратом, не важно каким, и надо чтобы один клиент мог эту процедурку переодически выполнять и как можно меньше времени ждать обсчета!
Вопросы оптимизации тут обсуждать не будем, отдельная тема и уже много чего по этому поводу было сделано.
Очень уж хочется заставить трудиться эту процедурку сразу на всей вычислительной мощи! В конце концов сервак для этого купили и не самый простой: два Xeon 5620 по 2.4гГц. А при таком раскладе смысла от него нет.
Мне же, повторюсь, надо чтобы одна задача распаралеливалась желательно на все ядра сервера. Поясню почему: клиентов немного ~20, БД крошечная ~30 мб, все клиенты работают на регистрацию, им ресурсы практически не важны, достаточно было бы и целерончика древнего для комфорта! но есть одна процедурка с очень замудреным мат аппаратом, не важно каким, и надо чтобы один клиент мог эту процедурку переодически выполнять и как можно меньше времени ждать обсчета!
Вопросы оптимизации тут обсуждать не будем, отдельная тема и уже много чего по этому поводу было сделано.
Очень уж хочется заставить трудиться эту процедурку сразу на всей вычислительной мощи! В конце концов сервак для этого купили и не самый простой: два Xeon 5620 по 2.4гГц. А при таком раскладе смысла от него нет.
Re: InterBase2009 и SMP
именно так. Распараллеливать запрос InterBase не умеет. Вообще не всякие задачи и запросы могут быть распараллелены даже на 2, не говоря про 16 ядер.Но опять же, как Вы сказали, именно для конкурирующих сессий.
купите Оракл с Parallel Query Option.Мне же, повторюсь, надо чтобы одна задача распаралеливалась желательно на все ядра сервера.
если база 30 мег, то она вся и всегда в памяти. я не верю, чтобы можно было по такой базе написать запрос, выполняющийся 7 минут (впрочем, верю, и могу сам постараться такое написать, но так писать не надо). Значит, речь идет не о запросе, а действительно о вычислениях. А СУБД, вообще-то, для вычислений не предназначена.но есть одна процедурка с очень замудреным мат аппаратом, не важно каким, и надо чтобы один клиент мог эту процедурку переодически выполнять и как можно меньше времени ждать обсчета!
Пишите udf, в которой распараллеливайте вычисления сколько угодно, потом эту udf вызывайте.
Но вообще у вас смутные впечатления о распараллеливаемости. Даже если задача сугубо вычислительная, и ее УДАСТСЯ распараллелить, разведение ее по 16 ядрам не даст ускорения в 16 раз. Хорошо если в 8, а в реале и 6 было бы неплохо.
Re: InterBase2009 и SMP
Ясно, жаль что ИБ не могут научить это делать! Согласитесь, было бы здорово иметь возможность самому указывать какому запросу (или клиенту) на каких ресурсах работать!
Возможно, тогда бы, в моем случае, можно было бы все 20 клиентов-регистраторов обрабатывать на одном ядре, а остальные - 15 выделить именно под ту хитроумную процедурку Вип клиента!;)
Покупать Оракл не представляется возможным.
Писать УДФ, видимо - идея, но пока тоже смутно обозримая;) Процедурка эта выдает около 60ти параметров, и для ее работы - в ней же чз Селект запрашивается не меньше, причем, это получаются массивы данных. Как их передать в УДФ? (вот хотябы первая, как мне кажется трудность).
А про ускорение обработки в 16 раз - это же ИДЕАЛ!;) В 6-8 раз было бы не плохо!
Спасибо kdv!
Возможно, тогда бы, в моем случае, можно было бы все 20 клиентов-регистраторов обрабатывать на одном ядре, а остальные - 15 выделить именно под ту хитроумную процедурку Вип клиента!;)
Покупать Оракл не представляется возможным.
Писать УДФ, видимо - идея, но пока тоже смутно обозримая;) Процедурка эта выдает около 60ти параметров, и для ее работы - в ней же чз Селект запрашивается не меньше, причем, это получаются массивы данных. Как их передать в УДФ? (вот хотябы первая, как мне кажется трудность).
А про ускорение обработки в 16 раз - это же ИДЕАЛ!;) В 6-8 раз было бы не плохо!
Спасибо kdv!
Re: InterBase2009 и SMP
а откуда убеждение, что эту процедуру вообще можно распараллелить?
Re: InterBase2009 и SMP
Если внимательно прочитаешь, убеждений нет, есть одни желания!)
Re: InterBase2009 и SMP
как я уже писал, нужно понимать, что может распараллеливаться, а что нет, и как распараллелить распараллеливаемое. Желание чтобы нечто выполнялось сразу на нескольких ядрах параллельно - как минимум выглядит наивно.