Здравствуйте, chaynick, Вы писали:

C>Помогите чайнику! Имеется база изначально написаная под 1.0. В связи с тем, что многие пользователи разжились 2х процессорными серваками тестил ея под 1.5 . Все хорошо но хранимые процедуры под 1.5 выполняются в сотни раз медленее. Анализ производительности показал, что под 1.0 обращений на read к таблице 50 тыс а под 1.5 500 млн!!
C>Где копать


В очередь СД

Здравствуйте, Igor Trofimov, Вы писали:

C>>Помогите чайнику! Имеется база изначально написаная под 1.0. В связи с тем, что многие пользователи разжились 2х процессорными серваками тестил ея под 1.5 . Все хорошо но хранимые процедуры под 1.5 выполняются в сотни раз медленее. Анализ производительности показал, что под 1.0 обращений на read к таблице 50 тыс а под 1.5 500 млн!!

iT>Смотри планы запросов.

Очень интересный и содержательный ответ.

Очень не приянто, когда люди (которые думают, что они все знают) начинают довать ответы типа таких: Смотри планы, смотри доки, смотри все остальное).

Не можешь помочь человеку не лезь.

Вообщем планы эти два сервера скорее всего строят одинаково.
Дело здесь в другом:

FireBird SuperServer не поддерживает работу на двухпроцесорных машинах. Для правильной работы нужно работать на одном процессоре(принудительно указать серверу один процессор) или устанавливать interbase 7.0 или использовать архетектуру классик.

Надеюсь теперь Гиви(Чайник) тебе усе понятно. Приедем и протестируем с пивом.

Бандерлог и Агроном.

Привет, "человек без имени"!
Вы пишешь 14 апреля 2004:

[Sorry, skipped]
> FireBird SuperServer не поддерживает работу на двухпроцесорных машинах.

Поддерживает. Только тормозит

> Для правильной работы нужно работать на одном процессоре
> (принудительно указать серверу один процессор) или устанавливать interbase 7.0

Который тоже тормозит, но меньше

> или использовать архетектуру классик.

От это правильно.
Только драйверы прикупить (hands.sys) и усё будет Ок.

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

>> Для правильной работы нужно работать на одном процессоре
>> (принудительно указать серверу один процессор) или устанавливать interbase 7.0

AC>Который тоже тормозит, но меньше

>> или использовать архетектуру классик.

AC>От это правильно.
AC>Только драйверы прикупить (hands.sys) и усё будет Ок.

Саш, а причем тут кол-во обращений к таблице, как описано в исходном посте? Думаю,все же дело в запросе. Что-то не то проJOINили
Нет ли в запросах хитрых обьединений типа таблица+ХП и тому подобного?

WBR, Dmitry Beloshistov AKA [-=BDS=-]

Привет, Dmitry!
Вы пишешь 15 апреля 2004:

[Sorry, skipped]
> Саш, а причем тут кол-во обращений к таблице, как описано в исходном посте?
> Думаю,все же дело в запросе. Что-то не то про JOIN или

Да простит меня человек задавший исходный вопрос,
но имхо, там редкий пример корреляции родственников проживающих в Киеве,
с кустарником, дающим черно-фиолетовые плоды, произрастающим в огороде.

> Нет ли в запросах хитрых объединений типа таблица+ХП и тому подобного?

Сие превеликая тайна есть. И сокрыта она от глаз наших...

--
With best regards, Alex Cherednichenko.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Alex.Che, Вы писали:

>>> Для правильной работы нужно работать на одном процессоре
>>> (принудительно указать серверу один процессор) или устанавливать interbase 7.0

AC>>Который тоже тормозит, но меньше

>>> или использовать архетектуру классик.

AC>>От это правильно.
AC>>Только драйверы прикупить (hands.sys) и усё будет Ок.

А>Саш, а причем тут кол-во обращений к таблице, как описано в исходном посте? Думаю,все же дело в запросе. Что-то не то проJOINили
А>Нет ли в запросах хитрых обьединений типа таблица+ХП и тому подобного?

А>WBR, Dmitry Beloshistov AKA [-=BDS=-]

Даже если и запросы кривоваты, то никто меня не переубедит в том что 1.0 и 1.5 — имеют разные оптимизаторы, которые строят одим и тот же запрос по разному.

Все дело в ДВУХ процессорах, обращений к таблице больше из- за того, что происходит переключение задач между процессорами .

Привет, "человек без имени"!
Вы пишешь 15 апреля 2004:

[Sorry, skipped]
> Даже если и запросы кривоваты, то никто меня не переубедит в том что 1.0 и 1.5 — имеют разные оптимизаторы,
> которые строят одим и тот же запрос по разному.

Это действительно так. Ибо ядро 1.5 было существенно переработано. И оптимизатор тоже.

