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

Откуда: Донецк
Сообщений: 4936
Наталья87
А к чему плохому это может привести?
К тормозам, которые вы пытаетесь избежать. Вам уже ответили Сибиряков и kdv. Это идиотизм - запускать при каждом запуске программы долгую тяжелую операцию.

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

Он как раз очень нужен. Ведь это единственный вариант собрать мусор для вас (кроме backup-restore, что еще дольше), раз вы программу не можете переделать в пристойное состояние.

Наталья87
Но set statistics index при каждом 10-м запуске программы (чтобы не нервировать пользователей - при каждом запуске не стоит, наверное это делать) ведь не повредит?

Повредит по тем же причинам - бесполезные тормоза.
Статистику чаще всего достаточно считать один раз - после наполнения базы данными.
Либо вообще 0 раз, если создавать индексы после наполнения базы данными (как делает restore, например).
У вас, видимо, ни разу не считалась на той базе, на которой помогло ускорить.
Да, бывают случаи, когда полезно статистику обновить раз в месяц или около того. Накопление данных может изменить статистику и планы. Но это не ваш случай.
Ну и делать это нужно на сервере, опять же, ночью, ведь это тормозит, а у вас этого нет.

Хотите, раз для вас это допустимо (базы у вас, я так понял, крохотные), делайте backup-restore еженедельно, да и всё. Отмечайте в реестре дату последнего успешного, и проверяйте, чтоб это был 7-й день с тех пор.
Запускайте только на компьютере, где база.
Предварительно остановив службу Firebird и переименовав файл базы.
Ну, что ж. Зато не надо swwep запускать и set stat :))
19 ноя 21, 11:43    [22397870]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
X11
пишущая транзакция - для записи данных и она - максимально короткая.

а потом приходит какой-нибудь чел, лезет ИБЭкспертом в промышленную базу с 500 одновременных пользователей, выполняет там какой-нибудь запрос и бросает ИБЭксперт на пару суток.
И через сутки-двое начинаются вопли "у нас всё тормозит". Если в конторе есть кто-то умный, который знает про mon$ - смотрит и находит негодяя по IP, ИБэксперт отрубают, и дают тому канделябром по башке.
Иногда после этого пишут скрипт, который раз в 1-2 часа отрубает все коннекты, где имя процесса - ibexpert.exe.
Как-то так.
19 ноя 21, 12:04    [22397879]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

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

Тут проблема в том, что если
- в однопользовательском варианте вы можете и свип запускать из приложения (не через гфикс), и бэкап делать тоже (не через гбак).
- в многопользовательском приложении запускать гбак или гфикс, или пересчитывать статистику через какие-то интервалы - значит у вас в КАЖДОМ приложении такое возможно, а значит вы будете "долбить" сервер этими задачами, причем только в момент работы пользователей. В многопользовательском случае по любому нужен админ, и настройка бэкапов и свипов именно на сервере.

p.s. так что там с 22397719


Ну у нас "сервер" только в кавычках. Не какая-то там высоконагруженная система, а программка на 1-3 компьютера. Ну максимум 8. Там где больше 3 компьютеров по любому есть какой нибудь админ и наверное автоматические свипы не нужны ...
19 ноя 21, 12:05    [22397881]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
энди
Member

Откуда: Киров, Россия
Сообщений: 1299
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?
19 ноя 21, 13:25    [22397926]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

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

YuRock
sweep interval можно отключить тогда (через gfix установить 0)

Не надо обезьянам давать ЭТУ гранату. Уже были прецеденты - угробит базу.

Posted via ActualForum NNTP Server 1.5

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

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


Да. Но это не часами длится. Обычно не более 1 минуты, а при нормальной работе секунд 10-15. Очень удобно - если произошла ошибка или пользователь нажал "Отменить" - просто делаем Rollback и всё.
19 ноя 21, 13:42    [22397934]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

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

YuRock
sweep interval можно отключить тогда (через gfix установить 0)

Не надо обезьянам давать ЭТУ гранату. Уже были прецеденты - угробит базу.


И правда - да пусть чистится и автоматически тоже. Жалко чтоли.
А как базу можно этим угробить? Разве что тормозить база начнёт.
А угробить базу из практики можно если нет ИБП и мигает свет, либо бэд-блоки на винте, либо очень редко - при сбоях оперативной памяти.
19 ноя 21, 13:45    [22397936]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

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

Наталья87
А как базу можно этим угробить? Разве что тормозить база начнёт.

Да, именно тормозить начнёт. До такой степени, что разработчика увольняют, а
систему мигрируют на другую СУБД.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 114
X11
DmSer
Сталкивались с такими проблемами. Знаем. Решается просто: разделяем транзакции для чтения и записи. Для чтения можно использовать длинную транзакцию, она не повлияет на накопление мусора в БД. Для записи используем короткие транзакции, которые запускаем только на момент записи в БД. Мусор в этом случае не копится. База не тормозит.


Зачем дальнейшая дискуссия и танцы з бубном после этого сообщения?

