sysmasterInformix 32-битный или 64-битный.
Когда поcледний раз выполнялся UPDATE STATISTICS?

UPDATE STATISTICS выполняется еженощно.

А вот как узнать насчет 32 или 64 бит незнаю... не подскажете?

Журавлев Денис ПинеуЕсть огромные проблемы с качеством кода у наших программеров, но заставить их не могу, и меня заставляют выжимать из сервера последнее.будь вы хоть самым лучшим на планете информикс дба >10% вам не выжать, а программист добавив кавычки в запрос легко и непринужденно может выжать 10000%.


Я енто понимаю.. по тому и говорю, что заставить начальство "дать задание" программерам не могу - тут уже политика...

AndronПоскольку у вас 32bit информикс то использовать 8 Gb памяти не удастся, только если переходить на 64bit, но это еще должна поддерживать и сама ОС.
Далее, если у вас нет проблем с дисками, то наиболее очевидный путь - обнаружить наиболее загруженные по I/O чанки (onstat -g iof) и сделать балансировку нагрузки на дисках (т.е. переложить чанки). Либо если все хозяйство равномерно разложено по дискам, настраивать сами диски, чтобы выжать из них побольше.
А есть ли на сервере другие приложения кроме информикса, может они тоже создают ощутимую нагрузку?
SHMADD = 32Кб, вы не ошиблись?
Использование следующих советов потребует чтения документации и знания информикса.
Мониторить использование таблиц (onstat -g ppf, предварительно должен быть включен параметр TBLSPACE_STATS 1). В этом случае наличие у немаленьких таблиц seqscan значительно большее 0 должно обращать на себя внимание, значит запросы сканируют такие таблицы, исправлять запросы, возможно создавать правильные индексы.
Также посмотреть значение lkwts - ожидание другими сессиями блокировок, можеть быть некоторые таблицы должны иметь уровень блокирования на запись а не страницу (особенно осторожно применять для больших таблиц!)
Фрагментировать наиболее загруженные таблицы если возможно.
Жаль что у вас не 10 информикс - все очень большие таблицы можно было бы отправить в отдельный буферный пул, чтобы не было конкуренции с остальными таблами за буфера.
Вообще мониторинг информикса в таких случаях может дать немало. Есть ли у вас система мониторинга? Только имея некие накопленные статистические данные можно на их основании настроить на макс. производительность сервер и приложения.
Вообще всего не перечислишь, читайте документацию.

1. 32бит информикс на данной конфигурации сервера имеет все шансы использовать столько озу сколько сможет взять. мне как раз нужна помощь в настройке его на максимум доступной ему озу, пусть не 8Гб, а 4Гб но это по любому увеличит производительность, тем более ОС теперь тоже имеет больше озу.

2. Вся бд лежит на диске презентованном по SAN с HP EVA4000. - она сама распределяет инфу равномерно по дискам, диски в ней тоже FiberChannel.

3. Информикс крутится для ERP-системы. эта ERP реализована на юниксовых сессиях - клиенты по телнету коннектятся и работают. загрузку ощутимую она не создает.

4. SHMADD = 32Кб, вы не ошиблись? - onconfig прикладуываю здесь. в ходе работы информикс говорит что добавляет по 32Кб памяти.

5. статистику сейчас веду - скрипт ежедневно в файл записывает вывод onstat -a. как вернусь из командировки выложу его.

6. Доку читаю, но часто и советы нужны - для уверенного движения вперед ;) так что буду еще спрашивать :)

еще раз повторю, что в приложении onstat

Выкладываю статистику.

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

В файле почти весь onstat -a.

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

период - 1 рабочий день. У нас еженощно сервер перегружается по расписанию.

дисковый массив подключен по оптике на скорости 2ГБит/сек

Журавлев Денис AndronДисковый кэш еще и другие процессы требуют, а тут память которая только темпу информикса, мне кажется стоит попробовать.Так это гадание все, может темп у них вообще не используется. Я сейчас 80 страниц напишу чего еще можно попробовать. У них %rcached 95.81 и commit 163 за целый день, вообще какой-то бред.

