Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Delphi Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798
kdv
p.s. и последнее - fetch All для select count зачем? там 1 запись выводится.

Ты сильный оптимист если думаешь, что она делала запрос с count...

Наталья87
Столько советов, что мозг уже не соображает, за что схватиться.

Естественно. Поэтому обычно обучение происходит постепенно, начиная с азов. Сначала просто счёт с палочками, потом сложение-вычитание, потом таблица умножения и только через четыре года тригонометрия с синусами-косинусами. А Вы решили ворваться в высшую математику, размахивая счётными палочками. Конечно же будет больно.

Сообщение было отредактировано: 19 ноя 21, 20:10
19 ноя 21, 20:01    [22398142]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4938
Dimitry Sibiryakov
goldmi45
Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся,
потом пошёл на обед. И в итоге транзакция может висеть очень долго.

Приведённые ею статистики такого не показывают.
Я не уверен, что приведенная статистика была не от недавно отресторенной базы.
19 ноя 21, 21:28    [22398177]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
YuRock,

там всё какое-то секретное, и я даже вывода gstat -h не видел, только набор маркеров транзакций скопирован оттуда.
19 ноя 21, 21:40    [22398183]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
pva86
Member

Откуда:
Сообщений: 2
Наталья87, это Вы разрабатываете Курс: школа?
19 ноя 21, 22:30    [22398200]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Да - размер страницы у меня, разумеется, 4 Кб.

По информации - да, запрос был без count. Сейчас то же самое с count. На всякий случай перед каждым тестом перезапуск сервера Firebird и свежий запуск IBExpert.


1) Исходная база 2 Гб:

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9 110 532
Max memory = 9 357 108
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 284 232


2) После set statistics index + Sweep (база 2 Гб):

------ Performance info ------
Prepare time = 0ms
Execute time = 50ms
Avg fetch time = 50,00 ms
Current memory = 9 106 432
Max memory = 9 352 988
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 284 232


3) После Backup&Restore (база 117 Мб):

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9 120 068
Max memory = 9 365 492
Memory buffers = 2 048
Reads from disk to cache = 4 161
Writes from cache to disk = 0
Fetches from cache = 284 654
19 ноя 21, 23:25    [22398206]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4938
Наталья87
Да - размер страницы у меня, разумеется, 4 Кб.

По информации - да, запрос был без count. Сейчас то же самое с count. На всякий случай перед каждым тестом перезапуск сервера Firebird и свежий запуск IBExpert.


1) Исходная база 2 Гб:

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9 110 532
Max memory = 9 357 108
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 284 232


2) После set statistics index + Sweep (база 2 Гб):

------ Performance info ------
Prepare time = 0ms
Execute time = 50ms
Avg fetch time = 50,00 ms
Current memory = 9 106 432
Max memory = 9 352 988
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 284 232


3) После Backup&Restore (база 117 Мб):

------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9 120 068
Max memory = 9 365 492
Memory buffers = 2 048
Reads from disk to cache = 4 161
Writes from cache to disk = 0
Fetches from cache = 284 654

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

Сообщение было отредактировано: 19 ноя 21, 23:29
19 ноя 21, 23:29    [22398210]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Нет - база тормозящая. Кажись, таблица та была не самая большая.
Вообще непонятно как определять самую большую таблицу. То ли по количеству записей. То ли по примерной сумме данных (в байтах).
Вот здесь другая таблица - уже посущественнее задержки.


1) Исходная тормозящая БД
------ Performance info ------
Prepare time = 0ms
Execute time = 4s 436ms
Avg fetch time = 4 436,00 ms
Current memory = 9 191 116
Max memory = 9 357 108
Memory buffers = 2 048
Reads from disk to cache = 9 070
Writes from cache to disk = 8 674
Fetches from cache = 8 352 295


2) После set statistics index + Sweep
------ Performance info ------
Prepare time = 0ms
Execute time = 1s 312ms
Avg fetch time = 1 312,00 ms
Current memory = 9 107 400
Max memory = 9 352 988
Memory buffers = 2 048
Reads from disk to cache = 7 292
Writes from cache to disk = 0
Fetches from cache = 707 354


