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

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

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

В DNA копать.
Как переползал на 1.5? Просто переставил сервер и всё?
Базу нужно пересоздать из бекапа, а потом тестить.

--
With best regards, Alex Cherednichenko.

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

AC>В DNA копать.
AC>Как переползал на 1.5? Просто переставил сервер и всё?
AC>Базу нужно пересоздать из бекапа, а потом тестить.

А что там копать-то в этом DNA?
Или я тебя не понял?
А за идею с бекапом — спасибо. попробую

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

AC>Привет, chaynick!
AC>Вы пишешь 08 апреля 2004:

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

AC>В DNA копать.
AC>Как переползал на 1.5? Просто переставил сервер и всё?
AC>Базу нужно пересоздать из бекапа, а потом тестить.

AC>--
AC>With best regards, Alex Cherednichenko.

Бекапил-ресторил не помогает. А можешь поподробнее? У мея в конторе не один программер не знает что есть DNA.
Вообщето настройкой серверов мы только только занялись.

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

C>У мея в конторе не один программер не знает что есть DNA.


Эта аббревиатура гены означает. ДНК по-русски.

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

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

C>>У мея в конторе не один программер не знает что есть DNA.

FA>
FA>Эта аббревиатура гены означает. ДНК по-русски.

Пробовал перенастроить свой ДНК, но пальцы в USB не лезут. Мож через COM а ??

зы не смешно

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

[Sorry, skipped]
c> Пробовал перенастроить свой ДНК, но пальцы в USB не лезут. Мож через COM а ??
c> зы не смешно

Ты не обижайся. Просто ты не привёл никаких подробностей.
И посему, на такие вопросы, обычно отвечают — "ошибка в 17-й строке", ну или в DNA.
Подробности давай: текст процедуры, DDL задействованных таблиц и т.п.

--
With best regards, Alex Cherednichenko.

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

AC>Привет, chaynick!
AC>Вы пишешь 08 апреля 2004:

AC>[Sorry, skipped]
c>> Пробовал перенастроить свой ДНК, но пальцы в USB не лезут. Мож через COM а ??
c>> зы не смешно

AC>Ты не обижайся. Просто ты не привёл никаких подробностей.
AC>И посему, на такие вопросы, обычно отвечают — "ошибка в 17-й строке", ну или в DNA.
AC>Подробности давай: текст процедуры, DDL задействованных таблиц и т.п.

AC>--
AC>With best regards, Alex Cherednichenko.

Я не обижаюсь-на это нет времени. Процедуры выложить не могу ..длинно. сия проц. имеет вложенную,
та в свою очередь еще две, те в свою очередь еще по одной . Я хотел узнать принципиально ПОЧЕМУ и где копать (настройки сервера, индексы, планы ). Переписывать ежели что не так, нельзя — половина будет юзать 1.0 половина скорее всего 1.5 Почему простейший запрос типа select t1.field1 from table t1 inner join table2 t2 on (t1.enyfield=t2.enyfield) where t2.somefield>8686 совершает 500 чтений а на 1.5 4000!!! на той же базе.
зы fb 1.5.0.4306 WIN32

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

[Sorry, skipped]
AC>> Подробности давай: текст процедуры, DDL задействованных таблиц и т.п.

c> Почему простейший запрос типа select t1.field1 from table t1 inner join table2 t2 on (t1.enyfield=t2.enyfield) where
c> t2.somefield>8686 совершает 500 чтений а на 1.5 4000!!!

Чем смотрим? Если IBExpert'ом, то прежде чем смотреть статистику чтений,
выполни в нём переход на последнюю запись. А уж потом смотри.
Иначе чушь наблюдаешь.

--
With best regards, Alex Cherednichenko.

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

AC>Привет, chaynick!
AC>Вы пишешь 08 апреля 2004:

AC>[Sorry, skipped]
AC>>> Подробности давай: текст процедуры, DDL задействованных таблиц и т.п.

c>> Почему простейший запрос типа select t1.field1 from table t1 inner join table2 t2 on (t1.enyfield=t2.enyfield) where
c>> t2.somefield>8686 совершает 500 чтений а на 1.5 4000!!!

