Создание RAM-диска для оптимизации ФБ

Alexx · Сообщение **Alexx** » 20 дек 2004, 13:46

Подскажите пожалуйста как организовать RAM-диск в ОЗУ компьютера. Это делается с пом. каких-нить утилит? Если да - то какие из них предпочтительнее использовать?
А то совет эт сделать - весьма понятен - если в оперативку запихать времянки ФБ - ускорение существенное д.б., а вот как реализовать это...
Буду оч. благодарен за линк на соответствующую тему...

Заранее спасибо!

Сообщение **kdv** » 20 дек 2004, 15:16

никак не надо организовывать, потому что это не надо, и по производительности ничего не даст.
то есть, всякие ram-drive это штуки посторонние и подозрительные, поэтому до 1.5 лучше temp на отдельный hdd делать, а в 1.5 оно само в памяти сортировки делает. см. fbconfig.

Alexx · Сообщение **Alexx** » 21 дек 2004, 09:16

Кстати, извиняюсь - не "представился"...
Использую сервер 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 тоже может использовать врем. папку винды для хранения своих сортировок?
(поясню интерес - если темп винды исп-ся, то его имеет смысл положить на отд. диск, как минимум, а еще лучше - как-то запихнуть в память, благо, размер позволяет. Если же не исп-ся - то одной проблемой меньше

)

Заранее благодарю за ответы!

Сообщение **kdv** » 21 дек 2004, 09:53

эх, мда. Значит так:

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, но это ж...

Alexx · Сообщение **Alexx** » 22 дек 2004, 09:25

1. О врем. файлах:

kdv писал(а):Это означает что система (ОС) сама решает, где держать файл, если хватает или не хватает памяти.

Т.е., если чуть-чуть конкретнее, то, если у меня ВСЕГДА свободно порядка 1 Гб ОЗУ, то врем. файлы ФБ, независимо, помещались бы они в темп винды или в темп-директорию, указанную через параметр firebird.conf "TempDirectories", на диск писаться не будут, а ОС будет ложить их в ОЗУ?

2. По пов. утилитки:

kdv писал(а):Данная утилита всего-лишь сообщает ТЕКСТ ИЗ FIREBIRD.CONF И следовательно этот текст - правда.
А установка параметра - это его изменение и снятие комментария в виде #

насчет установки параметра - абсолютно согласен, но вот коменты то она берет не напрямую из firebird.conf, а из FBConfManager.lang, в кот. как раз по параметру "SortMemBlockSize" вставлены коменты, кот. нет в самом файле конфигурации (иначе бы и не спрашивал

). В firebird.conf по "SortMemBlockSize" написано исключительно следующее:

# ----------------------------
# In-memory sorting module
#
# The amount of memory allocated for each sort block.
#
# Type: integer
#
#SortMemBlockSize = 1048576

Так что по дефолтному значению еще есть неясность - для CS это 0 или 1 Mb.

Как-нить по-точнее бы...

Спасибо за совет по определению используется ли буфер сортировок - щас проверю. Последнее уточнение по этому поводу - временные файлы ФБ все имеют только подобное название: fb_..., или могут называться как-нить по-другому? (Если могут - то подскажите плиз как, дабы смотреть темп директории было по-проще...

)

Спасибо!

Сообщение **kdv** » 22 дек 2004, 10:01

то, если у меня ВСЕГДА свободно порядка 1 Гб ОЗУ, то врем. файлы ФБ, независимо, помещались бы они в темп винды или в темп-директорию, указанную через параметр firebird.conf "TempDirectories", на диск писаться не будут, а ОС будет ложить их в ОЗУ?

дотошный ты наш, ну посмотрел бы хелп по createFile... ОС всегда создает временный файл на диске. Но вот держит она содержимое в памяти или пишет на диск - зависит целиком от ее разумения. Ну и, конечно, от FB, сколько определено sortmem.

В firebird.conf по "SortMemBlockSize" написано исключительно следующее:

не знаю, что там и где написано, у меня все это (про классик) написано прямо в firebird.conf. FB 1.5.1. файл аж от 6.09, у меня редко возникает потребность в его редактировании.

Сообщение **kdv** » 22 дек 2004, 12:17

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

Alexx · Сообщение **Alexx** » 22 дек 2004, 14:27

kdv писал(а):дотошный ты наш, ну посмотрел бы хелп по createFile...