3) После backup&restore
------ Performance info ------
Prepare time = 0ms
Execute time = 500ms
Avg fetch time = 500,00 ms
Current memory = 9 120 772
Max memory = 9 365 492
Memory buffers = 2 048
Reads from disk to cache = 7 243
Writes from cache to disk = 0
Fetches from cache = 707 257
19 ноя 21, 23:43    [22398213]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
Наталья87
1) Исходная тормозящая БД
Reads from disk to cache = 9 070
Writes from cache to disk = 8 674

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

Статистику по базе (gstat -r ...) смотрели? Версии есть? Или после первого запроса они исчезли? Или еще не исчезли, раз у вас superserver (как я понял), и он просто не успел еще собрать мусор?

Но нет - мы стартанем свип (просто наобум), и не глядя в firebird.log будем считать что станет быстрее. Хотя мусор собрался уже перед свипом.

И почему вы считаете что для базы 2 гиг размер страницы 4к - это нормально? Сделайте 8к, и сразу заметите что стало быстрее.

Короче, я уже устал. :-) Читайте ibase.ru про транзакции, версионность, и т.д.
20 ноя 21, 01:15    [22398230]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
pva86
Member

Откуда:
Сообщений: 2
kdv,
Если речь таки о Курс: школа, то там полная печаль: бекапы базы делаются путем копирования файла базы перед каждым запуском программы, клиентов десятки тысяч на самых разных конфигурациях ПК. А сама база, в основном, содержит информацию всего лишь о 2-3 тисячах человек
20 ноя 21, 12:07    [22398280]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
pva86
бекапы базы делаются путем копирования файла базы перед каждым запуском программы

ну, 1с локальные базы "бэкапит" тоже записью в zip или сжатую папку.
20 ноя 21, 18:51    [22398382]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798

kdv
1с локальные базы "бэкапит" тоже записью в zip или сжатую папку

Галактика в своё время делала так же. Самое забавное, что из-за какого-то бага в
pkzip архив на определённых данных получался битый и не мог распаковаться.

Posted via ActualForum NNTP Server 1.5

20 ноя 21, 18:54    [22398385]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
X11
Member

Откуда: Kharkiv, Ukraine
Сообщений: 15434
Наталья87
энди
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?


Да. Но это не часами длится. Обычно не более 1 минуты, а при нормальной работе секунд 10-15. Очень удобно - если произошла ошибка или пользователь нажал "Отменить" - просто делаем Rollback и всё.


но это в корне неправильно
21 ноя 21, 16:30    [22398683]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798

X11
но это в корне неправильно

Да нет, при соблюдении определённых условий это нормально. Жаль, что аффтарша
эти условия соблюсти не смогла.

Posted via ActualForum NNTP Server 1.5

21 ноя 21, 17:02    [22398698]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
Dimitry Sibiryakov

kdv
1с локальные базы "бэкапит" тоже записью в zip или сжатую папку

Галактика в своё время делала так же. Самое забавное, что из-за какого-то бага в
pkzip архив на определённых данных получался битый и не мог распаковаться.


Не у меня все по феншую. Бэкапы делаются с помощью gbak, не простым копированием файла базы, также проверяется восстановление из бэкапов. Если же бэкапы перестали делаться - пользователю выводится табличка с предупреждением. Обычно если бэкапы перестали делаться означает что база сильно повреждена, что даже бэкапы перестали делаться.

Для новых пользователей и размер страницы будет 8К. А старым 4К останется тут уже ничего не сделаешь ...
22 ноя 21, 00:52    [22398846]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4938
Наталья87
А старым 4К останется тут уже ничего не сделаешь ...
При восстановлении из бэкапа это можно легко изменить.
22 ноя 21, 02:44    [22398855]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
shalamyansky
Member

Откуда:
Сообщений: 290
Наталья87

с пустой базой приложение работает очень быстро, а по мере наполнения базы начинает замедляться.

