iBase.ru Forum

[CyberMax: Тема отделена. Начало: FireBird и Фазы Луны.]

Спасибо, в принципе не совсем доказано.
FB действительно подтормаживает на таком малом обьеме, хотя решение найдено. постоянно делать select count(*) после такого обновления. и тогда никаких проблем.

Вот назрело еще несколько вопросов, возможно предложений для новых версий FB.

Вот есть вопрос в чем отличие.
#SortMemBlockSize = 1048576
от
#SortMemUpperLimit = 67108864

вот с SortMemUpperLimit все понятно, и еще вопрос можно задать както в процентном отношении от свободной памяти выделяемый размер. SortMemUpperLimit на например 50%.

Зачем это нужно. понятно что если сервер тогда просто знаеш сколько памяти свободной на ПК установил и все, а вот если embeded режим ну не известно сколько у клиента свободной памяти. и получается имет клиент Гиг памяти а работа ведется медленно, на большой базе, а так был бы параметр использоваться 50% и все. или есть такие варианты?

Вариант самостоятельно в программе проверить сколько есть памяти и изменить conf fb программно тоже не подходит, так как думаю возможны тормоза при работе FB должен сам выбирать, а сейчас как я понимаю при увеличении лимита будет swap windows, если конечно в работе действительно столько понадобится.

1. параметры сортировки без причин крутить не следует.
2. для начала нужно проверить, сколько в среднем и какого размера бывают файлы fb_....tmp в каталоге TEMP (системном или настроенном в firebird.conf). На основании этого можно подкрутить упомянутые параметры сортировки.
3. автоматических параметров сортировки нет. при задании нужно учитывать имеющийся объем памяти на машине, и вообще есть-ли запросы с сортировкой (см. пункт 2).
4. в чем отличие - написано в firebird.conf. размер блока - это размер куска памяти на один запрос с сортировкой. Размер лимита - общий лимит на объем памяти, выделяемой под сортировку, для суперсервера.
для каждого запроса с сортировкой (plan sort) выделяется свой, отдельный, кусок памяти.

1. параметры сортировки без причин крутить не следует.

На разве так не оптимальной былоб для многих видов задач.
если бы был параметр использовать скажем 70% свободной памяти.

Ну на пример задача. и клиентское embeded приложение.
А размер памяти клиента неизвестен.
Есть база строк 500 мег.

Нужно отсортировать или сгруппировать данные, что посути одно и тоже. при работе.

1. Сервер читает данные в свой буфер (сейчас он жестко в конфиге макс.)
2. Сортирует.
3. Сбрасывает на диск.
.....

4. Сливает все файлы в один.

5. Выдает результат.

Гараздо эффективней и быстрей велась бы работа, если бы размер этого буфера использовался максимально от свободной памяти клиента.

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

в чем отличие - написано в firebird.conf. размер блока - это размер куска памяти на один запрос с сортировкой. Размер лимита - общий лимит на объем памяти, выделяемой под сортировку, для суперсервера.
для каждого запроса с сортировкой (plan sort) выделяется свой, отдельный, кусок памяти.

не могу понять
А что означает один запрос?

Ну например я один клиент у сервера, одно соединение.

если мне нужно отсортировать 500 мег, без индексов и.т.д ну просто строк в базе то что будет сервер использовать только 1МБ. памяти.

#SortMemBlockSize = 1048576


А не #SortMemUpperLimit = 67108864 его максимальный размер?

kdv писал(а):4. в чем отличие - написано в firebird.conf. размер блока - это размер куска памяти на один запрос с сортировкой

Не совсем так. Кусками этого размера FB будет выделять память под сортировку.
Т.е. если сортировка не умещается в стандартный малый буффер, то выделяется доп память р-ром SortMemBlockSize.
Не хватает её - выделяем ещё и т.д.
Пока не выделим SortMemUpperLimit (в сумме - т.е. для всех одновременных сортировок).
Потом - идём на диск

На разве так не оптимальной былоб для многих видов задач.
если бы был параметр использовать скажем 70% свободной памяти.

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

2. Сортирует.

откуда известно, что он сортирует, и сколько?

тем более этот вопрос интересен в контексте embedded. приложение написано максимально неэффективно, например, сортирует гигантские выборки?

А что означает один запрос?

один запрос это один запрос.
клиент выполняет запрос. у запроса plan sort. значит будет сортировка. В каком объеме, неизвестно. 10 клиентов выполняют этот же запрос - ресурсы под сортировку будут выделены в 10-кратном объеме.

если мне нужно отсортировать 500 мег

то нужно пересмотреть приложение. т.е. понять смысл, зачем это делается, т.е. "сортируется 500 мег". Почему не 1 гиг? или не 1 мег...
И откуда известно, что будет сортировка?

А не #SortMemUpperLimit = 67108864 его максимальный размер?

блин. этот параметр - максимальный объем памяти, аллокируемой сервером под сортировку. Не сразу, а по мере появления нужд на сортировку. Вообще, для 1-10-100-1000 клиентов. Суммарно. А размер БЛОКА - это размер куска памяти (минимального), выделямого для сортировки ОДНОГО ЗАПРОСА.

Огромное спасибо, за полный ответ.

кстати. на sql.ru год или два назад некто заполучил приложение на ib/fb, которое при 100мб базе умудрялось при некоторых операциях в temp генерить временный файл 1 гиг и более.
человек спрашивал, как это дело побороть. посоветовали выкинуть прогу, ибо исходников не было.

Наверное, с последующим разбором содержимого.

Разные люди бывают на свете. Разные запросы:
http://thedailywtf.com/forums/thread/107331.aspx

да, про отвертку интересно. больше всего меня позабавила реакция шефа, который еще и настучал по голове Ивану.