> Все дело в ДВУХ процессорах, обращений к таблице больше из- за того, что происходит переключение задач между процессорами .

А вот это в хумор! :lol:

--
With best regards, Alex Cherednichenko.

Привет, Alex!

AC>Да простит меня человек задавший исходный вопрос,
AC>но имхо, там редкий пример корреляции родственников проживающих в Киеве,
AC>с кустарником, дающим черно-фиолетовые плоды, произрастающим в огороде.

Угу, что-то в этом есть

>> Нет ли в запросах хитрых объединений типа таблица+ХП и тому подобного?

AC>Сие превеликая тайна есть. И сокрыта она от глаз наших...

Пример запроса в студию!

P.S. А насчет 2-х процессоров и переключений между ними — это сильно LOL
Я уж боюсь спрашивать про скази и остальное железо

WBR, Dmitry Beloshistov AKA [-=BDS=-]

Здравствуйте, Alex.Che, Вы писали:


>> Все дело в ДВУХ процессорах, обращений к таблице больше из- за того, что происходит переключение задач между процессорами .

AC>А вот это в хумор! :lol:

Я не тот аноним, которуму ты отвечал.

Но все же, тоже придерживаюсь мнения о двух и более процессорах. Зная о какой базе идет речь, запросы там строятся по первичному ключу. Такая большая разница в операциях SELECT возможно, только из-за двух процессорах. Не зря ведь для работы interbase 7.0 на двух процессорах необходимо покупать дополнительный KIT. Поэтому и предлагаеться использовать classic, что бы для каждого коннекта создавался отдельный процесс.



banderlog & agronom

Здравствуйте, Аноним, Вы писали:


>>> Все дело в ДВУХ процессорах, обращений к таблице больше из- за того, что происходит переключение задач между процессорами .

AC>>А вот это в хумор! :lol:

А>Но все же, тоже придерживаюсь мнения о двух и более процессорах. Зная о какой базе идет речь, запросы там строятся по первичному ключу.

create table Test(
ID integer not null,
MyField varchar(10));

ID — primary key.
Внимание вопрос — каким образом ID будет участвовать в запросе вида
SELECT MyField FROM Test и как сервер узнает об этом? К тому первичного ключа может не быть вовсе

A>Такая большая разница в операциях SELECT возможно, только из-за двух процессорах.

Каким образом? Процесс вместо распараллеливания операций на 2 процессора по-твоему выполняет свои операции на каждом процессоре

WBR, Dmitry Beloshistov AKA [-=BDS=-]

Здравствуйте, <Аноним>, Вы писали:
А>banderlog & agronom
Кошмар ребята. Просто кошмар. Вы что, всерьез полагаете, что добавление второго процессора способно замедлить работу interbase? И за счет чего, интересно? Да еще и количество обращений к винту радикально увеличить... Я вам настоятельно рекомендую купить какую-нибудь книжку про разработку СУБД и прочитать хотя бы бегло.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:
А>>banderlog & agronom
S>Кошмар ребята. Просто кошмар. Вы что, всерьез полагаете, что добавление второго процессора способно замедлить работу interbase? И за счет чего, интересно?

Ты будешь смеятся, но суперсервер IB, если не принимать некоторых мер, на двух процессорах действительно может работать медленее. IB до версии 7 использует только один процессор, причем упорно. А система начинает его перекидывать по разным процессорам. Вот на переключениях производительность и теряется

Здравствуйте, Romkin, Вы писали:

S>>Кошмар ребята. Просто кошмар. Вы что, всерьез полагаете, что добавление второго процессора способно замедлить работу interbase? И за счет чего, интересно?

R>Ты будешь смеятся, но суперсервер IB, если не принимать некоторых мер, на двух процессорах действительно может работать медленее. IB до версии 7 использует только один процессор, причем упорно. А система начинает его перекидывать по разным процессорам. Вот на переключениях производительность и теряется

1) Это не обьясняет увеличение кол-ва обращений к БД.
2) У человека — FB 1.5.

WBR, Dmitry Beloshistov AKA [-=BDS=-]

Здравствуйте, Romkin, Вы писали:
R>Ты будешь смеятся, но суперсервер IB, если не принимать некоторых мер, на двух процессорах действительно может работать медленее.
Буду смеяться.
R>IB до версии 7 использует только один процессор, причем упорно.
Я в курсе. И это естественно, потому что в нем только один рабочий поток.
R>А система начинает его перекидывать по разным процессорам. Вот на переключениях производительность и теряется
Не смеши мои тапочки. Ты что думаешь, если мы вытеснили поток из процессора №1, то потом восстановление его в процессор №2 займет существенно больше времени, чем в процессор №1? А вытеснение будет происходить по любому.