AC>Чем смотрим? Если IBExpert'ом, то прежде чем смотреть статистику чтений,
AC>выполни в нём переход на последнюю запись. А уж потом смотри.
AC>Иначе чушь наблюдаешь.

AC>--
AC>With best regards, Alex Cherednichenko.

В результатах? Выполнил — ничего не поменялось.

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

c>>> Почему простейший запрос типа select t1.field1 from table t1 inner join table2 t2 on (t1.enyfield=t2.enyfield) where
c>>> t2.somefield>8686 совершает 500 чтений а на 1.5 4000!!!

AC>>Чем смотрим? Если IBExpert'ом, то прежде чем смотреть статистику чтений,
AC>>выполни в нём переход на последнюю запись. А уж потом смотри.
AC>>Иначе чушь наблюдаешь.

C>В результатах? Выполнил — ничего не поменялось.

Если хочешь, чтобы тебе помогли, то давай структуру, индексы и планы с 1.0 и с 1.5. Количество записей в таблицах.

Если же заниматься гаданием, то попробуй так
select t1.field1 from table t1 inner join table2 t2 on (t1.enyfield=t2.enyfield+0) where
t2.somefield>8686

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

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

c>>>> Почему простейший запрос типа select t1.field1 from table t1 inner join table2 t2 on (t1.enyfield=t2.enyfield) where
c>>>> t2.somefield>8686 совершает 500 чтений а на 1.5 4000!!!

AC>>>Чем смотрим? Если IBExpert'ом, то прежде чем смотреть статистику чтений,
AC>>>выполни в нём переход на последнюю запись. А уж потом смотри.
AC>>>Иначе чушь наблюдаешь.

C>>В результатах? Выполнил — ничего не поменялось.

А>Если хочешь, чтобы тебе помогли, то давай структуру, индексы и планы с 1.0 и с 1.5. Количество записей в таблицах.

А>Если же заниматься гаданием, то попробуй так
А>select t1.field1 from table t1 inner join table2 t2 on (t1.enyfield=t2.enyfield+0) where
А>t2.somefield>8686

Ну хорошо:

CREATE TABLE ABONENTS (
LSHET VARCHAR(10) CHARACTER SET NONE NOT NULL,
ISDELETED IDENTIFER,
KR INTEGER,
DOGOVORDT TIMESTAMP,
HOUSECD KEYS,
FLATNO SMALLINT,
ROOMNO SMALLINT,
FIO VARCHAR(40) CHARACTER SET NONE,
NAME VARCHAR(20) CHARACTER SET NONE,
SECOND_NAME VARCHAR(20) CHARACTER SET NONE,
TEL VARCHAR(15) CHARACTER SET NONE,
NOTE BLOB SUB_TYPE 1 SEGMENT SIZE 80,
DELETED BOOLEAN,
NEEDMONTHDOLGRECOUNT BOOLEAN,
OWNERID KEYS,
CHANGEDOCUMENTCD INTEGER
);





/******************************************************************************/
/* Primary Keys */
/******************************************************************************/

ALTER TABLE ABONENTS ADD CONSTRAINT XPKABONENTS PRIMARY KEY (LSHET);


/******************************************************************************/
/* Foreign Keys */
/******************************************************************************/

ALTER TABLE ABONENTS ADD CONSTRAINT R_58 FOREIGN KEY (HOUSECD) REFERENCES HOUSES (HOUSECD);
ALTER TABLE ABONENTS ADD CONSTRAINT R_783 FOREIGN KEY (ISDELETED) REFERENCES DOCUMENTS (DOCUMENTCD);
ALTER TABLE ABONENTS ADD CONSTRAINT R_888 FOREIGN KEY (OWNERID) REFERENCES INFORMATIONOWNERS (OWNERID);


/******************************************************************************/
/* Indices */
/******************************************************************************/

CREATE INDEX ABONENTS_IDX1 ON ABONENTS (LSHET);
CREATE INDEX XIEFIOABONENTS ON ABONENTS (FIO);
CREATE INDEX XIETELABONENTS ON ABONENTS (TEL);


Количество записе 8162