Оценить зависимость времени выполнения запросов от размера базы (числа строк больших таблиц) можете? Если зависимость линейная, значит, где-то индекса не хватает, или он не используется. Вместо логарифмического поиска используется линейный. Почему B/R в таком случае помогает? Меньше страниц серверу просматривать приходится. Как гипотеза.
22 ноя 21, 03:30    [22398856]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
shalamyansky
Наталья87

с пустой базой приложение работает очень быстро, а по мере наполнения базы начинает замедляться.

Оценить зависимость времени выполнения запросов от размера базы (числа строк больших таблиц) можете? Если зависимость линейная, значит, где-то индекса не хватает, или он не используется. Вместо логарифмического поиска используется линейный. Почему B/R в таком случае помогает? Меньше страниц серверу просматривать приходится. Как гипотеза.


От этого и возникают идеи "дефрагментации базы данных". Чтобы упорядочить данные внутри файла. Чтобы они не были раскиданы по всему файлу в хаотичном виде. Я так понимаю, после Backup&Restore именно это и происходит (данные таблиц становятся более упорядоченными внутри файла и идут последовательно). Но в целом рекомендации выше и так уже помогли. Всё стало работать с приемлемой скоростью и без backup&restrore. А у кого это не поможет (таких теперь явно будет меньше после выполнения всех рекомендаций) можно по старинке и backup&restore сделать (и индексов добавить где запросы тормозят).
22 ноя 21, 12:26    [22399013]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
энди
Member

Откуда: Киров, Россия
Сообщений: 1299
"Я так понимаю", а почитать?
22 ноя 21, 14:13    [22399107]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
Наталья87
. Чтобы упорядочить данные внутри файла. Чтобы они не были раскиданы по всему файлу в хаотичном виде. Я так понимаю, после Backup&Restore именно это и происходит (данные таблиц становятся более упорядоченными внутри файла и идут последовательно).

еще раз - база данных (любая) - это файл произвольного доступа (random access). У операционной системы при чтении файлов есть "предиктивное" чтение. Поэтому, если 2 страницы одной и той же таблицы лежат подряд, то файловый кэш ОС скорее всего при обращении к такой первой странице считает и вторую.
Поэтому, как бы, последовательный перебор записей в таблицах быстрее после restore. Потому что рестор заливает таблицы по очереди.
Однако, последовательность данных в таблицах всегда случайная - т.е. как их записали, или как обновили в зависимости от "дырок" после удалений.
А обычно из БД стараются получить данные в каком-то упорядоченном виде. Который абсолютно точно не соответствует расположению записей в таблицах.
Индексы, которые способствуют выдаче по нужному порядку, строятся "потом". Например, в самом конце restore. И они расположены далеко от таблиц.
Опять возвращаемся к random access. Если на HDD "предиктивное чтение" ОС еще как-то помогало, то на SSD оно абсолютно бесполезно, т.к. чтение случайных страниц одинаково быстро.
И вообще, "дефрагментация" с SSD теряет смысл. Дефрагментация раньше нужна была только для того, чтобы файлы копировались быстрее. А копирование - это последовательное чтение страниц (блоков) файла.
Чего (последовательного чтения) при выборке данных из БД не бывает почти никогда.

p.s. вся эта идея "дефрагментации" она как из прошлого, лет 20-30 назад. Тем более по отношении к БД. И сейчас просто СТЫДНО упоминать такую бредятину. Как минимум, это индикатор того, что вы вообще не понимаете внутреннее устройство баз, дисков, ssd и прочего. А надо бы.
22 ноя 21, 14:32    [22399121]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
svd
Member

Откуда:
Сообщений: 223
Наталья87,

Если вам нужно делать backup/restore раз в полгода, ну создайте bat/cmd/sh, который это делает. Записываете вызов в скедалер и наслаждаетесь.

Что мешает делать это программно? У нас так и сделано. Правда идет управление роботом, контроль ведется несколькими программами одновременно. При старте компьютера специальная программа рапуска контролирующих программ проверяет статус запуска серверов, запуска соединения с железом и на минутку задерживается, чтоб сделать бэкап/рестор базы.
26 ноя 21, 12:17    [22401188]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
Все форумы / Delphi Ответить