iT>>Смотри планы запросов.
А>Очень интересный и содержательный ответ.

Я старался.

А>Очень не приянто, когда люди (которые думают, что они все знают) начинают довать ответы типа таких: Смотри планы, смотри доки, смотри все остальное).

Если ты не видишь разницы между содержательностью ответа "смотри доки" и "смотри планы" — могу только посочувствовать.

А>Вообщем планы эти два сервера скорее всего строят одинаково.

А вот и не факт. Разное число обращений может быть вызвано тем, что второй серер строит другой план запроса.
Еще это может быть вызвано настройками кеша, например.
Но в первую очередь надо бы проверить планы.

А>Дело здесь в другом:

А>FireBird SuperServer не поддерживает работу на двухпроцесорных машинах. Для правильной работы нужно работать на одном процессоре(принудительно указать серверу один процессор) или устанавливать interbase 7.0 или использовать архетектуру классик.

)))) Насмешил! Ну как от этого может зависть число чтений с диска?

S>Кошмар ребята. Просто кошмар. Вы что, всерьез полагаете, что добавление второго процессора способно замедлить работу interbase?

Увы, это документально зафиксированный факт. Специально в первых версиях FB доделывали опцию привязки к одному процу.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Romkin, Вы писали:
R>>Ты будешь смеятся, но суперсервер IB, если не принимать некоторых мер, на двух процессорах действительно может работать медленее.
S>Буду смеяться.
R>>IB до версии 7 использует только один процессор, причем упорно.
S>Я в курсе. И это естественно, потому что в нем только один рабочий поток.

Может, ты хотел сказать все-таки "процесс"? Потому что он на каждое соединение открывает свой поток. Исключение — локальные соединения.

R>>А система начинает его перекидывать по разным процессорам. Вот на переключениях производительность и теряется
S>Не смеши мои тапочки. Ты что думаешь, если мы вытеснили поток из процессора №1, то потом восстановление его в процессор №2 займет существенно больше времени, чем в процессор №1? А вытеснение будет происходить по любому.

Что значит "вытеснили"? Одно дело, когда прерывается выполнение потока для других (вытесняющая многозадачность), и другое — когда контекст всего процесса тусуется между процессорами.
А то, что замедляет — увы, проверено. Super FB1.5 ставил с указанием использовать два процессора... Результат — оба заняты на 50% примерно, и работа замедлилась (соединений было под сотню, так что...)

Здравствуйте, DarkMaster, Вы писали:

DM>Здравствуйте, Romkin, Вы писали:

R>>Ты будешь смеятся, но суперсервер IB, если не принимать некоторых мер, на двух процессорах действительно может работать медленее. IB до версии 7 использует только один процессор, причем упорно. А система начинает его перекидывать по разным процессорам. Вот на переключениях производительность и теряется

DM>1) Это не обьясняет увеличение кол-ва обращений к БД.
DM>2) У человека — FB 1.5.

Это и понятно, что не объясняет. И могу сказать, что у меня вообще идей нет, почему работа замедлилась. Недавно совсем окончательно перевел все приложения с IB5.6 на FB1.5. Все явно стало работать быстрее, правда, на количество чтений я не смотрел
FB1.5 — супер его версия на win ведет себя абсолютно аналогично IB . Для Linux — не скажу, не пробовал.

Здравствуйте, Igor Trofimov, Вы писали:
iT>Увы, это документально зафиксированный факт. Специально в первых версиях FB доделывали опцию привязки к одному процу.
Нифига себе. Век живи — век учись. Мои представления об устройстве операционных систем трещат по швам. Это как же надо писать программу, чтобы она работала медленнее на 2х процах вместо одного?..

Привет, Sinclair!
Вы пишешь 16 апреля 2004:

iT>> Увы, это документально зафиксированный факт. Специально в первых версиях FB доделывали опцию привязки к одному процу.
S> Нифига себе. Век живи — век учись. Мои представления об устройстве операционных систем трещат по швам.
S> Это как же надо писать программу, чтобы она работала медленнее на 2х процах вместо одного?..

А что ты знаешь "...об устройстве операционных систем", отличных от MS Windows?
Изначально IB разрабатывался как платформонезависимый сервер. (Ещё за царя Гороха)
Были таки экзоты как IB for NetWare, for Win3.X и пр.
А какая там вытесняющая многозадачность? Никакой. Потому и фигня такая с многопоточностью.
А на разработку "нормальной" версии IB, для сегодняшних реалий, Borland забил болт 4 года назад.
Спохватились только в прошлом году. Конкуренты давным давно ушли вперёд.
А у IB7 так и осталось древнее ядро, заштопаное в 30 местах и слегка приукрашенное.

--
With best regards, Alex Cherednichenko.