CREATE TABLE CITYZENS (
CITYZEN_ID IDENTIFER NOT NULL,
LSHET VARCHAR(10) CHARACTER SET NONE,
ISMAINCITYZEN BOOLEAN,
PASPORTNO VARCHAR(20) CHARACTER SET NONE,
PASPORTSR VARCHAR(10) CHARACTER SET NONE,
PASSPORTDATE TDATE,
PASSPORTNOTE TEXT_BLOB,
CTZFIO VARCHAR(30) CHARACTER SET NONE,
CTZNAME VARCHAR(20) CHARACTER SET NONE,
CTZPARENTNAME VARCHAR(20) CHARACTER SET NONE,
STARTDATE TDATE,
ENDDATE TDATE,
NOTE TEXT_BLOB,
BIRTHDAY TDATE,
UNIQUECITYZENID VARCHAR(30) CHARACTER SET NONE,
CHANGEDOCUMENTCD INTEGER
);





/******************************************************************************/
/* Primary Keys */
/******************************************************************************/

ALTER TABLE CITYZENS ADD CONSTRAINT XPKCITYZENS PRIMARY KEY (CITYZEN_ID);


/******************************************************************************/
/* Foreign Keys */
/******************************************************************************/

ALTER TABLE CITYZENS ADD CONSTRAINT R_623 FOREIGN KEY (LSHET) REFERENCES ABONENTS (LSHET);


/******************************************************************************/
/* Indices */
/******************************************************************************/

CREATE UNIQUE INDEX XAKCITYZENSUNIQUEID ON CITYZENS (UNIQUECITYZENID);

кодичество записей 4135


Для примера запрос select ab.lshet from abonents ab
inner join cityzens cz on (cz.lshet=ab.lshet)
where cz.cityzen_id>1000

PLAN JOIN (CZ INDEX (RDB$PRIMARY22),AB INDEX (RDB$PRIMARY7))

результаты FB 1.0 SuperServer (на машке P4 1400)
Query Time
------------------------------------------------
Prepare : 0,00 ms
Execute : 15,00 ms
Avg fetch time: 0,79 ms

Memory
------------------------------------------------
Current: 5 416 852
Max : 5 544 964
Buffers: 2 048

Operations
------------------------------------------------
Read : 0
Writes : 0
Fetches: 3 948


Enchanced Info:
+--------------------------+-------+-----------+---------+---------+---------+
| Table Name | Index | Non-Index | Updates | Deletes | Inserts |
| | reads | reads | | | |
+--------------------------+-------+-----------+---------+---------+---------+
| ABONENTS| 558 | 0 | 0 | 0 | 0 |
| CITYZENS| 558 | 0 | 0 | 0 | 0 |
+--------------------------+-------+-----------+---------+---------+---------+

результаты FB 1.5 Classic Server (на машке 2хP4 2700)

Причем на разницу SS CS ссылаться не надо пробовал и так и так.

Query Time
------------------------------------------------
Prepare : 0,00 ms
Execute : 0,00 ms
Avg fetch time: 0,00 ms

Memory
------------------------------------------------
Current: 1 551 500
Max : 8 189 628
Buffers: 75

Operations
------------------------------------------------
Read : 3 346
Writes : 0
Fetches: 28 748


Enchanced Info:
+--------------------------+-------+-----------+---------+---------+---------+
| Table Name | Index | Non-Index | Updates | Deletes | Inserts |
| | reads | reads | | | |
+--------------------------+-------+-----------+---------+---------+---------+
| ABONENTS| 4096 | 0 | 0 | 0 | 0 |
| CITYZENS| 4096 | 0 | 0 | 0 | 0 |
+--------------------------+-------+-----------+---------+---------+---------+

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

[Sorry, skipped]
c> Ну хорошо:

Нет, не хорошо.
Доменов нету.

[Sorry, skipped]
c> результаты FB 1.0 SuperServer (на машке P4 1400)
c> Query Time
c> ------------------------------------------------
c> Prepare : 0,00 ms
c> Execute : 15,00 ms
c> Avg fetch time: 0,79 ms

[Sorry, skipped]
c> результаты FB 1.5 Classic Server (на машке 2хP4 2700)
c> Query Time
c> ------------------------------------------------
c> Prepare : 0,00 ms
c> Execute : 0,00 ms
c> Avg fetch time: 0,00 ms

