proNovell

На свежеустановленном и введёном в рабочее дерево NW6.5SP5 был установлен BAB r11.1SP3, под который я установил pervasive версии 9.52. И обнаруживаю через несколько дней работы удивительную вещь - ЧТО БЫ Я НИ ПИСАЛ в bti.cfg, сразу же после перезагрузки сервера (перезагружал три раза) модуль NWMKDE.NLM отжирает ~800 мегабайт памяти! Смотрю NRM-ом и SEG.NLM - результаты совпадают. На сервере памяти 4Гига, вот мой bti.cfg:

[MicroKernel]
MaxFiles=500
MaxCursors=25000
BalancedTrees=NO
ForceFileVersion=0700
SystemData=YES
MaxDatabases=10
Logging=NO
CacheSize=262144
CompressedBufferSize=5
ExtendedBufferSize=64
MergeSortBufferSize=0
MaxRecSize=63
CachePartitioning=YES
TransDurability=YES
TransLogBufferSize=1024
TransLogFileSize=1024
SysTransBundleLimit=65535
SysTransTimeLimit=10000
MaxClients=50
BackgroundThreads=50
WaitLockTimeout=50
TransLogDirectory=SYS:/SYSTEM/MKDE/LOG
WorkDirectory=
Trace=NO
TraceFile=SYS:/SYSTEM\MKDE.TRA
TraceDataBufferLength=256
TraceKeyBufferLength=256
TraceOpsList=ALL
LoadRouter=NO
RouterCommBufferSize=16
RuntimeServerSupportMode=0000
MaxCacheUsage=10
TransLogging=YES
Validate Request=NO
Max Pending IO=1024
File Growth Factor=15
Page Server Allow Client Cache=YES
Prompt For Client Credentials=NO
Allow Client-Stored Credentials=YES
Use FileIO Mutex=NO

Ключевые параметры выделены цветом, судя по ним максимум, что может отожрать NWMKDE.NLM - это 10% от общей памяти (сразу резервируется 256 мбайт), т.е., не более 400 мегабайт, а он зараза, отъедает в два раза больше! Что за на фиг? Они там единицы измерения случайно не поменяли? А то я думаю, что пишу 256 мбайт, а там - гигабайты .

Это надо не в BTI.CFG смотреть, а через PCC. А в процентах задается кеш второго уровня . Так что может и не жрет ничего, а считает что так и надо. 256+400+еще чего где-то близко к 800 будет. Хотя я не уверен, что они в 9.52 в BTI.CFG параметры хранят. Я вот посмотрел сейчас, на серваке с 768MB занято типа 39МВ.

Сергей Дубров писал(а):На свежеустановленном и введёном в рабочее дерево NW6.5SP5 был установлен BAB r11.1SP3, под который я установил pervasive версии 9.52. И обнаруживаю через несколько дней работы удивительную вещь - ЧТО БЫ Я НИ ПИСАЛ в bti.cfg, сразу же после перезагрузки сервера (перезагружал три раза) модуль NWMKDE.NLM отжирает ~800 мегабайт памяти! Смотрю NRM-ом и SEG.NLM - результаты совпадают. На сервере памяти 4Гига, вот мой bti.cfg:

[MicroKernel]
MaxFiles=500
MaxCursors=25000
BalancedTrees=NO
ForceFileVersion=0700
SystemData=YES
MaxDatabases=10
Logging=NO
CacheSize=262144
CompressedBufferSize=5
ExtendedBufferSize=64
MergeSortBufferSize=0
MaxRecSize=63
CachePartitioning=YES
TransDurability=YES
TransLogBufferSize=1024
TransLogFileSize=1024
SysTransBundleLimit=65535
SysTransTimeLimit=10000
MaxClients=50
BackgroundThreads=50
WaitLockTimeout=50
TransLogDirectory=SYS:/SYSTEM/MKDE/LOG
WorkDirectory=
Trace=NO
TraceFile=SYS:/SYSTEM\MKDE.TRA
TraceDataBufferLength=256
TraceKeyBufferLength=256
TraceOpsList=ALL
LoadRouter=NO
RouterCommBufferSize=16
RuntimeServerSupportMode=0000
MaxCacheUsage=10
TransLogging=YES
Validate Request=NO
Max Pending IO=1024
File Growth Factor=15
Page Server Allow Client Cache=YES
Prompt For Client Credentials=NO
Allow Client-Stored Credentials=YES
Use FileIO Mutex=NO

