GByteСмотрел release notes.

У нас стоит IDS 7.31.UD5.
Для него release notes вообще близко нет.. ну посмотрел другие. Обратил внимание на отличие - в доке написано SHMBASE=0x82000000L, у нас в onconfig SHMBASE= 0xa000000

Никто не может сказать с уверенностью >50% какой правильнее? :)


Это один из основных параметров, тюнинг которого позволит
увеличить обьем используемой памяти процессом.
Я когдато давно еще на SCO Unix пробовал высчитывать, геморойное это дело.
Правильное из них любое рекомендованное IBM ,
только максимальный обьем памяти, которую можно отдать серверу
при разных параметрах будет разный.
2-й Ход по увеличению используемой памяти это перемещать адреса загрузки разделяемых библиотек.

При правильном подходе для конкретного сочетания ( верисия OS, libc, версия информикс), все это будет работать стабильно, но при изменении чего либо из вышеперечисленного нужно будет и параметры менять.


GByte
Еще вопрос: После наращивания ОЗУ с 4Гб до 8Гб в выводе onstat -p значение usercpu стало значительно меньше syscpu.

О чем это может говорить?

# onstat -p

Informix Dynamic Server Version 7.31.UD5 -- On-Line -- Up 19:48:40 -- 2912520 Kbytes

Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
58014385 1281674292 807968525 92.82 8772258 29951507 141986698 93.82

isamtot open start read write rewrite delete commit rollbk
1872860077 4472786 58727336 1619273289 63708983 175298 58690 30 0

gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0

ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 20853.99 74546.13 175 472

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
2579090 0 488044113 0 0 239 165404 1471310

ixda-RA idx-RA da-RA RA-pgsused lchwaits
6419334 262503 1212790 7879072 8804162


Это может говорить о том что в системе используется двойная буферизация.
Вы файлы используете или raw?

GByteИспользуем RAW.

Но как может отразится двойная буферизация на usercpu и syscpu?

Причем когда мы увеличили ОЗУ сервера с 4Гб до 8Гб и утилита sar стала говорить о сильно возросшем времени на системные события?


покажите ls -al ваших девайсов & onstat -d

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

Покажите sar -Bb там должны быть нули если в системе нет нагрузки на кеш,
если Вы правльно используете raw, то операции ВВ идут мимо кеша ФС.

Подозреваю IMHO , что весь возросший syscpu сидит в колонке fault/s из sar -B,
Если ничего другого(кроме увеличения памяти) в системе не изменялось.

GByteвывод sar -b, onstat -d, ls -la /dev/rdsk.


Для полной ясности хорошо бы увидеть все в комплексе
sar -ubgpd 1 30

Какие еще приложения кроме БД активно работают с файлами на сервере?

Рекомендую почитать
Virtual memory (VM) parameters для Unixware , думаю тюнинг этих параметров для Вашей системы позволить
уменьшить syscpu.