Переход с Interbase на Firebird

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Переход с Interbase на Firebird

Сообщение S.H.S » 25 ноя 2005, 02:32

При переходе с Interbase 7.1 на Firebird 2b возникли проблемы.
Создаю базу, перекидываю данные. При запуске программы - тормоза.
В IB Expert'е подключаю две базы и вижу, что при простом SELECT * FROM table в Firebird 3899 чтений (именно столько записей в таблице), а у Interbase - 1203. Firebird работает три раза медленее!!! Таблицы одинаковые.
Помогите разобраться.
Очень - Очень - Очень сильно жду помощи.
Последний раз редактировалось S.H.S 25 ноя 2005, 17:58, всего редактировалось 1 раз.

Ivan_Pisarevsky
Заслуженный разработчик
Сообщения: 644
Зарегистрирован: 15 фев 2005, 11:34

Сообщение Ivan_Pisarevsky » 25 ноя 2005, 08:21

-Штирлиц, у Вас есть план?
-А как же!
-Ахааа... хороший у Вас план, Штирлиц!!!

Будем гадать и ли план запроса смотреть? и всяческие структуры таблиц и индексов.

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Сообщение S.H.S » 25 ноя 2005, 10:23

Таблица:
CREATE TABLE COMPS (
COMPS_ID INTEGER NOT NULL,
COMPS_NUM INTEGER NOT NULL,
CATEGORY_ID INTEGER,
GOODS_ID INTEGER,
PRICE NUMERIC(5,2),
PRICE_RB INTEGER,
BASE_ID INTEGER,
METKA INTEGER
);
ALTER TABLE COMPS ADD PRIMARY KEY (COMPS_ID);

ALTER TABLE COMPS ADD FOREIGN KEY (GOODS_ID) REFERENCES GOODS (GOODS_ID);
ALTER TABLE COMPS ADD FOREIGN KEY (CATEGORY_ID) REFERENCES CATEGORY (CATEGORY_ID);
ALTER TABLE COMPS ADD FOREIGN KEY (BASE_ID) REFERENCES BASE (BASE_ID);

Простите за "выписки".

Запрос:
SELECT comps_id FROM comps

В Interbase результат:
1302 - non-indexed reads

Plan
PLAN (COMPS NATURAL)