Ключевые параметры выделены цветом, судя по ним максимум, что может отожрать NWMKDE.NLM - это 10% от общей памяти (сразу резервируется 256 мбайт), т.е., не более 400 мегабайт, а он зараза, отъедает в два раза больше! Что за на фиг? Они там единицы измерения случайно не поменяли? А то я думаю, что пишу 256 мбайт, а там - гигабайты .

PCC У текущей версии PSQL сохраняет кинфиг в SYS:\ETC\psrgstry.ini (текстовый слава богу).

Boris Morozov писал(а):Это надо не в BTI.CFG смотреть, а через PCC. А в процентах задается кеш второго уровня . Так что может и не жрет ничего, а считает что так и надо. 256+400+еще чего где-то близко к 800 будет.

Насколько я понял из документации, первый параметр - CacheSize - это стартовый минимум, который pervasive забирает под кеш, а второй параметр - MaxCacheUsage - это процент от общей памяти, до которого кешу разрешено расти, т.е. в моём случае максимум должен быть не больше 10% от 4Гиг, т.е., ~400Мбайт.

Boris Morozov писал(а):Хотя я не уверен, что они в 9.52 в BTI.CFG параметры хранят.

Точно, не там хранят. А я тут сервер перегружать устал после после очередной правки bti.cfg

Boris Morozov писал(а):Я вот посмотрел сейчас, на серваке с 768MB занято типа 39МВ.

"Хорошо тебе" (c)

Dimerson писал(а):PCC У текущей версии PSQL сохраняет кинфиг в SYS:\ETC\psrgstry.ini (текстовый слава богу).

Точно! Там и нашёл вот это:

Cache Size=759908

Руками-то можно, надеюсь, этот параметр поправить? А то я что-то у себя PCC завести не могу - куда, кстати, эта програмуля ставится?

Да, сильно я от жизни с первасивом отстал, всю дорогу считал, что они в bti.cfg параметры держат, да и все ссылки - у CA, у Novell-а - на этот файлик указывали.

Спасибо!

UPD: плохо я искал: NWMKDE uses a large amount of memory after upgrading Pervasive SQL (btrieve)

Сергей Дубров писал(а):

Dimerson писал(а):PCC У текущей версии PSQL сохраняет кинфиг в SYS:\ETC\psrgstry.ini (текстовый слава богу).

Точно! Там и нашёл вот это:

Cache Size=759908

Руками-то можно, надеюсь, этот параметр поправить? А то я что-то у себя PCC завести не могу - куда, кстати, эта програмуля ставится?

Да, сильно я от жизни с первасивом отстал, всю дорогу считал, что они в bti.cfg параметры держат, да и все ссылки - у CA, у Novell-а - на этот файлик указывали.

Спасибо!

UPD: плохо я искал: NWMKDE uses a large amount of memory after upgrading Pervasive SQL (btrieve)

1.PCC это часть Клиента PREVASIVE SQL. Ставите клиента получете PCC.

2. AS 11.1SP2, да и SP3 если честно, дурак - ищет сведения о памяти в bti.cfg хотя они уже в
psrgstry.ini . Пришлось ему создать фейковый bti.cfg и он успокоился.
На предмет вправления ему мозгов есть Хот Фикс QO87892 для NW-BAB R11.1 SP3 содержащий PFC.NLM & MSG (модуль для Pre-Flight Check при старте AS). А Large Amount это да - у меня нормально заработало восстановление ( именно хождение по сессиям итд ) при выделении 25% озу (всего 1 GB было) .