Читающая транзакция должна быть readonly.
При открытии окна добавления/редактирования товара/объекта не открывать ничего на запись. А вот, когда пользователь нажимает сохранить и выполняется Commit, то для этого использовать пишущую транзакцию. т.е. пишущая транзакция - для записи данных и она - максимально короткая.

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


Даже не знаю, какие транзакции Delphi использует при работе с TIBTransaction, TIBQuery. Судя по всему - по умолчанию транзакции вида Snapshot. Вполне возможно, что пишущие используются для чтения. Вот только я после чтения их всё равно освобождаю (Free) - надеюсь, это решает проблему. Free делать приходится - так как иначе утечки памяти очень быстро копятся и потребляют все ресурсы компьютера.
19 ноя 21, 13:48    [22397938]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

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

Наталья87
А как базу можно этим угробить? Разве что тормозить база начнёт.

систему мигрируют на другую СУБД.


Это нереально. Тем более с вашим подходом "переводите по одной форме с IBX на FireDAC как раз до конца жизни за год и успеете. Перевести 400 тысяч строк кода - тем более что там куча быдлокода и говнокода на другую СУБД невозможно, либо оно того не стоит.

Скорее пользователи в этом случае сделают backup&restrore, поставят помощнее комп или в самом крайнем случае начнут с чистой базы данных.
19 ноя 21, 13:51    [22397940]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

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

Наталья87
Это нереально.

Целый фейсбук переводили на другую СУБД несколько раз. Думаете, у них меньше
говнокода, чем у вас?..

Posted via ActualForum NNTP Server 1.5

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

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

Наталья87
Это нереально.

Целый фейсбук переводили на другую СУБД несколько раз. Думаете, у них меньше
говнокода, чем у вас?..


Но там и бюджеты и масштабы другие. В наших небольших проектах не знаю стоит ли оно того ...
19 ноя 21, 14:09    [22397948]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

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

В ваших небольших бюджетах обычно просто берут 1С.

Posted via ActualForum NNTP Server 1.5

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

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


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

Не делайте так никогда. Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся, потом пошёл на обед. И в итоге транзакция может висеть очень долго.
Пишущая транзакция должна быть по времени максимально короткой. Стартовать в момент, когда пользователь нажал "Сохранить".
Дайте угадать, вы используете DBWare-компонеты, типа TDBEdit и поэтому не можете отказаться от старта транзакции перед изменением данных?
19 ноя 21, 14:26    [22397958]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

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

goldmi45
Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся,
потом пошёл на обед. И в итоге транзакция может висеть очень долго.

Приведённые ею статистики такого не показывают.

Posted via ActualForum NNTP Server 1.5

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

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

goldmi45
Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся,
потом пошёл на обед. И в итоге транзакция может висеть очень долго.

Приведённые ею статистики такого не показывают.

Я лишь сказал, что не нужно начинать транзакцию при открытии диалога.
К тому же неизвестно, в какой момент эти статистики были собраны. Может быть, автоматический сборщик мусора запустился и всё колом встало.
19 ноя 21, 14:49    [22397977]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Dimitry Sibiryakov
Member

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

goldmi45
Может быть, автоматический сборщик мусора запустился и всё колом встало.

Если запустился автосвип (который часто путают со сборщиком мусора), то это
должно быть отражено в firebird.log. И "колом встало" при его работе это не про
приложение на полтора пользователя, там нужна гораздо более интенсивная нагрузка.

Запуск автосвипа неизбежен после отключения электричества, но я не слышал
упоминаний от аффтарши о "база тормозит после отключения электричества", только
"через некоторое время".

Posted via ActualForum NNTP Server 1.5

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

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

да всё это теоретизирование. Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.
19 ноя 21, 15:01    [22397988]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2657
ТС уже раз пять прямо сказала, что НЕ БУДЕТ переделывать "как правильно", а они все равно скачут перед ней, как самцы павианов перед самкой, "короткие трпнзакции", "сборка мусора"...
19 ноя 21, 16:11    [22398023]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
Наталья87
Member

Откуда:
Сообщений: 114
ъъъъъ
ТС уже раз пять прямо сказала, что НЕ БУДЕТ переделывать "как правильно", а они все равно скачут перед ней, как самцы павианов перед самкой, "короткие трпнзакции", "сборка мусора"...