И чем ты недоволен????

c> Причем на разницу SS CS ссылаться не надо пробовал и так и так.

Будет очень смешно, если ты оставил DefaultDbCachePages
на классике таким же, как на SS...

--
With best regards, Alex Cherednichenko.

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

AC>Привет, chaynick!
AC>Вы пишешь 09 апреля 2004:

AC>[Sorry, skipped]
c>> Ну хорошо:

AC>Нет, не хорошо.
AC>Доменов нету.

AC>[Sorry, skipped]
c>> результаты FB 1.0 SuperServer (на машке P4 1400)
c>> Query Time
c>> ------------------------------------------------
c>> Prepare : 0,00 ms
c>> Execute : 15,00 ms
c>> Avg fetch time: 0,79 ms

AC>[Sorry, skipped]
c>> результаты FB 1.5 Classic Server (на машке 2хP4 2700)
c>> Query Time
c>> ------------------------------------------------
c>> Prepare : 0,00 ms
c>> Execute : 0,00 ms
c>> Avg fetch time: 0,00 ms

AC>И чем ты недоволен????

c>> Причем на разницу SS CS ссылаться не надо пробовал и так и так.

AC>Будет очень смешно, если ты оставил DefaultDbCachePages
AC>на классике таким же, как на SS...

AC>--
AC>With best regards, Alex Cherednichenko.
Сорри не неаписал, что FB 1.0 стоит на P4 1400, 320Mb а FB 1.5 на 2хP4 2700, 1Gb

CREATE DOMAIN IDENTIFER AS
INTEGER

CREATE DOMAIN KEYS AS
INTEGER

CREATE DOMAIN BOOLEAN AS
SMALLINT
CHECK (VALUE IN (0, 1))

CREATE DOMAIN TDATE AS
DATE

А размер кыша не влияет-пробовал, тут вопрос ИМХО не в этом.

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

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

Гиви, ты что не знаешь где магазин находится?! Сходи туда, купи пива своим программерам и они тебе все расскажут. Ты уже задолбал народ трести

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


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

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

А>Гиви, ты что не знаешь где магазин находится?! Сходи туда, купи пива своим программерам и они тебе все расскажут. Ты уже задолбал народ трести


Бандерлог, эти сволочи ни хрена не знают, и пиво им поможет

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

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


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

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

А>>Гиви, ты что не знаешь где магазин находится?! Сходи туда, купи пива своим программерам и они тебе все расскажут. Ты уже задолбал народ трести


C>Бандерлог, эти сволочи ни хрена не знают, и пиво им поможет


Ты тогда нам купи мы приедем и будем долго-долго помогать тебе пока пиво не кончиться.

Бандерлог

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

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

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


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

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

А>>>Гиви, ты что не знаешь где магазин находится?! Сходи туда, купи пива своим программерам и они тебе все расскажут. Ты уже задолбал народ трести


C>>Бандерлог, эти сволочи ни хрена не знают, и пиво им поможет


А>Ты тогда нам купи мы приедем и будем долго-долго помогать тебе пока пиво не кончиться.

А>Бандерлог

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

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

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

C>Бекапил-ресторил не помогает. А можешь поподробнее? У мея в конторе не один программер не знает что есть DNA.
C>Вообщето настройкой серверов мы только только занялись.
8) DNA == ДНК.

Здравствуйте, 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.

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

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

Мысль хорошая. Доки, книги — вещь полезная. Вот и глянь книгу. И почитай бегло. Здесь спор идет о FIB, а не о СУБД вообще. КАрочИ — еще с 1 FIB была такая фигня. Если посмотреть на то, какие баги исправлялись при разработке 1.5, то в доке ни слова нет о многопроцессорности.

iT>Если ты не видишь разницы между содержательностью ответа "смотри доки" и "смотри планы" — могу только посочувствовать. 50 тыс а под 1.5 500 млн!! Ты посмотри насколько происходит увеличение, и ты хочешь это лечить настройкой плана?! Вот пытаюсь разглядеть разницу и никак не вижу.

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

iT>Я старался.
Ну это понятно, к интернету коннестился клоун

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