Dimerson писал(а):1.PCC это часть Клиента PREVASIVE SQL. Ставите клиента получете PCC.

Понял. Вспомнил, что когда-то с sql2000 так и делал, просто забыть успел за давностью. Ладно, без PCC обойдусь, руками поправлю в ini-файле то, что надо.

Dimerson писал(а):2. AS 11.1SP2, да и SP3 если честно, дурак - ищет сведения о памяти в bti.cfg хотя они уже в
psrgstry.ini . Пришлось ему создать фейковый bti.cfg и он успокоился.

Во-во, я и думал, что коль скоро BAB читает bti.cfg, то он знает, что делает и тоже считал, что pervasive v9 оттуда же настройки берёт.

Dimerson писал(а):На предмет вправления ему мозгов есть Хот Фикс QO87892 для NW-BAB R11.1 SP3 содержащий PFC.NLM & MSG (модуль для Pre-Flight Check при старте AS).

Этот патч у меня стоИт уже давно, я как раз его ставил, когда достали вопли про 20% при загрузке.

Dimerson писал(а):А Large Amount это да - у меня нормально заработало восстановление ( именно хождение по сессиям итд ) при выделении 25% озу (всего 1 GB было) .

Я сейчас поставил Cache Size=262144, а Max MicroKernel Memory Usage=60 не стал пока трогать (это 60%) - понаблюдаю за сервером (только перегрузить его надо будет не забыть на выходные).

Я ведь с чего кинулся память проверять - в NRM увидел жёлтенький светофор напротив "Available Logical Space" - и обнаружил, что NWMKDE.NLM 800 метров памяти отъел.

==== OFF on ====
UPD ??
==== OFF off ====

"Течёт" память у NWMKDE.NLM v9.52 - выставил ему Cache Size=262144 в SYS:\ETC\psrgstry.ini. Перегрузился, смотрю память (NRM-ом и SEG.NLM) - вижу ~267 MB. Нормально. Дело было в выходные. В понедельник смотрю - а NWMKDE.NLM "весит" уже больше 300 MB, но при этом ни одного бэкапа после перезагрузки ещё НЕ БЫЛО! Т.е., первасив не работал, но память отъел. Ладно, жду понедельничный бэкап, смотрю после него - а NWMKDE.NLM распух уже до ~360 MB! Это что такое с ним творится-то? За три дня - 100 мегабайт скушал?!

Сейчас с утра опять перегрузил сервер (вдруг перестал пускать NRM, говорит, имя или пароль плохие, хотя обычным логином пускал без проблем - перезагрузка помогла. Чудеса, блин). Зафиксировал размер NWMKDE.NLM - те самые ~267 MB, понаблюдаю. Но явно память у NWMKDE.NLM "течёт".

Сергей Дубров писал(а):"Течёт" память у NWMKDE.NLM v9.52 - выставил ему Cache Size=262144 в SYS:\ETC\psrgstry.ini. Перегрузился, смотрю память (NRM-ом и SEG.NLM) - вижу ~267 MB. Нормально. Дело было в выходные. В понедельник смотрю - а NWMKDE.NLM "весит" уже больше 300 MB, но при этом ни одного бэкапа после перезагрузки ещё НЕ БЫЛО! Т.е., первасив не работал, но память отъел. Ладно, жду понедельничный бэкап, смотрю после него - а NWMKDE.NLM распух уже до ~360 MB! Это что такое с ним творится-то? За три дня - 100 мегабайт скушал?!

Сейчас с утра опять перегрузил сервер (вдруг перестал пускать NRM, говорит, имя или пароль плохие, хотя обычным логином пускал без проблем - перезагрузка помогла. Чудеса, блин). Зафиксировал размер NWMKDE.NLM - те самые ~267 MB, понаблюдаю. Но явно память у NWMKDE.NLM "течёт".

Врать не буду - не уверен на 100% но если бы текло то я бы заметил - есть в работе и 9.50 и 9.52

Dimerson писал(а):

