[quot genix то что cpu = 1, хотя машина 2х процессорная. Корректно ли это с точки зрения оптимизации работы informix'а?[/quot]
Просто такой параметр задан у тебя в конфигурационном файле onconfig.
Это значит, что есть только один виртуальный процессор, отвечающий за обработку запросов, а это, в свою очередь, говорит о том, что длительное выполнение какого либо процесса (DSS), связанное с процессорным временем (сортировка, например, или формирование отчета), будет тормозить выполнение всей очереди коротких OLTP-запросов, стоящих на обслуживание.
Если сервер на самом деле 2-х процессорный (а не HiperThreding), то можно установить параметры (все три взаимосвязаны).
MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor
NUMCPUVPS 2 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one

И еще меня смущают следующие цифры
Virtual processor summary:
class vps usercpu syscpu total
cpu 1 344444.70 4371.33 348816.03

Это за какой же период собрана статистика ?
И уж больно большое соотношение usercpu к syscpu.
Или ввода/вівода очень мало или ...что то тут не так :)

genix vasilisИ еще меня смущают следующие цифры
Virtual processor summary:
class vps usercpu syscpu total
cpu 1 344444.70 4371.33 348816.03

Это за какой же период собрана статистика ?
И уж больно большое соотношение usercpu к syscpu.
Или ввода/вівода очень мало или ...что то тут не так :)

если под периодом понимается uptime который можно посмотреть по onstat, то речь идет всего лишь о 110 днях
Нет, речь идет о времени, за которое собиралась статистика (она может обнуляться по onstat -z).
выполни лучше запрос по анализу загрузки проца. Только сначала обнули статистику, дай активно поработать серверу с час и покажи результат
-------------------------------------------------
-- Processor and main activity (CPU profile)
-- (whole instance)
--
-- V.Shulzhenko DBA_Tools 2004-05
-------------------------------------------------
set isolation to dirty read;
select
'===== CPU Profile ====' ______________
,DBINFO('dbhostname') hostname
,DBINFO('utc_to_datetime',sh_boottime) boot_time
,current year to second -
EXTEND(dbinfo('utc_to_datetime',sh_boottime),year to second) _running_time
,DBINFO('utc_to_datetime',sh_pfclrtime) zero_profile_time
,current year to second -
EXTEND(dbinfo('utc_to_datetime',sh_pfclrtime),year to second) statistic_time
,'-------------------------------' ______________
,'--Onconfig Effective--' __________
,(select cf_effective from sysconfig where cf_name='NUMCPUVPS') num_cpuvps
,(select cf_effective from sysconfig where cf_name='MULTIPROCESSOR') multiprocessor
,'-------------------------------' ______________
,'-- Stamp activity from boot --' __________
,sh_bootstamp boot_stamp
,sh_stamp current_stamp
,sh_stamp-sh_bootstamp _stamp_update
,round((sh_stamp-sh_bootstamp)/(sh_curtime-sh_boottime),4) _activity_psec
,'-- Processor Stat Time --' __________
,(select round(sum(usercpu),2) from sysvpprof) usercpu_time
,(select round(sum(syscpu),2) from sysvpprof) syscpu_time
,(select round(sum(usercpu+syscpu),2) from sysvpprof) _all_cpu_time
,(select round(sum(usercpu)/sum(usercpu+syscpu)*100,2) from sysvpprof) _user2sys_ratio
,round((select sum(usercpu+syscpu) from sysvpprof)/
(sh_curtime-sh_pfclrtime)*100,2) _IDS_cputime_ratio
,'-------------------------------' ______________
from sysshmvals;

К сожалению, концовку вывода запроса ты обрезал. тас как раз и хотел посмотреть загрузку процессоров.
Но раз помогло. то уже хорошо.
На будущее, можно указать в onconfig даже три или четыре CPU VP на двух физических процессорах, чтобы избежать торможений длительными процессами очереди коротких запросов. Общая эффективность работы сервера может быть немножко хуже (будет больше времени тратиться на переключение между VP и согласование работы), но эффективность обработки запросов улучшиться.

genix
А как лучше быть на 2-х процессорах с HT (Intel Xeon)? Указывать 2 (физических) или 4 (с учетом HT) процессора? Система (linux) видит в общей сложности 4 процессора.
Да можно хоть 8. Я как то видел установленное количество в 20 CPU VP на два проца - и ничего, система жила нормально :)
Основной смысл в том, что CPU VP обслуживает больше 90% всей работы, необходимой для выполнения запросов, соответственно, именно он и потребляет основное процессорное время. Если запросы в чистом виде OLTP-шные (т.е. короткие по времени, без сканирования таблиц и процессорных вычислений), то и одного CPU VP вполне достаточно даже для двухпроцессорного хоста. При бОльшем кол-ве виртуальных процессоров им уже необходимо взаимодействовать между собой, переключать контексты, садиться на разные физические процессоры и т.п. Т.е. общая эффективность обработки может падать (больший процент процессорного времени будет уходить на служебную работу). Многочисленные рекомендации от производителя всегда рекомендовали делать кол-во CPU VP меньшим на единицу от кол-ва физических процов. Так говорит теория. Но практика показывает, что чистых OLTP запросов мало и тогда длинный запрос начинает тормозить всех. К тому же, рекомендации ранее расчитывались исходя из менее мощных процессоров, чем сейчас, да еще , как обычно, по хорошему принципу "не навредить". Современные интеловские процы достаточно мощные, чтобы тянуть 2 или 3 CPU VP каждый, хотя , конечно, многое зависит от крутости самих запросов. Тем не менее, для средней интеловской системы, как я уже ранее и говорил. я рекомендую по 2 CPU VP на каждый физический проц. HT, конечно, крутая маркетинговая штука, но для обработки ОДНОТИПНЫХ запросов она мало подходит, IMHO.