Работа InterBase на многопроцессорной машине.
Работа InterBase на многопроцессорной машине.
Наша товароучетная программа работает на InterBase. Недавно поставили новый сервер: два Xeon 2,8 и Windows 2000 Server. В винде показывается 4 процессора, когда работает программа загружен только один в итоге общая загрузка 25%, как загрузить все четыре процессора?
для InterBase 7.0/7.1/7.5 - купить нужное число процессорных лицензий. 1, 2 или 3. По $990 за штуку.
Для остальных InterBase - ничего не делать. многопроцессорность в 6.0 будет поддерживать только Classic, на Linux, причем 6.0 использовать крайне не рекомендуется по причине его старости.
Hyperthreading для сервера тоже не очень рекомендуется. см. статью на сайте про это.
Для остальных InterBase - ничего не делать. многопроцессорность в 6.0 будет поддерживать только Classic, на Linux, причем 6.0 использовать крайне не рекомендуется по причине его старости.
Hyperthreading для сервера тоже не очень рекомендуется. см. статью на сайте про это.
-
- Сообщения: 9
- Зарегистрирован: 04 янв 2005, 17:25
Re: Работа InterBase на многопроцессорной машине.
Yaffil Classic, причем бесплатноpekalnik писал(а):Наша товароучетная программа работает на InterBase. Недавно поставили новый сервер: два Xeon 2,8 и Windows 2000 Server. В винде показывается 4 процессора, когда работает программа загружен только один в итоге общая загрузка 25%, как загрузить все четыре процессора?

-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Почему вечно все отправляют к classic? Не поддерживает многопроцессорность FB, ни super, ни классик. Загрузка процессора будет все равно 25% с любой архитектурой сервера.Ivan_Pisarevsky писал(а):fb 1.5.2 classic религия не позволяет? тож кстати бесплатно
Вот операционная система smp поддерживает -- по-этому может разные процессы раскидывать по разным процессорам.
И выгода по-этому будет только при нескольких коннектах. Это заслуга ОС -- не сервера БД.
Вот когда конкретный запрос будет выполняться раза в 1.5 побыстрее на 2-х проц. машине по сравнению с 1-проц. -- вот тогда можно будет говорить о том, что сервер БД поддерживает многопроцессорность.
Не надо прописные истины в форум писать!!!jake писал(а):Почему вечно все отправляют к classic? Не поддерживает многопроцессорность FB, ни super, ни классик. Загрузка процессора будет все равно 25% с любой архитектурой сервера.Ivan_Pisarevsky писал(а):fb 1.5.2 classic религия не позволяет? тож кстати бесплатно
Вот операционная система smp поддерживает -- по-этому может разные процессы раскидывать по разным процессорам.
И выгода по-этому будет только при нескольких коннектах. Это заслуга ОС -- не сервера БД.
И будет тогда и ОС и Сервер всё в одном флаконе!!!Вот когда конкретный запрос будет выполняться раза в 1.5 побыстрее на 2-х проц. машине по сравнению с 1-проц. -- вот тогда можно будет говорить о том, что сервер БД поддерживает многопроцессорность.
Только кому такой монстр нужен???
Мне кажется, не надо людей в заблуждение вводить...McArty писал(а):Не надо прописные истины в форум писать!!!
Человек спрашивает: " В винде показывается 4 процессора, когда работает программа загружен только один в итоге общая загрузка 25%, как загрузить все четыре процессора?"
Ему в ответ -- ставь ксассик, типа он многопроцессорность поддерживает...
По-моему будет тогда сервер БД, поддерживающий SMP. На мой взгляд нужен он многим. И, насколько мне известно, работы в этом направлении ведутся...И будет тогда и ОС и Сервер всё в одном флаконе!!!
Только кому такой монстр нужен???
это распараллеливание запросов. Есть например в oracle и informix, и вроде в MS SQL. но при покупке специальных версий этих серверов или специальных "пакетов" к этим серверам. причем распараллеливается не абы какой запрос, а написанный специально, по определенным образом подготовленным данным. Поэтому рекомендую забить на подобное восприятие "многопроцессорности". Сервер, поддерживая многопроцессорность, в первую очередь должен уметь раскидывать запросы клиентов по разным процессорам.Вот когда конкретный запрос будет выполняться раза в 1.5 побыстрее на 2-х проц. машине по сравнению с 1-проц. -- вот тогда можно будет говорить о том, что сервер БД поддерживает многопроцессорность.
Интересно. А какой вариант многопроцессорности разрабатывается в рамках Vulkan? Раскидываение разных запросов по разным процессорам? Я то почему-то думал, что будет именно так, как я писал выше...kdv писал(а):это распараллеливание запросов. Есть например в oracle и informix, и вроде в MS SQL. но при покупке специальных версий этих серверов или специальных "пакетов" к этим серверам. причем распараллеливается не абы какой запрос, а написанный специально, по определенным образом подготовленным данным. Поэтому рекомендую забить на подобное восприятие "многопроцессорности". Сервер, поддерживая многопроцессорность, в первую очередь должен уметь раскидывать запросы клиентов по разным процессорам.
разумеется. в FB до сих пор супер не распараллеливаемый.А какой вариант многопроцессорности разрабатывается в рамках Vulkan? Раскидываение разных запросов по разным процессорам?
Я то почему-то думал, что будет именно так, как я писал выше.
"Милай, каму ета нать"?

я еще раз подчеркиваю, что написать распараллеливаемый пример Demos/Threads - не проблема. Ты попробуй "распараллелить"
select * from table. Распараллелить вообще-то можно две операции, результат которых объединяется тем или иным образом. например информикс может распараллелить
select * from table
where y = 1999 or y = 2002
только если таблица сегментирована по данному условию.
Последний раз редактировалось kdv 28 фев 2005, 11:17, всего редактировалось 1 раз.