Почему же нет? Буду переделывать. Только переделки времени требуют. Особенно если речь про 400 000 строк кода.
И требование писать новый код никто не отменял :(
И понять, как не открывать пишущие транзакции для чтения в Delphi тоже.
Плохо тут то, что данные ошибки не проявляют себя сразу, а потом привыкаешь так писать.

Столько советов, что мозг уже не соображает, за что схватиться. Извините, если туплю :(

Хотя вопрос по сути уже решён, совет с "set statistics index" помог. Да 2 гигабайтной базе много и нее надо наверное ...



kdv
goldmi45,

да всё это теоретизирование. Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.


IBExpert (Execute and Fetch All) показывает так (cтоит сказать, что у меня Intel Core i7 и SSD, а у пользователей Pentium 4 и HDD потому сложно понять их проблемы с тормозами ...):

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

------ Performance info ------
Prepare time = 0ms
Execute time = 1s 452ms
Avg fetch time = 0,01 ms
Current memory = 13 053 936
Max memory = 48 897 120
Memory buffers = 2 048
Reads from disk to cache = 3 949
Writes from cache to disk = 4
Fetches from cache = 316 413

После set statistics index Sweep (размер базы остался 2 Гб):

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 472ms
Avg fetch time = 0,01 ms
Current memory = 12 719 024
Max memory = 71 616 052
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 316 393

После Backup&Restore (размер бэкапа 47 Мб) база стала вместо 2 Гб - 117 Мб:

И запрос:

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 412ms
Avg fetch time = 0,01 ms
Current memory = 9 146 440
Max memory = 9 365 804
Memory buffers = 2 048
Reads from disk to cache = 4 162
Writes from cache to disk = 4
Fetches from cache = 284 673

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

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

И понять, как не открывать пишущие транзакции для чтения в Delphi тоже.

Двойной клик мышью по объекту TIBTransaction открывает некий диалог, где все это, решив разобраться, можно настроить.
Т.е. в самом минимальном варианте нужны будут два объекта: TIBTransactionReadOnly и TIBTransactionReadWrite.

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

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

Наталья87
Хотя вопрос по сути уже решён, совет с "set statistics index" помог.

А не должен был по идее.

Posted via ActualForum NNTP Server 1.5

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

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


kdv
...Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.


IBExpert (Execute and Fetch All) показывает так (cтоит сказать, что у меня Intel Core i7 и SSD, а у пользователей Pentium 4 и HDD потому сложно понять их проблемы с тормозами ...):

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

------ Performance info ------
Prepare time = 0ms
Execute time = 1s 452ms
Avg fetch time = 0,01 ms
Current memory = 13 053 936
Max memory = 48 897 120
Memory buffers = 2 048
Reads from disk to cache = 3 949
Writes from cache to disk = 4
Fetches from cache = 316 413

После set statistics index Sweep (размер базы остался 2 Гб):

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 472ms
Avg fetch time = 0,01 ms
Current memory = 12 719 024
Max memory = 71 616 052
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 316 393

После Backup&Restore (размер бэкапа 47 Мб) база стала вместо 2 Гб - 117 Мб:

И запрос:

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 412ms
Avg fetch time = 0,01 ms
Current memory = 9 146 440
Max memory = 9 365 804
Memory buffers = 2 048
Reads from disk to cache = 4 162
Writes from cache to disk = 4
Fetches from cache = 284 673

Это п....ц.
Соответствие ответа вопросу - меньше, чем у виртуального собеседника уровня ELIZA, 1966г.
19 ноя 21, 17:55    [22398072]     Ответить | Цитировать Сообщить модератору
 Re: Ускорение работы растущей базы данных Firebird через приложение на Delphi  [new]
kdv
Member

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

ок, спасибо. Хотя размер страницы из (gstat -h) тоже бы не помешал. Ну да ладно.
Допустим, размер страницы 8к. Хотя, если соотнести с уровнем знаний, то должен быть 4к.
Итого. 4162 страниц размером (допустим) 8к прочитано за 1.4 сек. Это получается 23мб/в секунду.
Для 4к страниц это 11.6мб в секунду.

То есть, база на каком-то ноутбучном диске HDD примерно 10летней давности, не меньше.
Наталья87
После set statistics index Sweep (размер базы остался 2 Гб):

ну почему вы считаете что после каких-то операций размер базы должен уменьшиться?
Размер базы НИКОГДА не уменьшается, ни при каких операциях - удаление, свип, реиндексация, и т.д.
Уменьшение файла БД вообще никакой СУБД никогда не делается.
А рестор - это создание новой БД и заполнение ее данными из бэкапа. Весь файл БД строится заново.

Кроме того - ну уменьшилась у вас база в 20 раз. И что? Как было время выполнения запроса 1.4 секунды, так и осталось. Потому что читалось одно и то же (примерно) количество страницы. Результат page reads 4162 относительно 3950 предыдущих, видимо, из-за заполнения кэша (там плюс-минус 2048 страниц кэша).
Fetches меньше? Ну, м.б. чуть поплотнее данные на страницах стали. и всё.
Наталья87
cтоит сказать, что у меня Intel Core i7 и SSD

не верю. по цифрам никакого ssd у вас нет.

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

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

Для примера. База 26 гиг, tpcc. размер страницы 16к. amd 3700x.
select count(*) from order_line
(если что - результат = 90млн записей)
Execute time = 46s 687ms
Memory buffers = 2 048
Reads from disk to cache = 532 637
Firebird 3 (версия ФБ тут без разницы, т.к. фактически меряется скорость обращения к диску)

вычисляем, получаем ... 178 мегабайт в секунду. На HDD ST200DM01.

Вам надо CrystalDiskMark запустить, посмотреть диск. А то ваш диск на ssd не тянет совершенно, и даже на hdd.

Скопировал базу на ssd (samsung 860 evo, sata3), получил
Execute time = 22s 500ms

То есть, 369 мегабайт в секунду (столько же показывает и диспетчер задач).

p.s. и последнее - fetch All для select count зачем? там 1 запись выводится.
19 ноя 21, 19:55    [22398140]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Delphi Ответить