Есть немного...

Этим и берем... Хелп обязательно гляну.

kdv писал(а):ОС всегда создает временный файл на диске. Но вот держит она содержимое в памяти или пишет на диск - зависит целиком от ее разумения. Ну и, конечно, от FB, сколько определено sortmem.

Спасибо огроменное за доходчивое объяснение - теперь все понятно с темпами.

kdv писал(а):и еще про темп - ты его сначала почисть. а когда будешь выполнять запросы с сортировкой - все и так увидишь

Да темп у меня чистый - я его периодически чищу. Вот тока в механизме работы самой винды со своим темпом я не разбирался еще и не знаю какие врем. файлы винда сама может положить в темп и когда это может произойти. Поэтому и спросил. Этот вопрос уже решил. Вот тока действительно оч. сложно понять - используется ли буфер сортировок в памяти, если длина времянки в любом случае 0. (Что я и наблюдал при отработке запроса; память изменяется тоже, но вот тока все ли обрабатывается в памяти или нет - х.з. ...).

Т.о., подытоживая, получается, что чтобы для CS максимально избежать хранения содержимого времянки Осью на диске, при наличии свободной ОЗУ, нужно:
1. Увеличить размер параметра "SortMemUpperLimit" с 8Mb по умолчанию.
2. От греха по-дальше задать явное значение параметру "SortMemBlockSize" в тот же самый мег, к примеру.

Тогда - вопрос на ограничение:
Слышал, что увеличение того же параметра "DefaultDbCachePages" может привести в ряде случаев наоборот - к снижению производительности (частая запись, 10000 для SS и т.п.)...
Подскажите плиз - есть ли какие-нить подводные камни, противопоказания, кроме увеличения расхода ОЗУ сервера, к увеличению этих двух параметров "SortMem..."? (особенно - касательные производительности сервера) Или с их увеличением, пока еще есть резерв оперативки, хуже не будет точно?

Спасибо!

Сообщение **kdv** » 22 дек 2004, 15:54

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

позвольте. Временные файлы FB создает сам. Они не создаются операционкой "от балды". Файл вообще не создается, пока кто-либо не вызовет CreateFile

Поэтому при отсутствии 100 активных программ в temp совершенно четко видно, какие и чьи есть temp-файлы. Если что, рекомендую ProcMon от sysinternals.com.

Слышал, что увеличение того же параметра "DefaultDbCachePages" может привести в ряде случаев наоборот - к снижению производительности (частая запись, 10000 для SS и т.п.)

это ты очень давно слышал. сейчас проблем с 10000 cache pages для супера нет. На классике все равно больше 1024 выставлять не рекомендуется. А на супере даже IB7.5 расширило db cache pages до допустимых 131К страниц.

Увеличить размер параметра "SortMemUpperLimit" с 8Mb по умолчанию.

тогда каждый процесс классика под сортировки будет жрать 8мб и выше (до установленного лимита).

Все остальное проверяется ТОЛЬКО ЭКСПЕРИМЕНТАЛЬНО. Допустим, ты сейчас наконфигурируешь, а в твоей задаче реально окажется что запросов, сортирующих АДЕКВАТНЫЕ объемы данных через врем. файлы нет. Ну и кому тогда это конфигурирование надо, и какой с него толк?

Видишь PLAN SORT - значит сортировка пойдет в памяти-на диске. Ну и подумай тут, сколько записей будет сортироваться. Прикинь объем, и одновременное число таких запросов.

Сообщение **kdv** » 22 дек 2004, 15:56

а вообще все это читается на курсах - www.ibase.ru/crs_reg.htm. плюс оптимизатор и т.п. я даже удивляюсь, чего это я тут все рассказываю ...

Лысый · Сообщение **Лысый** » 22 дек 2004, 16:05

kdv писал(а):а вообще все это читается на курсах - www.ibase.ru/crs_reg.htm. плюс оптимизатор и т.п. я даже удивляюсь, чего это я тут все рассказываю ...

Я бы пошел, но где я, а где Москва... Так что твой рассказ нужен.

Сообщение **kdv** » 22 дек 2004, 16:11

на курсах 70% иногородних, между прочим. и обучиться, и по москве пошляться.

Лысый · Сообщение **Лысый** » 22 дек 2004, 16:13

kdv писал(а):на курсах 70% иногородних, между прочим. и обучиться, и по москве пошляться.