Сергей Дубров писал(а):Но явно память у NWMKDE.NLM "течёт".

Врать не буду - не уверен на 100% но если бы текло то я бы заметил - есть в работе и 9.50 и 9.52

Всё-таки "течёт" память у модуля NWMKDE.NLM v9.52 - выставил ему размер 512Мбайт в SYS:\ETC\psrgstry.ini, перезагрузил сервер, проверил - всё нормально, скушано ~полгига. А после недели работы занятый объём увеличился до ~700Мбайт.

Сергей Дубров писал(а):

Dimerson писал(а):

Сергей Дубров писал(а):Но явно память у NWMKDE.NLM "течёт".

Врать не буду - не уверен на 100% но если бы текло то я бы заметил - есть в работе и 9.50 и 9.52

Всё-таки "течёт" память у модуля NWMKDE.NLM v9.52 - выставил ему размер 512Мбайт в SYS:\ETC\psrgstry.ini, перезагрузил сервер, проверил - всё нормально, скушано ~полгига. А после недели работы занятый объём увеличился до ~700Мбайт.

Уже больше 900 метров занимает (937,750,455 байт по NRM).

Сергей Дубров писал(а):

Сергей Дубров писал(а):

Dimerson писал(а):

Сергей Дубров писал(а):Но явно память у NWMKDE.NLM "течёт".

Врать не буду - не уверен на 100% но если бы текло то я бы заметил - есть в работе и 9.50 и 9.52

Всё-таки "течёт" память у модуля NWMKDE.NLM v9.52 - выставил ему размер 512Мбайт в SYS:\ETC\psrgstry.ini, перезагрузил сервер, проверил - всё нормально, скушано ~полгига. А после недели работы занятый объём увеличился до ~700Мбайт.

Уже больше 900 метров занимает (937,750,455 байт по NRM).

Поглядел ... есть место где 6.5 SP6 + PSQL 9.52 с ноября в аптайме = как был в пределах 500мб так и остался . (там 2 гига озу)

UPD. Моск родил идею (бредовую) - у меня везде IP ONLY (в тч нет SERVERID) ... может они с IPX уже не тестируют и у вас он влияет как-то ?

Dimerson писал(а):

Сергей Дубров писал(а):

Сергей Дубров писал(а):

Dimerson писал(а):

Сергей Дубров писал(а):Но явно память у NWMKDE.NLM "течёт".

Врать не буду - не уверен на 100% но если бы текло то я бы заметил - есть в работе и 9.50 и 9.52

Всё-таки "течёт" память у модуля NWMKDE.NLM v9.52 - выставил ему размер 512Мбайт в SYS:\ETC\psrgstry.ini, перезагрузил сервер, проверил - всё нормально, скушано ~полгига. А после недели работы занятый объём увеличился до ~700Мбайт.

Уже больше 900 метров занимает (937,750,455 байт по NRM).

Поглядел ... есть место где 6.5 SP6 + PSQL 9.52 с ноября в аптайме = как был в пределах 500мб так и остался . (там 2 гига озу)

UPD. Моск родил идею (бредовую) - у меня везде IP ONLY (в тч нет SERVERID) ... может они с IPX уже не тестируют и у вас он влияет как-то ?

В теории у NWMKDE.NLM ещё есть куда расти - параметр MaxCacheUsage выставлен в 60% . Сейчас глянул на другом сервере (там NWMKDE.NLM v9.10, сервер NW5.1, IP+IPX) - при выставленной изначально цифре CacheSize=~418Мбайт (при ОЗУ - 2Гб) сейчас там NWMKDE.NLM съел порядка 645Мбайт (работает с 3-го января). Причём на NW5.1 типичный аптайм - год (без трёх дней ) - то ли "распухание" со временем прекращается, то ли NWMKDE.NLM 9.10 по-другому себя ведёт, то ли 5.1 vs 6.5 по-разному с памятью обходятся.

В общем, понаблюдаю ещё...

Сергей Дубров писал(а):

Dimerson писал(а):