163 транзакции за день это еще оч много! - у нас программеры не пользуются этим!.... :((

Daugava 6 /dev/rdsk/slice3 1964461 1239053 725408 29.4
7 /dev/rdsk/slice3 1907332 1179001 728331 28.5
Чемпионы по записи - tmp дспейсы, которые находятся на одном диске. Разнести обязательно, более того имеет смысл добавить еще. Ну и в память запихнуть, должно помочь. По чтению есть другие чемпионы, тут видимо можно поиграться с фрагментацией таблиц, дабы распределить нагрузку по дискам.

Кстати, а как у данной версии с KAIO ? Тоже може кое-что выжать.

там без разницы что на одном слайсе. слайсы на HP MSA1000 - она сама размазывает данные по физическим дискам. скоро все данные перенесу на HP EVA4000. как думаете сильно производительность добавит?

Насчет ram-диска в данном случае может и правда поможет.. попробую в ближайшее время.

что с KAIO не знаю.. буду искать.

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

да, она сама все раскидывает. но дисками управлять можно - можно явно указать на каких дисках строить дисковую группу, а там уже и логический диск создается, вот его распределением по группе дисков управлять нельзя.

DaugavaКак-то 600 дисков и 60Гб базы не вяжутся. Более того, не 60, а где-то 58 или даже вообще 52 :) Видимо на этих же FC весилится и ликует не один десяток серверов. Может проблемы с производительностью от них ползут?
Вообще читаю и радуюсь, что не взял HP. IBM все таки значительно гибче в плане настройки.

Совершенно верно - и на MSA1000 и на EVA4000 у нас не один сервер сидит..

смотрели загрузке FC-Switch по портам, она по все портам выше 1-10% не поднимается. только если физические диски загружены..

на MSA1000 SCSI-диски, на EVA4000 FC-диски. надеемся что с переходом на них производительность тоже возрастет.

Алексан GByteВыкладываю статистику...
Мне кажется - по данной статистике - что система используется, в основном, для отчётов, что эти отчёты интенсивно используют временные таблицы, и что системе не хватает памяти. Памяти Информиксу не хватает, потому что некоторые большие таблицы часто последовательно сканируются и, вследствие этого, целиком лежат в памяти (особенно выделяются таблицы 0х600050, 0х6000fc, 0х600165, 0х60020b, 0х60044d, 0х60054d). Как следствие, сколько бы Вы памяти Информиксу не скормили, её всё равно не хватит, пока эти таблицы не будут адекватно проиндексированы (либо отчётам действительно нужны все данные из этих таблиц, и тогда стоит сменить систему или ожидания пользователей :-))
По поводу временных таблиц: если они большие, то их тоже стоит индексировать и, после этого, обновлять на них статистику.

Ещё я бы увеличил размер буфера физического журнала (PHYSBUFF), пока его использование не приблизится к 75% (см. отношение pages/io к bufsize в выходе onstat -l). Возможно, на некоторых отчётах поможет повысить производительность увеличение числа виртуальных процессоров AIO (NUMAIOVPS, кажется). Если возможно, используйте KAIO.

Данная статистика снята как раз в отчетный период, когда системы загружена на 1000% как раз отчетами.
А в течение месяца в БД заносятся данные.

АнатоЛойА если всё-таки OnManager'ом поймать парочку любителей больших nreads, onstat -g sql xyz,
и пойманный запросик с соответствующими структурками разобрать по полочкам? :)

П.С.: Я не навязчивый - это у меня мысль навязчивая :)

Да я с удовольствием! :)
только вот не разумею..

если не трудно, в кратце по пунктам по подробнее подскажи ;)

Спасибо!

Завтра наклепаю скриптик для мониторинга.

Буду потом анализировать. как раз отчетный период пошел..

Тема не закрывается - буду еще у Вас спрашивать!

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

Ранее в этой ветке "прозвучало" что у 32-бит Информикса максимум оперативной памяти может быть использовано не более 2.9 Гб.

Погуглил основательно, но нигде ссылку на официальную доку с такой цифрой найти не могу, а начальство требует или цифру или зацепить к СУБД 16Гб ОЗУ...

Кто знает где можно найти эту цифру, подскажите, плиз :)

Луну пока не просили)))

в моих двух Informix 7.3 нет нипапки ни файла...

буду искать дальше..

кто знает где еще посмотреть - подскажите, буду признателен!

Огромадное СПАСИБО!

Правда искал много, но часто крупные брэнды как-то по особому у себя инфу располагают :)
или я уже сильно туплю...

Да-да XD

Смотрел release notes.

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

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

Еще вопрос: После наращивания ОЗУ с 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.

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

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

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

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

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


Приложений больше никаких нет.

Это сервер под Informix и ERP-систему MAX, которая как раз Информикс и использует в качестве хранилища.

sar -ubgpd 1 30 в приложении.
выполнен был уже после окончания рабочего дня. завтра в 9 по москве повторю и выложу.

актуальный sar -ubgpd 1 30