Мне не светит, ненакого задачи скинуть... оракловый сервер еще мне навесили (админы уволились).

dimitr · Сообщение **dimitr** » 22 дек 2004, 19:52

Alexx писал(а):Вот тока действительно оч. сложно понять - используется ли буфер сортировок в памяти, если длина времянки в любом случае 0. (Что я и наблюдал при отработке запроса; память изменяется тоже, но вот тока все ли обрабатывается в памяти или нет - х.з. ...).

Если файл создан, но имеет нулевую длину, то сортировка идет в памяти. Как только ее не хватит, буфер будет записан на диск. Изменится ли длина файла, если запись кешировала ОС - не знаю.

Alexx писал(а): 1. Увеличить размер параметра "SortMemUpperLimit" с 8Mb по умолчанию.
2. От греха по-дальше задать явное значение параметру "SortMemBlockSize" в тот же самый мег, к примеру.

С увеличением UpperLimit для классика можешь нарваться на своп под нагрузкой. BlockSize трогать вообще не рекомендую, особенно "от греха подальше".

Alexx писал(а):Подскажите плиз - есть ли какие-нить подводные камни, противопоказания, кроме увеличения расхода ОЗУ сервера, к увеличению этих двух параметров "SortMem..."? (особенно - касательные производительности сервера) Или с их увеличением, пока еще есть резерв оперативки, хуже не будет точно?

Хуже точно не будет. Но BlockSize лучше все же не трогать!!!

dimitr · Сообщение **dimitr** » 22 дек 2004, 19:55

kdv писал(а):это ты очень давно слышал. сейчас проблем с 10000 cache pages для супера нет.

Если твое "сейчас" относится к FB2, то верно

Иначе - проблемы имеют место быть.

Alexx · Сообщение **Alexx** » 23 дек 2004, 10:13

Супер!!! Спасибо всем за толковые объяснения и советы - все стало предельно ясно! Класс!

kdv писал(а):а вообще все это читается на курсах - ... я даже удивляюсь, чего это я тут все рассказываю ...

...Ну, как бы...:

Администрирование
Администирование клиентской и серверной части InterBase, Firebird, Yaffil. Настройка файла конфигурации и т.п.

kdv писал(а):а вообще все это читается на курсах - www.ibase.ru/crs_reg.htm. плюс оптимизатор и т.п.

Да я давно уже на эти курсы облизываюсь, нашальство подбиваю... Тока действительно - мне до Москвы 2 дня в одну сторону на собаках, а щас, пока ПО обкатывается, даже если на день отлучусь и производство встанет - не то, что на грелки, на носовые платки порвут... Поэтому пока приходится сглатывать слюну на предмет курсов, хотя хоцца...

dimitr писал(а):Если твое "сейчас" относится к FB2, то верно

Интересно! Надо будет опробовать этот ФБ2...

Кстати, первые результаты действительно оч. радуют - у меня еще есть одна база, используемая тока для формирования тяжелых запросов, работающая на др. "сервере" под SS - так увеличение "SortMemUpperLimit" в 3 раза ускорило формирование отчетов на порядка 15-20%!

Еще раз спасибо всем!

Лысый · Сообщение **Лысый** » 23 дек 2004, 10:20

>Интересно! Надо будет опробовать этот ФБ2...
Когда выйдет - тогда и опробуем

Alexx · Сообщение **Alexx** » 23 дек 2004, 11:51

Лысый писал(а):Когда выйдет - тогда и опробуем

Точно

givi · Сообщение **givi** » 28 дек 2004, 12:47

dimitr писал(а):
kdv писал(а):это ты очень давно слышал. сейчас проблем с 10000 cache pages для супера нет.
Если твое "сейчас" относится к FB2, то верно Иначе - проблемы имеют место быть.

Вах... А проскакивало что в 1.5 SS это решено.
А где точнее можно посмотреть решено оно или нет? А то я сходу 20000 залепил.

dimitr · Сообщение **dimitr** » 31 дек 2004, 10:46

Не решалось это в FB 1.5. Смотреть нигде не надо, достаточно поверить

Еще раз напомню, что проблема наблюдается при массовых обновлениях данных, т.е. когда кол-во "грязных" страниц кеша превышает 10К. Для сценариев типа "много читаем, мало пишем" никаких проблем с производительностью нет.