Создание RAM-диска для оптимизации ФБ
Модераторы: kdv, Alexey Kovyazin
Создание RAM-диска для оптимизации ФБ
Подскажите пожалуйста как организовать RAM-диск в ОЗУ компьютера. Это делается с пом. каких-нить утилит? Если да - то какие из них предпочтительнее использовать?
А то совет эт сделать - весьма понятен - если в оперативку запихать времянки ФБ - ускорение существенное д.б., а вот как реализовать это...
Буду оч. благодарен за линк на соответствующую тему...
Заранее спасибо!
А то совет эт сделать - весьма понятен - если в оперативку запихать времянки ФБ - ускорение существенное д.б., а вот как реализовать это...
Буду оч. благодарен за линк на соответствующую тему...
Заранее спасибо!
Кстати, извиняюсь - не "представился"...
Использую сервер Firebird 1.5.1.4481 CS.
Если все сортировки делаются в памяти - то тогда 2 вопроса по пов. параметров fbconfig:
1. Зачем тогда нужен параметр "Temporary directories"?
(туда начинают писаться времянки тогда, когда достигается размер SortMemUpperLimit для процесса, или как?)
2. Параметр "SortMemBlockSize".
Что за зверь? В .conf написано, что это количество памяти под каждый блок сортировки и по умолч. 1 Мб. В утилитке Firebird Configuration Manager (http://www.firebirdsql.org/index.php?op=files) по этому параметру написано следующее:
"In-memory sorting module
For Classic servers, these settings are defaulted to 0 (disabled) although they can be set, the values would apply to each client connection/server instance and thus consume a lot of memory."
Так все ж какого его значение по умолчанию для CS? Если про 0-ое значение для Классика правда - то следует ли изменить его, если память позволяет, но запросов с ORDER и GROUP BY по неиндексированным полям почти нет?
И последний вопрос, касающийся расположения временных файлов ФБ. Вычитал в одной из тем форума, что ФБ кладет файлы сортировки не только в свои врем. папки (или, получается, в память, в сл. ФБ 1.5), но и в темп винды, в зависимости от запроса.
Вопрос - это относилось только к пред. версиям ФБ, или ФБ 1.5 тоже может использовать врем. папку винды для хранения своих сортировок?
(поясню интерес - если темп винды исп-ся, то его имеет смысл положить на отд. диск, как минимум, а еще лучше - как-то запихнуть в память, благо, размер позволяет. Если же не исп-ся - то одной проблемой меньше )
Заранее благодарю за ответы!
Использую сервер Firebird 1.5.1.4481 CS.
Если все сортировки делаются в памяти - то тогда 2 вопроса по пов. параметров fbconfig:
1. Зачем тогда нужен параметр "Temporary directories"?
(туда начинают писаться времянки тогда, когда достигается размер SortMemUpperLimit для процесса, или как?)
2. Параметр "SortMemBlockSize".
Что за зверь? В .conf написано, что это количество памяти под каждый блок сортировки и по умолч. 1 Мб. В утилитке Firebird Configuration Manager (http://www.firebirdsql.org/index.php?op=files) по этому параметру написано следующее:
"In-memory sorting module
For Classic servers, these settings are defaulted to 0 (disabled) although they can be set, the values would apply to each client connection/server instance and thus consume a lot of memory."
Так все ж какого его значение по умолчанию для CS? Если про 0-ое значение для Классика правда - то следует ли изменить его, если память позволяет, но запросов с ORDER и GROUP BY по неиндексированным полям почти нет?
И последний вопрос, касающийся расположения временных файлов ФБ. Вычитал в одной из тем форума, что ФБ кладет файлы сортировки не только в свои врем. папки (или, получается, в память, в сл. ФБ 1.5), но и в темп винды, в зависимости от запроса.
Вопрос - это относилось только к пред. версиям ФБ, или ФБ 1.5 тоже может использовать врем. папку винды для хранения своих сортировок?
(поясню интерес - если темп винды исп-ся, то его имеет смысл положить на отд. диск, как минимум, а еще лучше - как-то запихнуть в память, благо, размер позволяет. Если же не исп-ся - то одной проблемой меньше )
Заранее благодарю за ответы!
эх, мда. Значит так:
temp всегда использовался для сортировок (order by без индекса, create/alter index active, и т.п.).
в YA впервые включили для temp-файлов флаг temporary (create file). Это означает что система (ОС) сама решает, где держать файл, если хватает или не хватает памяти.
В FB 1.03 (вроде как) и в FB 1.5 теперь временные файлы на виндах тоже создаются с флагом temporary.
насчет IB7 - не знаю.
Дальше. В YA, FB 1.5 и IB7 введены настройки размера буфера сортировок в памяти. тот самый sortmemblocksize. Понять, работает он или нет на нынешних версиях сложно - даже если "не работает", то винды все равно temorary-файлу показывают нулевую длину.
Т.е. надо взять искуственный запрос, сортирующий некоторый объем записи, и смотреть как в temp (на создающийся файл) так и на память, потребляемую сервером.
Дальше, по поводу defaults. Данная утилита всего-лишь сообщает ТЕКСТ ИЗ FIREBIRD.CONF И следовательно этот текст - правда.
А установка параметра - это его изменение и снятие комментария в виде #.
И еще правда - что означенная память выделяется для каждого запроса, сортирующего данные. и память удерживается пока запрос не закрыт (или записи не выбраны). Так что что в классике что в супере при большом числе клиентов и большом числе таких запросов не рекомендуется устанавливать большое значение softrmem. в любом случае, все это можно посмотреть taskmanager.
И конечно, исходя из вышеизложенного, никакой ram-диск для temp уже давно не нужен. ну разве что может быть для IB6, но это ж...
temp всегда использовался для сортировок (order by без индекса, create/alter index active, и т.п.).
в YA впервые включили для temp-файлов флаг temporary (create file). Это означает что система (ОС) сама решает, где держать файл, если хватает или не хватает памяти.
В FB 1.03 (вроде как) и в FB 1.5 теперь временные файлы на виндах тоже создаются с флагом temporary.
насчет IB7 - не знаю.
Дальше. В YA, FB 1.5 и IB7 введены настройки размера буфера сортировок в памяти. тот самый sortmemblocksize. Понять, работает он или нет на нынешних версиях сложно - даже если "не работает", то винды все равно temorary-файлу показывают нулевую длину.
Т.е. надо взять искуственный запрос, сортирующий некоторый объем записи, и смотреть как в temp (на создающийся файл) так и на память, потребляемую сервером.
Дальше, по поводу defaults. Данная утилита всего-лишь сообщает ТЕКСТ ИЗ FIREBIRD.CONF И следовательно этот текст - правда.
А установка параметра - это его изменение и снятие комментария в виде #.
И еще правда - что означенная память выделяется для каждого запроса, сортирующего данные. и память удерживается пока запрос не закрыт (или записи не выбраны). Так что что в классике что в супере при большом числе клиентов и большом числе таких запросов не рекомендуется устанавливать большое значение softrmem. в любом случае, все это можно посмотреть taskmanager.
И конечно, исходя из вышеизложенного, никакой ram-диск для temp уже давно не нужен. ну разве что может быть для IB6, но это ж...
1. О врем. файлах:
2. По пов. утилитки:
# ----------------------------
# In-memory sorting module
#
# The amount of memory allocated for each sort block.
#
# Type: integer
#
#SortMemBlockSize = 1048576
Так что по дефолтному значению еще есть неясность - для CS это 0 или 1 Mb. Как-нить по-точнее бы...
Спасибо за совет по определению используется ли буфер сортировок - щас проверю. Последнее уточнение по этому поводу - временные файлы ФБ все имеют только подобное название: fb_..., или могут называться как-нить по-другому? (Если могут - то подскажите плиз как, дабы смотреть темп директории было по-проще... )
Спасибо!
Т.е., если чуть-чуть конкретнее, то, если у меня ВСЕГДА свободно порядка 1 Гб ОЗУ, то врем. файлы ФБ, независимо, помещались бы они в темп винды или в темп-директорию, указанную через параметр firebird.conf "TempDirectories", на диск писаться не будут, а ОС будет ложить их в ОЗУ?kdv писал(а):Это означает что система (ОС) сама решает, где держать файл, если хватает или не хватает памяти.
2. По пов. утилитки:
насчет установки параметра - абсолютно согласен, но вот коменты то она берет не напрямую из firebird.conf, а из FBConfManager.lang, в кот. как раз по параметру "SortMemBlockSize" вставлены коменты, кот. нет в самом файле конфигурации (иначе бы и не спрашивал ). В firebird.conf по "SortMemBlockSize" написано исключительно следующее:kdv писал(а):Данная утилита всего-лишь сообщает ТЕКСТ ИЗ FIREBIRD.CONF И следовательно этот текст - правда.
А установка параметра - это его изменение и снятие комментария в виде #
# ----------------------------
# In-memory sorting module
#
# The amount of memory allocated for each sort block.
#
# Type: integer
#
#SortMemBlockSize = 1048576
Так что по дефолтному значению еще есть неясность - для CS это 0 или 1 Mb. Как-нить по-точнее бы...
Спасибо за совет по определению используется ли буфер сортировок - щас проверю. Последнее уточнение по этому поводу - временные файлы ФБ все имеют только подобное название: fb_..., или могут называться как-нить по-другому? (Если могут - то подскажите плиз как, дабы смотреть темп директории было по-проще... )
Спасибо!
дотошный ты наш, ну посмотрел бы хелп по createFile... ОС всегда создает временный файл на диске. Но вот держит она содержимое в памяти или пишет на диск - зависит целиком от ее разумения. Ну и, конечно, от FB, сколько определено sortmem.то, если у меня ВСЕГДА свободно порядка 1 Гб ОЗУ, то врем. файлы ФБ, независимо, помещались бы они в темп винды или в темп-директорию, указанную через параметр firebird.conf "TempDirectories", на диск писаться не будут, а ОС будет ложить их в ОЗУ?
не знаю, что там и где написано, у меня все это (про классик) написано прямо в firebird.conf. FB 1.5.1. файл аж от 6.09, у меня редко возникает потребность в его редактировании.В firebird.conf по "SortMemBlockSize" написано исключительно следующее:
Есть немного... Этим и берем... Хелп обязательно гляну.kdv писал(а):дотошный ты наш, ну посмотрел бы хелп по createFile...
Спасибо огроменное за доходчивое объяснение - теперь все понятно с темпами.kdv писал(а):ОС всегда создает временный файл на диске. Но вот держит она содержимое в памяти или пишет на диск - зависит целиком от ее разумения. Ну и, конечно, от FB, сколько определено sortmem.
Да темп у меня чистый - я его периодически чищу. Вот тока в механизме работы самой винды со своим темпом я не разбирался еще и не знаю какие врем. файлы винда сама может положить в темп и когда это может произойти. Поэтому и спросил. Этот вопрос уже решил. Вот тока действительно оч. сложно понять - используется ли буфер сортировок в памяти, если длина времянки в любом случае 0. (Что я и наблюдал при отработке запроса; память изменяется тоже, но вот тока все ли обрабатывается в памяти или нет - х.з. ...).kdv писал(а):и еще про темп - ты его сначала почисть. а когда будешь выполнять запросы с сортировкой - все и так увидишь
Т.о., подытоживая, получается, что чтобы для CS максимально избежать хранения содержимого времянки Осью на диске, при наличии свободной ОЗУ, нужно:
1. Увеличить размер параметра "SortMemUpperLimit" с 8Mb по умолчанию.
2. От греха по-дальше задать явное значение параметру "SortMemBlockSize" в тот же самый мег, к примеру.
Тогда - вопрос на ограничение:
Слышал, что увеличение того же параметра "DefaultDbCachePages" может привести в ряде случаев наоборот - к снижению производительности (частая запись, 10000 для SS и т.п.)...
Подскажите плиз - есть ли какие-нить подводные камни, противопоказания, кроме увеличения расхода ОЗУ сервера, к увеличению этих двух параметров "SortMem..."? (особенно - касательные производительности сервера) Или с их увеличением, пока еще есть резерв оперативки, хуже не будет точно?
Спасибо!
позвольте. Временные файлы FB создает сам. Они не создаются операционкой "от балды". Файл вообще не создается, пока кто-либо не вызовет CreateFile Поэтому при отсутствии 100 активных программ в temp совершенно четко видно, какие и чьи есть temp-файлы. Если что, рекомендую ProcMon от sysinternals.com.Да темп у меня чистый - я его периодически чищу. Вот тока в механизме работы самой винды со своим темпом я не разбирался еще и не знаю какие врем. файлы винда сама может положить в темп и когда это может произойти.
это ты очень давно слышал. сейчас проблем с 10000 cache pages для супера нет. На классике все равно больше 1024 выставлять не рекомендуется. А на супере даже IB7.5 расширило db cache pages до допустимых 131К страниц.Слышал, что увеличение того же параметра "DefaultDbCachePages" может привести в ряде случаев наоборот - к снижению производительности (частая запись, 10000 для SS и т.п.)
тогда каждый процесс классика под сортировки будет жрать 8мб и выше (до установленного лимита).Увеличить размер параметра "SortMemUpperLimit" с 8Mb по умолчанию.
Все остальное проверяется ТОЛЬКО ЭКСПЕРИМЕНТАЛЬНО. Допустим, ты сейчас наконфигурируешь, а в твоей задаче реально окажется что запросов, сортирующих АДЕКВАТНЫЕ объемы данных через врем. файлы нет. Ну и кому тогда это конфигурирование надо, и какой с него толк?
Видишь PLAN SORT - значит сортировка пойдет в памяти-на диске. Ну и подумай тут, сколько записей будет сортироваться. Прикинь объем, и одновременное число таких запросов.
а вообще все это читается на курсах - www.ibase.ru/crs_reg.htm. плюс оптимизатор и т.п. я даже удивляюсь, чего это я тут все рассказываю ...
Я бы пошел, но где я, а где Москва... Так что твой рассказ нужен.kdv писал(а):а вообще все это читается на курсах - www.ibase.ru/crs_reg.htm. плюс оптимизатор и т.п. я даже удивляюсь, чего это я тут все рассказываю ...
Если файл создан, но имеет нулевую длину, то сортировка идет в памяти. Как только ее не хватит, буфер будет записан на диск. Изменится ли длина файла, если запись кешировала ОС - не знаю.Alexx писал(а):Вот тока действительно оч. сложно понять - используется ли буфер сортировок в памяти, если длина времянки в любом случае 0. (Что я и наблюдал при отработке запроса; память изменяется тоже, но вот тока все ли обрабатывается в памяти или нет - х.з. ...).
С увеличением UpperLimit для классика можешь нарваться на своп под нагрузкой. BlockSize трогать вообще не рекомендую, особенно "от греха подальше".Alexx писал(а): 1. Увеличить размер параметра "SortMemUpperLimit" с 8Mb по умолчанию.
2. От греха по-дальше задать явное значение параметру "SortMemBlockSize" в тот же самый мег, к примеру.
Хуже точно не будет. Но BlockSize лучше все же не трогать!!!Alexx писал(а):Подскажите плиз - есть ли какие-нить подводные камни, противопоказания, кроме увеличения расхода ОЗУ сервера, к увеличению этих двух параметров "SortMem..."? (особенно - касательные производительности сервера) Или с их увеличением, пока еще есть резерв оперативки, хуже не будет точно?
Супер!!! Спасибо всем за толковые объяснения и советы - все стало предельно ясно! Класс!
Кстати, первые результаты действительно оч. радуют - у меня еще есть одна база, используемая тока для формирования тяжелых запросов, работающая на др. "сервере" под SS - так увеличение "SortMemUpperLimit" в 3 раза ускорило формирование отчетов на порядка 15-20%!
Еще раз спасибо всем!
...Ну, как бы...:kdv писал(а):а вообще все это читается на курсах - ... я даже удивляюсь, чего это я тут все рассказываю ...
Администрирование
Администирование клиентской и серверной части InterBase, Firebird, Yaffil. Настройка файла конфигурации и т.п.
Да я давно уже на эти курсы облизываюсь, нашальство подбиваю... Тока действительно - мне до Москвы 2 дня в одну сторону на собаках, а щас, пока ПО обкатывается, даже если на день отлучусь и производство встанет - не то, что на грелки, на носовые платки порвут... Поэтому пока приходится сглатывать слюну на предмет курсов, хотя хоцца...kdv писал(а):а вообще все это читается на курсах - www.ibase.ru/crs_reg.htm. плюс оптимизатор и т.п.
Интересно! Надо будет опробовать этот ФБ2...dimitr писал(а):Если твое "сейчас" относится к FB2, то верно
Кстати, первые результаты действительно оч. радуют - у меня еще есть одна база, используемая тока для формирования тяжелых запросов, работающая на др. "сервере" под SS - так увеличение "SortMemUpperLimit" в 3 раза ускорило формирование отчетов на порядка 15-20%!
Еще раз спасибо всем!
Вах... А проскакивало что в 1.5 SS это решено.dimitr писал(а):Если твое "сейчас" относится к FB2, то верно Иначе - проблемы имеют место быть.kdv писал(а):это ты очень давно слышал. сейчас проблем с 10000 cache pages для супера нет.
А где точнее можно посмотреть решено оно или нет? А то я сходу 20000 залепил.