Rumata Estorskiy
IBM Informix Dynamic Server Version 9.40.TC7 -- On-Line -- Up 01:47:39 -- 1334720 Kbytes
Windows 2000 Server
Реальной оперативки 4 Гига.
Дык никак я не разберусь с параметрами в онконфиге. При указанных ниже параметрах (взятых в общем-то с потолка) информикс отводит 1334720 Kb (Ну сами видите). Далее при интенсивной загрузке (около 130 юзеров) он начинает подгружать новые сегменты (Dynamically allocated new virtual shared memory segment (size 32768KB)). И так до около 2-х Гиг, а дальше начинает ругаться, что памяти ему мало.

20:05:07 shmat: [ENOMEM][12]: out of available data space, check system memory parameters (e.g. MAXMEM).

20:05:07 out of virtual shared memory

20:05:08 Assert Failed: Condition Failed (Ignoring free of pool 'arc_21062' (0x2811020) in use by blkpool), In (mt_shm_free_pool)
20:05:08 IBM Informix Dynamic Server Version 9.40.TC7
20:05:08 Who: Session(21062, work@microsoft.com, 1952, 00000000)
Thread(65565, ontape, 0, 1)
File: mtshpool.c Line: 3127
20:05:08 Action: Please notify IBM Informix Technical Support.
20:05:08 stack trace for pid 836 written to C:\Informix\tmp\af.4052554
20:05:08 See Also: C:\Informix\tmp\af.4052554, shmem.4052554.0
20:05:10 Releasing server from system block
20:10:37 Condition Failed (Ignoring free of pool 'arc_21062' (0x2811020) in use by blkpool), In (mt_shm_free_pool)
20:10:54 Checkpoint Completed: duration was 12 seconds.
20:10:54 Checkpoint loguniq 4967, logpos 0x49c018, timestamp: 0xf0debf6e

Перестарт информикса спасает дело. Всё опять возвращается на 1,3 Гига и пару недель память медленно растёт до 2Гиг и потом опять ругается.
Мне непонятно одно. У меня реально 4 Гига, а информикс выше 2-х Гиг брать не хочет. Что мне делать с параметрами, а то никак не могу в них разобраться?


ONCONFIG:
-----------
RESIDENT 1 # Forced residency flag (Yes = 1, No = 0)

LOCKS 100000 # Maximum number of locks
BUFFERS 200000 # Maximum number of shared buffers
NUMAIOVPS # Number of IO vps
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 32 # Logical log buffer size (Kbytes)
CLEANERS 2 # Number of buffer cleaner processes
SHMBASE 0xC000000L # Shared memory base address
SHMVIRTSIZE 500000 # initial virtual shared memory segment size
SHMADD 32768 # Size of new shared memory segments (Kbytes)
EXTSHMADD 32768 # Size of new extension shared memory segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
LRUS 8 # Number of LRU queues
LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit
TXTIMEOUT 300 # Transaction timeout (in sec)
STACKSIZE 64 # Stack size (Kbytes)


1. Ограничение в 2 ГБ адресного пространства есть ограничение
на разрадность signed long в 32 разрадной операционной системе.
Теоретически адресное пространство процесса можно увеличить до unsigned long (4 ГБ), погуглите на предмет "PAE" "windows" "infomrmix".
Я не знаю насколько informix дружит с PAE.


2. Вам может помочь переодический запуск onmode -F.
Более действенным будет если в момент вызова onmode -F
У вас не будут выполняться сессий которые используют сортировки больших обьемов или полные сканирования таблиц.

3. В случае если у Вас DSS,
посмотрите на вывод onstat -P, если индексных страниц в буферах базы данных меньше 30 % можете смело уменьшать параметер BUFFERS
и на этот обьем увеличить SHMVIRTSIZE.
Это оттянет появление эффекта без потери производительности, если правильно подобрать соотношение индексных и страниц с данными в буферах
базы данных.
Если же у Вас OLTP ищите запросы которые не попадают по индексам.


4. Попробуйте поставить pdqpriority в значение меньше 5 в плоть до 0.
Это тоже может помочь если у Вас большое количество фрагментов таблиц.
Зато может существенно снизить производительность.

