Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Скорость выборки

Страницы: < 1 2 3 4 5 6 >
Piter © (2004-12-18 18:50:00)
Есть такое выражение:

'SELECT Count(n) From MyTable Where n=0'

Выборка длится около 4 секунд :(
Всего записей в базе 4700.

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

Такое ощущение, что это как бы инициализация работы с таблицей. То есть, при первой выборке из этой таблице что-то там делается долго, после чего последующие выборки из этой таблицы отрабатывают оперативно. Ну это мне так кажется.

Можно как-нибудь ускорить процесс? А то 4 секунды - это перебор все таки, имхо, на Athlon 1800. Не понимаю, как тогда работают базы с миллионами записей...

Использую базу Firebird Embedded

Nikolay M. (2004-12-19 16:50:00) [61]

> sniknik © (19.12.04 16:38) [46]

Я это уже в [27] предлагал...

> Piter © (19.12.04 16:28) [42]
> Nikolay M. © (19.12.04 16:14) [36]
> Тогда, скорее всего, остался мусор в страницах от предыдущего
> индекса. Удали и создай заново.
>
> нет! Не в этом дело...

А сделать базе сжатие-восстановление, если такое есть у ИБ? Или нет, сначала рядом завести тестовую таблицу аналогичной структуры и залить туда все данные из таблички? Если не поможет, создать новую базу. ы?

Sergey_Masloff (2004-12-19 16:48:00) [62]
sniknik © (19.12.04 16:38) [46]
>1 файл на изменениях кэшируется системой (полностью копируется >весь *.gdb),
Это в XP только. Я сначала тоже подумал но у Питера 2000.

Sergey_Masloff (2004-12-19 16:46:00) [63]
Piter © (19.12.04 16:35) [45]
>какого компьютера? Сервера?
Уже хотел ругаться что ответы не читаешь но понял что из-за глюков сервера мое огромное сообщение сюда не попало.

Придется заново. Но кратко :(
Сервер и клиент у меня один физический компьютер. После перегрузки СЕРВИСА IB его (а не операционки) кэш не существует как класс поэтому дальнейшие перезагрузки СЕРВЕРА по идее безразличны. В качестве эксперимента производилось и то и другое - то есть перестарт службы и перестарт компьютера на котором она запущена (а заодно и клиент). Все без разницы - результаты абсолютно одинаковые

>как при старте? Имхо, при старте IB сервер вообще к таблицам не >обращается. Запускается он мгновенно. И только при первом >запросе из таблицы начинает ее читать. имхо.
При старте сервер выделяет немного памяти под эти страницы. Конечно к базе он не обращается - он же не знает с какой базой будут работать клиенты. Хотя скорее вего не выделяет а просто резервирует так что на скорость это влиять не должно...

sniknik (2004-12-19 16:41:00) [64]
впрочем, у меня антивирус стоит и никаких задержек с тем же фаребирдом...
может всетаки код виноват?
выслать тестовую прогу? провериш в ней, если будет тоже самое... ну в общем любой результат показатель.

sniknik (2004-12-19 16:38:00) [65]
еще пара предположений (вернее одно ;) но разные причины)

1 файл на изменениях кэшируется системой (полностью копируется весь *.gdb), в какойто из виндов такое есть, поищи на http://ibase.ru(помню чтото такое читал, не помню где. главное зависит от расширения, если поменять на *.fdb (так вроде? для фаребирда) или из системы каширований прежнее удалить, то проходит)

2 файл базы блокируется антивирусом при первом обращении (открытии).

в обшем неважно чем но блокировка, и от файрбирда она не зависит...

Piter (2004-12-19 16:35:00) [66]
Sergey_Masloff (19.12.04 16:32) [43]
ну никак не влияет на результат и перегрузки компьютера

какого компьютера? Сервера?

Sergey_Masloff (19.12.04 16:32) [43]
Надо но выделить под них место он может (и делает это) раньше - при старте

как при старте? Имхо, при старте IB сервер вообще к таблицам не обращается. Запускается он мгновенно. И только при первом запросе из таблицы начинает ее читать. имхо.

Piter (2004-12-19 16:33:00) [67]
А вот на SQL.ru - хотя Николай и говорил, что там просто фантастический уровень находящегося там народа так вообще ничего путного не сказали - http://www.sql.ru/forum/actualthread.aspx?bid=2&tid=146762&pg=-1

Sergey_Masloff (2004-12-19 16:32:00) [68]
Piter © (19.12.04 16:25) [40]
>а серверу Interbase не надо в первый раз поднимать страницы в >память?
Надо но выделить под них место он может (и делает это) раньше - при старте.
Но неважно - сам говоришь не влияет.
Честно говоря- заинтриговал. Уже по свякому перепробовал - ну никак не влияет на результат и перегрузки компьютера, и индекс ненужный создавал, и дропал его - ну никак никакого торможения не добъюсь. Все эксперименты на таблице 6500 записей - подобрал максимально похожую.

Piter (2004-12-19 16:28:00) [69]
Nikolay M. © (19.12.04 16:14) [36]
Тогда, скорее всего, остался мусор в страницах от предыдущего индекса. Удали и создай заново.

нет! Не в этом дело...

Sergey_Masloff (19.12.04 16:18) [38]
>бли-и-ин. А вы перезагружались??!?!?!

Да, и сервис перестартовывал

как вас понимать?! Что значит "И"? Как можно перезагрузить сервер и в тоже время не перестартовать сервис IB?

Sergey_Masloff (19.12.04 16:18) [38]
(хотя это уже не играет роли) компьютер перезагружал

как это не играет? Я говорю, что именно после перезагрузки первый раз тормоза, а потом уже нормально - а вы говорите не играет роли!

Sergey_Masloff (19.12.04 16:20) [39]
Ну вобщем COUNT(*) по 50 000 000 записей 52 секунды без индексов. После перезагрузки компьютера ;-)