Сергей Дубров писал(а):

Сергей Дубров писал(а):

Dimerson писал(а):

Сергей Дубров писал(а):Но явно память у NWMKDE.NLM "течёт".

Врать не буду - не уверен на 100% но если бы текло то я бы заметил - есть в работе и 9.50 и 9.52

Всё-таки "течёт" память у модуля NWMKDE.NLM v9.52 - выставил ему размер 512Мбайт в SYS:\ETC\psrgstry.ini, перезагрузил сервер, проверил - всё нормально, скушано ~полгига. А после недели работы занятый объём увеличился до ~700Мбайт.

Уже больше 900 метров занимает (937,750,455 байт по NRM).

Поглядел ... есть место где 6.5 SP6 + PSQL 9.52 с ноября в аптайме = как был в пределах 500мб так и остался . (там 2 гига озу)

UPD. Моск родил идею (бредовую) - у меня везде IP ONLY (в тч нет SERVERID) ... может они с IPX уже не тестируют и у вас он влияет как-то ?

В теории у NWMKDE.NLM ещё есть куда расти - параметр MaxCacheUsage выставлен в 60% . Сейчас глянул на другом сервере (там NWMKDE.NLM v9.10, сервер NW5.1, IP+IPX) - при выставленной изначально цифре CacheSize=~418Мбайт (при ОЗУ - 2Гб) сейчас там NWMKDE.NLM съел порядка 645Мбайт (работает с 3-го января). Причём на NW5.1 типичный аптайм - год (без трёх дней ) - то ли "распухание" со временем прекращается, то ли NWMKDE.NLM 9.10 по-другому себя ведёт, то ли 5.1 vs 6.5 по-разному с памятью обходятся.

В общем, понаблюдаю ещё...

Вчера, сразу после окончания полного бэкапа (когда BAB уже записал данные в базу), NWMKDE.NLM дорос до ~953Мбайт. Смотрю сегодня утром - уже 1,038,602,167 байт!

Попробую сделать две вещи:

1. Поставлю в SYS:\ETC\psrgstry.ini:
Cache Size=524288
Max MicroKernel Memory Usage=20 (вместо умолчательного значения 60%).

2. Вместо NWMKDE.NLM v9.52 загружу NWMKDE.NLM v9.10 (на 5.1 с ней никаких проблем (IP+IPX) - память не "распухает").

Удивляет момент, что NWMKDE.NLM раздувается не в момент работы BAB-а (который, собственно, единственный, кто пользуется первасивом), а спустя некоторое время, как было вчера/сегодня - в районе 23:45 (бэкап уже закончился) - 935Мбайт, на следующее утро, в районе 9:45 - уже больше гигабайта.

Хотя... соврал я, что не работает - у меня ежедневно на 8:00 назначен prune/purge базы. Но, с другой стороны, этот сервер начал работать только с 7-го января этого года, база ещё маленькая, никаких purge (360 дней) и prune (180 дней) просто не должно быть - нечего там ещё пуржить/прунить. Непонятно...

Ладно, буду пробовать версию NWMKDE.NLM v9.10, если 9.52 и дальше расти будет.

UPD: Заметил одно различие в конфигурациях Database Engine на беспроблемной и проблемной конфигурациях: там, где NWMKDE.NLM не "распухает", галочка "Merge detail files while jobs are active" снята, а там, где есть проблема - установлена. Сейчас на "пухнущей" конфигурации галочку снял, рестартанул BAB, буду дальше наблюдать.

UPD2: Наткнулся на интересное обсуждение:
The memory handling with SP6 is much better than with SP5, so there were a lot of changes in there. The usual problem is when As tries to merge the log files into the database, then Btrieve gets a bit over excited, grabs the memory, and with SP5, the system didn't seem to get it back, hence the falling cache buffers and stalling backup jobs.

Короче, намекается, что надо с SP5 уходить.

Сергей Дубров писал(а):

Сергей Дубров писал(а):

Dimerson писал(а):