Adapted Plan
PLAN (COMPS NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 140ms
Avg fetch time = 7,00 ms
Current memory = 9,190,400
Max memory = 9,467,136
Memory buffers = 2,048
Reads from disk to cache = 31
Writes from cache to disk = 0
Fetches from cache = 3,064

В Firebird результат:
3899 - non-indexed reads

Plan
PLAN (COMPS NATURAL)

Adapted Plan
PLAN (COMPS NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 151ms
Avg fetch time = 7,55 ms
Current memory = 689,468
Max memory = 727,672
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 7,974

Меня не столько беспокоит non-indexed сколько разница обращений.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Re: Переход с Interbase на Firebird

Сообщение hvlad » 25 ноя 2005, 10:27

А ты всё сфетчил ? Если фетчить не умеем, сравнивай select count(*)
И где медленнее ? 140 против 150 мс ?

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Сообщение S.H.S » 25 ноя 2005, 11:22

Во-первых: ху ис фетчить? (Что это).

Во-вторых: Это в SQL едиторе разница в 10мс. В программе все гораздо печальнее. При всязи с другими таблицами пауза в 4 секунды. Там где ее вообще не было.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 25 ноя 2005, 12:34

а у тебя размер страницы одинаков у обоих баз?

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Сообщение S.H.S » 25 ноя 2005, 13:12

В Interbase - Page Size 4096;
В Firebird - Page Size был 2048 менял на 4096, на 16386 (сейчас так).

Ничего не дало.

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 25 ноя 2005, 14:10

выполни на обоих серверах:

select count(*) from comps

и доложи статистику.

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Сообщение S.H.S » 25 ноя 2005, 15:13

select count(*) from comps дал количество там и там 3899 (они естественно одинаковые), также одинаковое количество обращений 3899 (это тоже понятно).

В Interbase:

Plan
PLAN (COMPS NATURAL)

Adapted Plan
PLAN (COMPS NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9,190,400
Max memory = 9,467,136
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 8,358

В Firebird:

Plan
PLAN (COMPS NATURAL)

Adapted Plan
PLAN (COMPS NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 20ms
Avg fetch time = 20,00 ms
Current memory = 660,560
Max memory = 698,420
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 7,975

Сразу хочу добавить, что две базы стоят на одном и том же компе. Обращение с одной и той же программы, меняется только в программе имя сервера с *.GDB на *.FDB.

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Сообщение S.H.S » 26 ноя 2005, 01:52

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

Всем огромное спасибо.

Кажеться причина в самом Fireberd 2.0 beta. Поставил Fireberd 1.5.3 проблема отпала сама собой. Надеюся, что в 2.0 это чудо только из-за beta-тестирования. Когда оно закончится должно работать все быстрее(Очень на это надеюсь и с нетерпением жду).

Ivan_Pisarevsky
Заслуженный разработчик
Сообщения: 644
Зарегистрирован: 15 фев 2005, 11:34

Сообщение Ivan_Pisarevsky » 26 ноя 2005, 10:33

Во-вторых: Это в SQL едиторе разница в 10мс. В программе все гораздо печальнее. При всязи с другими таблицами пауза в 4 секунды. Там где ее вообще не было.
Явные и неявные джойны в запросе случайно не присутствуют вместе?
Опять же надо структуры, ключи запрос и планы.

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 27 ноя 2005, 09:00

S.H.S писал(а):Кажеться причина в самом Fireberd 2.0 beta. Поставил Fireberd 1.5.3 проблема отпала сама собой. Надеюся, что в 2.0 это чудо только из-за beta-тестирования. Когда оно закончится должно работать все быстрее(Очень на это надеюсь и с нетерпением жду).
"Ну и наглый ты, Харли" (с)

Обнаружил потенциальную проблему в Beta, забил на нее болт и при этом хочешь, чтобы в релизе эту проблему устранили? Ню-ню.

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

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Сообщение S.H.S » 29 ноя 2005, 00:52

Очень простой пример:
Скачиваем и ставим FB 1.5.3. Создаем таблицу с 2-3 полями и одним PK. Забиваем ее данными 10 000 записей. Затем в IB Expert'e запускаем запрос SELECT field_id FROM table. Видим что при количестве записей 10 000 количество обращений около 500-3000 (думаю это цифра зависит от структуры таблицы).
А теперь скачиваем и ставим FB 2.0 Alpha или Beta (я и то и то ставил). Проделываем все тоже самое. Видим - при том же количестве записей количество обращений ровно 10 000.
На одной таблице разница по времени будет в мс, а для большего эффекта создим 2-3 таблицы, с внешним ключем. И напишем что-то вроди SELECT * FROM tabel1 t1, table2 t2, tabel3 t3 WHERE t1.field_id1=t2.field_id1 AND t2.field_id2=t3.field_id2. Заразница во времени между FB 1.5.3 и FB 2.0 будет в несколько секунд.
Вообще я думаю, что это не ошибка, а просто ограничение Beta-версии (по крайней мере очень надеюсь).

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 29 ноя 2005, 20:24

Ты подключаешься по локальному протоколу. У которого в 1.5 не было буферизации записей на клиенте. След-но, читалось только то, что отфетчил сам. В 2.0 локальный протокол кладет записи себе за щеку, как и сетевой, отсюда и разница. Проверь на коннекте через localhost и у тебя будут одинаковые цифры на обоих серверах.

Наверное, эту фичу стоит отключить дял XNET. Влад, как считаешь?

ЗЫ. ура моему телепатическому локатору.

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 29 ноя 2005, 21:39

dimitr писал(а): ЗЫ. ура моему телепатическому локатору.
А мой мне шепчет, что твой сработал в процессе отвлечённых раздумий о смысле жизни над пенным кружавичком ;) Специально до этого не додуматься :)

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Сообщение S.H.S » 29 ноя 2005, 23:21

Для полной ясности я, наверное, поясню с чего все началось. Я написал программу которая успешно наботала уже больше года, на Delphi под Interbase 7.1. Но мне надоело извращаться с запросами, изобретать велосипед (типа FIRST или CASE). На 7.5 перейти я не решался и выбрал FB 2.0 с его (IIF и другими прелестями). Поменял только сервер и клиент, и, естественно пересоздал базу (точную копию). В программе даже менять ничего не пришлось. Все это проделывал через LOCALHOST. Проверив работу остался доволен. Поставил программу в сеть. Все как бы хорошо, только в одном месте, где связь двух больших таблиц и одной не очень, упала в раз 50. Вернулся на свой комп, где локальный сервер, стуация таже. Дня 4 все мучались с этой задержкой в 4 сек. Затем поставил FB 1.5.3, все стало на много быстрее. НО Я ХОЧУ "IIF".
Если дело в настройках firebird.conf то подскажите - попробую.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 29 ноя 2005, 23:54

Значится так.

Цифры твои показывают, что в FB ты делаешь полный фетч, а в IB - частичный, отсюда и разница в кол-ве чтений. Это раз.

Запросы со статистикой и планами ты тоже прячешь. Это два.

Как показал ТЛ ДЕ и наша последующая беседа, локальный протокол всегда (?) делает полный фетч. ДЕ сейчас над этим думает. Это три.

Нет никаких ограничений беты. Это четыре.

Если хочешь таки выяснить в чём проблемы - давай сюда
а) тормозящий запрос,
б) DDL таблиц и индексов,
в) статистику индексов,
г)план и статистику его выполнения на IB, FB2 и FB 1.5.3.
Это всё

S.H.S
Сообщения: 65
Зарегистрирован: 25 ноя 2005, 02:18

Сообщение S.H.S » 30 ноя 2005, 12:14

Так все таки, что мне где в FB2.0 подкрутить, чтобы количество чтений было примерно одинаковое.

Запросов я не прячу, просто вопрос не в них.

Не хотелось бы показаться полным идиотом, но может кто-нибуди подскажет, где можно почитать про "ФЕТЧ". Или хотя бы в двух словах, что такое полный и частичный фетч, и где это менять (если это возможно).

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 30 ноя 2005, 12:19

S.H.S писал(а):в одном месте, где связь двух больших таблиц и одной не очень, упала в раз 50
Вот для этого случая давай метаданные, запрос, планы и статистику. Для обоих серверов.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 30 ноя 2005, 12:23

давай еще раз уточним:
1. в обоих случаях ты проводишь тест на localhost (НЕ локальный коннект), по tcp, или на удаленном сервере, по tcp. Так?
2. тестируешь в IBExpert, в обоих случаях жмешь
а) кнопку зеленого треугольника при выполнении запроса (выбрать только часть записей, помещающихся в грид)
б) кнопку двойного треугольника (выбрать ВСЕ записи на клиента, сиречь FetchAll).

Fetch - это выборка записей.

Ответить