iT>Но в первую очередь надо бы проверить планы.
Еще раз тебе говорю дело тут не в планах слишком большая разница в количестве обращений 50 тыс и 500 млн!!

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

Да, вижу ты уж точно доку не читал

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

А>Да, вижу ты уж точно доку не читал

Здравствуйте, Alex.Che, Вы писали:
AC>А что ты знаешь "...об устройстве операционных систем", отличных от MS Windows?
Да практически ничего. Но основная идея любых систем с вытесняющей многозадачностью вроде как в том, что шедулер время от времени сбрасывает контекст единицы шедулинга (будь то процесс или поток) в память, выбирает другой контекст, и поднимает в процессор его для исполнения в течение следующего кванта.
Отличие поддержки нескольких процессоров в том, что шедулер может назначить одновременно N потоков/процессов на исполнение.
Очевидно, что приложение, которое выполняет всю свою работу в пределах одной единицы шедулинга, не сможет использовать более одного процессора одновременно.
Но вот почему шедулинг при количестве процессоров более 1 становится настолько медленнее, я не понимаю. То есть насколько я знаю, при восстановлении контекста в момент активации потока шедулер выбирает, куда его восстановить.
Единственная идея, которая приходит мне в голову, состоит в том, что при восстановлении контекста в тот же процессор, где он был, есть шанс использовать кэш этого процессора. Я не в курсе, как взаимодействует кэширование в современных процах с переключениями контекста, поэтому не могу делать осмысленных заключений.
Тем не менее, не вижу повода как-то радикально просаживать производительность в этом случае (кроме того, почему бы не учитывать кэширование в шедулере?)

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

AC>> А что ты знаешь "...об устройстве операционных систем", отличных от MS Windows?
S> Да практически ничего. Но основная идея любых систем с вытесняющей многозадачностью...

А теперь ещё раз прочти, то что я написал, про то, когда и под что разрабатывался IB

--
With best regards, Alex Cherednichenko.

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

S>Очевидно, что приложение, которое выполняет всю свою работу в пределах одной единицы шедулинга, не сможет использовать более одного процессора одновременно.
S>Но вот почему шедулинг при количестве процессоров более 1 становится настолько медленнее, я не понимаю. То есть насколько я знаю, при восстановлении контекста в момент активации потока шедулер выбирает, куда его восстановить.

Если бы это было так, то ядра систем с поддержкой SMP и без нее не различались. Все дело в том, что вытесняющая многозадачность поддерживается самим процессором. Если упростить, процессор сам по команде сохраняет состояние регистров (где — не суть важно), берет регистры другого потока и прололжает... Причем здесь не интересно, какоим процессам принадлежат потоки.
А вот при друх процессорах уже все сложнее, ядру приходится отнимать у одного процессора весь процесс вместе с потоками и переносить на другой. А это уже гораздо напряжнее.

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

C>>Бекапил-ресторил не помогает. А можешь поподробнее? У мея в конторе не один программер не знает что есть DNA.
C>>Вообщето настройкой серверов мы только только занялись.
G> 8) DNA == ДНК.

DNA — distributed network applications, e.g. Windows DNA

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

AC>А теперь ещё раз прочти, то что я написал, про то, когда и под что разрабатывался IB
Блин, да какая разница? Я говорю про произвольное приложение. Откуда берутся накладные расходы при втором процессоре?
З.Ы. Я догадываюсь, почему IB не умеет использовать больше 50% от двух процессоров и 25% от четырех. Вопрос не в этом.

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

iT>>Но в первую очередь надо бы проверить планы.
А>Еще раз тебе говорю дело тут не в планах слишком большая разница в количестве обращений 50 тыс и 500 млн!!
Я восхищаюсь упорством храбрых. Вот мой опыт показвает, что увеличение количества обращений на 10 в четвертой зависит исключительно от плана запроса. Для тех, кто в танке, поясняю — если мы используем индекс, то читаем только необходмиый минимум. А если в плане стоит table scan — то придется читать все. Вот и получаем увеличение чтений ровно во столько раз, сколько была селективность индекса. А для джойнов ошибка в подборе плана может сыграть еще более радикальную роль. Ты бы вместо того, чтобы наезжать на Игоря привел сюда план запроса на FB1 и его же план на FB1.5.