Сергей Дубров писал(а):

Сергей Дубров писал(а):

Dimerson писал(а):

Сергей Дубров писал(а):Но явно память у NWMKDE.NLM "течёт".

Врать не буду - не уверен на 100% но если бы текло то я бы заметил - есть в работе и 9.50 и 9.52

Всё-таки "течёт" память у модуля NWMKDE.NLM v9.52 - выставил ему размер 512Мбайт в SYS:\ETC\psrgstry.ini, перезагрузил сервер, проверил - всё нормально, скушано ~полгига. А после недели работы занятый объём увеличился до ~700Мбайт.

Уже больше 900 метров занимает (937,750,455 байт по NRM).

Поглядел ... есть место где 6.5 SP6 + PSQL 9.52 с ноября в аптайме = как был в пределах 500мб так и остался . (там 2 гига озу)

UPD. Моск родил идею (бредовую) - у меня везде IP ONLY (в тч нет SERVERID) ... может они с IPX уже не тестируют и у вас он влияет как-то ?

В теории у NWMKDE.NLM ещё есть куда расти - параметр MaxCacheUsage выставлен в 60% . Сейчас глянул на другом сервере (там NWMKDE.NLM v9.10, сервер NW5.1, IP+IPX) - при выставленной изначально цифре CacheSize=~418Мбайт (при ОЗУ - 2Гб) сейчас там NWMKDE.NLM съел порядка 645Мбайт (работает с 3-го января). Причём на NW5.1 типичный аптайм - год (без трёх дней ) - то ли "распухание" со временем прекращается, то ли NWMKDE.NLM 9.10 по-другому себя ведёт, то ли 5.1 vs 6.5 по-разному с памятью обходятся.

В общем, понаблюдаю ещё...

Вчера, сразу после окончания полного бэкапа (когда BAB уже записал данные в базу), NWMKDE.NLM дорос до ~953Мбайт. Смотрю сегодня утром - уже 1,038,602,167 байт!

Попробую сделать две вещи:

1. Поставлю в SYS:\ETC\psrgstry.ini:
Cache Size=524288
Max MicroKernel Memory Usage=20 (вместо умолчательного значения 60%).

2. Вместо NWMKDE.NLM v9.52 загружу NWMKDE.NLM v9.10 (на 5.1 с ней никаких проблем (IP+IPX) - память не "распухает").

Удивляет момент, что NWMKDE.NLM раздувается не в момент работы BAB-а (который, собственно, единственный, кто пользуется первасивом), а спустя некоторое время, как было вчера/сегодня - в районе 23:45 (бэкап уже закончился) - 935Мбайт, на следующее утро, в районе 9:45 - уже больше гигабайта.

Хотя... соврал я, что не работает - у меня ежедневно на 8:00 назначен prune/purge базы. Но, с другой стороны, этот сервер начал работать только с 7-го января этого года, база ещё маленькая, никаких purge (360 дней) и prune (180 дней) просто не должно быть - нечего там ещё пуржить/прунить. Непонятно...

Ладно, буду пробовать версию NWMKDE.NLM v9.10, если 9.52 и дальше расти будет.

UPD: Заметил одно различие в конфигурациях Database Engine на беспроблемной и проблемной конфигурациях: там, где NWMKDE.NLM не "распухает", галочка "Merge detail files while jobs are active" снята, а там, где есть проблема - установлена. Сейчас на "пухнущей" конфигурации галочку снял, рестартанул BAB, буду дальше наблюдать.

UPD2: Наткнулся на интересное обсуждение:
The memory handling with SP6 is much better than with SP5, so there were a lot of changes in there. The usual problem is when As tries to merge the log files into the database, then Btrieve gets a bit over excited, grabs the memory, and with SP5, the system didn't seem to get it back, hence the falling cache buffers and stalling backup jobs.

Короче, намекается, что надо с SP5 уходить.

Думаю что это слабо сказано.
Надо уходить на OES2/Linux ;o)
P.S. GW8 под NetWare не будет ...