после перезагрузки какого компьютера? Сервера надеюсь?! Или вы клиента перегружаете?!?!?!?

Piter (2004-12-19 16:25:00) [70]
Sergey_Masloff (19.12.04 15:55) [31]
ведь это dll-ка которая загружается только при запуске твоей программы. Ей свой кэш тоже надо распределять и так далее - может поэтому первый запрос с интенсивным подъемом страниц в память так тормозит

а серверу Interbase не надо в первый раз поднимать страницы в память?
К тому же - приведенные мной опыты я делал уже на сервере Firebird (использовал IBConsole) - никакой разницы между Embedded и сервером не замечено

Nikolay M. © (19.12.04 15:44) [30]
попробуй удалить индекс на n и повторить эксперимент?

Дропнул индекс по N. Запрос выполняется еще дольше:

SELECT count(n) FROM Tree WHERE n=3:

Execution Time: 4:0672- время увеличилось
Prepare Time: 0:0000
Delta Memory: 6144- маленькой какой-то стала
Number of buffers: 2048
Reads: 1118- увеличилось
Writes: 6
Plan: PLAN(TREE NATURAL)

Sergey_Masloff (2004-12-19 16:25:00) [71]
Nikolay M. © (19.12.04 16:16) [37]
>И из-за этого план запроса требует кол-во чтений на порядок >больше
Упс... проглядел.

Sergey_Masloff (2004-12-19 16:20:00) [72]
Ну вобщем COUNT(*) по 50 000 000 записей 52 секунды без индексов. После перезагрузки компьютера ;-)

Sergey_Masloff (2004-12-19 16:18:00) [73]
Piter © (19.12.04 16:04) [35]
>бли-и-ин. А вы перезагружались??!?!?!
Да, и сервис перестартовывал и даже (хотя это уже не играет роли) компьютер перезагружал. Одно и то же.

Nikolay M. (2004-12-19 16:16:00) [74]

> Sergey_Masloff (19.12.04 15:55) [31]
> Ну а так все же может фича ембеддеда - ведь это dll-ка которая
> загружается только при запуске твоей программы. Ей свой
> кэш тоже надо распределять и так далее - может поэтому первый
> запрос с интенсивным подъемом страниц в память так тормозит?

И из-за этого план запроса требует кол-во чтений на порядок больше, судя по [29]?

Nikolay M. (2004-12-19 16:14:00) [75]

> CREATE INDEX TREE_ID ON TREE (n)
>
> Просто название неудачное, остался от прежнего:
>
> CREATE INDEX TREE_ID ON TREE (n, ID);

Тогда, скорее всего, остался мусор в страницах от предыдущего индекса. Удали и создай заново.

Piter (2004-12-19 16:04:00) [76]
Nikolay M. © (19.12.04 15:44) [30]
Какие поля входят в этот индекс?

CREATE INDEX TREE_ID ON TREE (n)

Просто название неудачное, остался от прежнего:

CREATE INDEX TREE_ID ON TREE (n, ID);

Piter (2004-12-19 16:04:00) [77]
Sergey_Masloff (19.12.04 15:55) [31]
Уж и так и сяк гоняю никак больше 16 мс не могу заставить выполняться

бли-и-ин. А вы перезагружались??!?!?!

Piter (2004-12-19 16:02:00) [78]
Anatoly Podgoretsky © (19.12.04 15:05) [26]
в чем сомневаюсь

извините, но можете сомневаться дальше

DrPass © (19.12.04 14:59) [24]
Подозреваю, что файл не слишком большой

28 Мб.

Nikolay M. © (19.12.04 15:06) [27]
Атлон 1800? Дык может у автора памяти 64 и винт на 2?

80 Gb барракуда + 256 Mb DDR 2100

Sergey_Masloff (19.12.04 15:12) [28]
Таблица из 4000 записей - это семечки даже для такой "системы".

Сергей, а вы учитываете что я говорю про ПЕРВЫЙ ЗАПУСК. У вас там думаю крутится сервер базы данных и крутится. Повторные запросы и у меня отрабатываются очень быстро. Можете посмотреть выше - я привел статистику. Но вот САМЫЙ ПЕРВЫЙ ЗАПРОС после перезагрузки - очень медленно работает.

Вы проведите эксперимент - вырубите базу данных на вашем DX2-66 сервере, перезагрузите компьютер, запустите сервер - и посмотрите сколько будет выполняться хотя бы первый count(*) по любой таблице, где записей хотя бы пару тысяч.

Sergey_Masloff (2004-12-19 15:56:00) [79]
Nikolay M. © (19.12.04 15:44) [30]

>попробуй удалить индекс на n и повторить эксперимент?
Кстати очень хорошая мысль!

Sergey_Masloff (2004-12-19 15:55:00) [80]
Piter © (19.12.04 15:34) [29]
Да интересная ситуация. Уж и так и сяк гоняю никак больше 16 мс не могу заставить выполняться. Ни о каких секундах речи нет... :(

Ну еще напрягись сделай не count(n) a count(*) тем более в твоем контексте это одно и то же.

Ну а так все же может фича ембеддеда - ведь это dll-ка которая загружается только при запуске твоей программы. Ей свой кэш тоже надо распределять и так далее - может поэтому первый запрос с интенсивным подъемом страниц в память так тормозит?

Страницы: < 1 2 3 4 5 6 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »