SortMemBlockSize и SortMemUpperLimit
SortMemBlockSize и SortMemUpperLimit
[CyberMax: Тема отделена. Начало: FireBird и Фазы Луны.]
Спасибо, в принципе не совсем доказано.
FB действительно подтормаживает на таком малом обьеме, хотя решение найдено. постоянно делать select count(*) после такого обновления. и тогда никаких проблем.
Вот назрело еще несколько вопросов, возможно предложений для новых версий FB.
Вот есть вопрос в чем отличие.
#SortMemBlockSize = 1048576
от
#SortMemUpperLimit = 67108864
вот с SortMemUpperLimit все понятно, и еще вопрос можно задать както в процентном отношении от свободной памяти выделяемый размер. SortMemUpperLimit на например 50%.
Зачем это нужно. понятно что если сервер тогда просто знаеш сколько памяти свободной на ПК установил и все, а вот если embeded режим ну не известно сколько у клиента свободной памяти. и получается имет клиент Гиг памяти а работа ведется медленно, на большой базе, а так был бы параметр использоваться 50% и все. или есть такие варианты?
Вариант самостоятельно в программе проверить сколько есть памяти и изменить conf fb программно тоже не подходит, так как думаю возможны тормоза при работе FB должен сам выбирать, а сейчас как я понимаю при увеличении лимита будет swap windows, если конечно в работе действительно столько понадобится.
Спасибо, в принципе не совсем доказано.
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) выделяется свой, отдельный, кусок памяти.
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 его максимальный размер?
Не совсем так. Кусками этого размера FB будет выделять память под сортировку.kdv писал(а):4. в чем отличие - написано в firebird.conf. размер блока - это размер куска памяти на один запрос с сортировкой
Т.е. если сортировка не умещается в стандартный малый буффер, то выделяется доп память р-ром SortMemBlockSize.
Не хватает её - выделяем ещё и т.д.
Пока не выделим SortMemUpperLimit (в сумме - т.е. для всех одновременных сортировок).
Потом - идём на диск
жрать столько памяти без разрешения - это неприлично для любой программы. сортировки не везде превалируют, например, больше памяти жрет выборка по индексам.На разве так не оптимальной былоб для многих видов задач.
если бы был параметр использовать скажем 70% свободной памяти.
откуда известно, что он сортирует, и сколько?2. Сортирует.
тем более этот вопрос интересен в контексте embedded. приложение написано максимально неэффективно, например, сортирует гигантские выборки?
один запрос это один запрос.А что означает один запрос?
клиент выполняет запрос. у запроса plan sort. значит будет сортировка. В каком объеме, неизвестно. 10 клиентов выполняют этот же запрос - ресурсы под сортировку будут выделены в 10-кратном объеме.
то нужно пересмотреть приложение. т.е. понять смысл, зачем это делается, т.е. "сортируется 500 мег". Почему не 1 гиг? или не 1 мег...если мне нужно отсортировать 500 мег
И откуда известно, что будет сортировка?
блин. этот параметр - максимальный объем памяти, аллокируемой сервером под сортировку. Не сразу, а по мере появления нужд на сортировку. Вообще, для 1-10-100-1000 клиентов. Суммарно. А размер БЛОКА - это размер куска памяти (минимального), выделямого для сортировки ОДНОГО ЗАПРОСА.А не #SortMemUpperLimit = 67108864 его максимальный размер?
Наверное, с последующим разбором содержимого.
Код: Выделить всё
select * from table1, table1, table1 order by ...
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Разные люди бывают на свете. Разные запросы:
http://thedailywtf.com/forums/thread/107331.aspx
http://thedailywtf.com/forums/thread/107331.aspx