Если все это не помогает, а ситуация сильно напрягает, ищите возможность переходя на 64 разрядную версию informix.

Rumata Estorskiy onstat-
1. Ограничение в 2 ГБ адресного пространства есть ограничение
на разрадность signed long в 32 разрадной операционной системе.
Теоретически адресное пространство процесса можно увеличить до unsigned long (4 ГБ), погуглите на предмет "PAE" "windows" "infomrmix".
Я не знаю насколько informix дружит с PAE.


Что такое PAE? То бишь получается, что стоит на серваке 2 Гига или 4 Гига памяти никаких различий? (учитывая то, что кроме информикса и винды на сервере больше ничего нету)?



Описание здесь. http://support.microsoft.com/kb/283037

Если связка ОС и Informix не дружит с PAE или AWE, то использавать память
в вашем случае будет некому кроме ОС для своих нужд.

Rumata Estorskiy
onstat-
3. В случае если у Вас DSS,
посмотрите на вывод onstat -P, если индексных страниц в буферах базы данных меньше 30 % можете смело уменьшать параметер BUFFERS
и на этот обьем увеличить SHMVIRTSIZE.
Это оттянет появление эффекта без потери производительности, если правильно подобрать соотношение индексных и страниц с данными в буферах
базы данных.
Если же у Вас OLTP ищите запросы которые не попадают по индексам.


Может это поможет?



Я просил onstat -P (Upper Case).
И не извесно в каком режиме работает база(OLTP, DSS).

Частично может помочь это

commit 6768
rollbk 1067

16 % не много ли откатов транзакций? Вы не задавались вопросом почему?

seqscans 928183

ixda-RA idx-RA da-RA RA-pgsused
1212829 31674 398916 1639193

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

Rumata Estorskiy onstat-
Я просил onstat -P (Upper Case).


По этой команде на пол метра вывод идёт. Вот начало:

17825818 2 1 1 0 0
17825838 2 1 1 0 0
17825839 3 3 0 0 0
17825850 1 0 0 1 0

Totals: 250000 112003 135628 2369 11406

Percentages:
Data 54.25
Btree 44.80
Other 0.95

onstat-
И не извесно в каком режиме работает база(OLTP, DSS).


И мне не известно.:(



А нам тем более.

Уменьшайте BUFFERS на 5 - 10 % и эту памаять отдавайте в SHMVIRTSIZE
Посмотрите документацию в каких единицах измеряются эти параметры!!!!
Если производительность не упадет, можете попробовать больше.
Это продлит uptime вашей системы.

Rumata Estorskiy
onstat-
Частично может помочь это
commit 6768
rollbk 1067


Это что?


Это часть результата вашего onstat -p,
и это значит что 16 % попыток пользователей не приводят к реальному изменению базы данных и ресурсы потраченные системой на эти действия
расходуются в пустую.
А в особо тяжких случаях( на DSS операциях)
в двойне(то есть до 32 %).

Как вариант это может быть причиной ваших проблем
когда сессия после отката транзакции не отпускает
ранее запрошенную память. Может это баг, а может и фича.
В любом случае после завершения этой сессии
память должна вернуться для использования другими сессиями.
А операционке все лишнее можно отдать через onmode -F.

Rumata Estorskiy
К сожалению это невозможно, т.к. программа не наша. А ковыряться в нескольких десятках баз, в каждой из которых несколько сотен таблиц - нереально.

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

vasilis Выбегалло
------
SHMBASE specifies the base address where shared memory is attached to the
memory space of a virtual processor. Do not change the value of SHMBASE.
------
Переводя на русский - это адрес в виртуальном пространстве процесса(ов) oninit, с которого начинается ихняя общая память. Никакого отношения к реальному физическому адресу, по которому будет выделена память, он не имеет.
Мне кажется, что ты немного неправ.
SHMBASE - это адрес в виртуальном пространстве ОС, а не процесса oninit.

Это адрес в виртуальном пространстве процесса.
1. При выделении разделяемой памяти( shmget) ее фактический адрес выделяется в виртуальном пространстве ОС, затем эта память подключается(shmat) к адресному пространству процесса по адресу SHMBASE.

2. Если бы это был адрес в пространстве ОС , то для каждого SERVERNUM нужно было бы указывать свой SHMBASE.