powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Informix [игнор отключен] [закрыт для гостей] / Переход с MS SQL на INFORMIX под HP-PA-RISC
33 сообщений из 33, показаны все 2 страниц
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32232416
Недавно заказчик захотел перейти с MS SQL 7.0 на Informix 9.30 под HP-UX на железе PA-RISC.
База объемом порядка 70 Гб (предполагаемый рост до 200Гб), многие таблицы имеют несколько сотен миллионов записей.
БД используется в 3-х уровневой архитектуре с сервером приложений.
На БД практически никакой логики нет (типа хранимых процедур, триггеров),
используются только ограничения по ссылочной целостности через внешние ключи.
Функционирование БД типично для OLTP систем.
Сейчас БД функционирует на железе Compaq (модель не помню, четырехпроцессорный Intel Xeon 650Мгц, 2Гб ОЗУ, Raid5) под Win2K.
Какой приблизительно конфигурации сервер HP-PA_RISC необходимо взять, что бы на нем Informix работал с близкой производительностью
к MS SQL 7.0 на указанном железе?
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32232712
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Бери четырех процессорный UNIX и не ошибешься.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32233052
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
и двух камней за глаза ...

под энтей четыре камня все равно только электричество жрали :-)
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32234897
Исходя из типичных задач составили тест, эмулирующий типичную нагрузку на СУБД в Системе
(похожа на нагрузку в типичных OLTP). Тест выполняет при заданном числе записей в таблицах комбинации
операции по вставке единичных и групповых записей, поиск еденичных записей и групп записей, обновление и удаление записей.
Создается несколько конкурирующих соединений, выполняющих запросы одновременно.
Использовалось следующее оборудование:

1) СУБД MS SQL (используется на текущий момент в составе Системы):
операционная система - Microsoft Windows 2000 Advance Server,
сервер СУБД - Microsoft SQL Server 7.0 Standart Edition

аппаратная платформа - HP PROLIANT ML370 G3, общей стоимостью около 8000$
2 x Intel Xeon Processor at 2.8Ghg,
1Gb RAM,
HP SCSI320 RAID CONTROLLER with 128Mb
2 x 18Gb 15k rpm, организованных в RAID 1 для установки системного ПО
3 x 36Gb 10k rpm, организованных в RAID 5 для установки файлов СУБД

2) СУБД INFORMIX (предполагается использовать для замены MS SQL в составе Системы):
операционная система - HP-UX ver 11i,
сервер СУБД - IBM INFORMIX DYNAMIC SERVER ver.9.30

аппаратная платформа - HP A500 9000, общей стоимостью около 15000$
1 x HP PA-RISC 64bit Processor at 440Mhg,
1Gb RAM,
HP SCSI320 INTEGRATE CONTROLLER
2 x 36Gb 15k rpm, организованных в RAID 1

При тестах MS SQL никак не оптимизировался, для INFORMIX'а пытались создать наиболее благоприятные
условия для выполнения данных задач. В результате получилось, что при данной конфигурации:

на 10 000 записей INFORMIX медленнее в 6 раз,
на 100 000 записей INFORMIX медленнее в 12 раз,
на 1 000 000 записей INFORMIX медленнее в 18 раз.

Исходя из этого, получается, чтобы мне получить близкую к MS SQL производительность
на HP PA RISC, необходимо брать что-то типа HP RP5460 (четыре проц. PA_RISC 8700 at 875Mhg).
Однако это стоит у них ~ 90 000$, у нас будет около ~ 150 000$. Однако INFORMIX
преобретается для дальнейшего масштабирования, значит сейчас надо брать
что-то типа HP RP7110 (восмипроцессорная платформа) с установкой сейчас четырех процессоров
с возможностью дальнейшего наращивания. Однако это с четырьмя процами будет
стоит у нас будет около ~ 250 000$.
Это нормально, что для получения одинаковой производительности при таком раскладе
железо должно быть на порядок дороже?!
Может при тестах мы плохо оптимизировали сам INFORMIX и/или HP-UX или это нормально на таких железяках?
Может кто из хорошо знающих INFORMIX может помочь в его оптимизации?
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32235173
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
Берите SUN
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32235187
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
Вообще то вы явно что то не то там оптимизировали.

К тому же при вашей трехзвенной архитектуре проблема может быть вообще не в информиксе.

Начинайте тестировать с самого сервера, напишите прогу на esqlc.

По платформе вашей подсказать ничего не могу тк сам работаю с SUN и INTEL.

Начните с того что оцените загрузку сервака onstat-ом например, может он у вас спит.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32235346
SUN взять не можем, т.к. HP и INFORMIX - требования заказчика, которые менятся не могут. Потом, я думаю, что HP явно не хуже SUN'а будет. Тест написан не на Сервере приложений, а как отдельное приложение, которое напрямую работает с БД через OLE DB. Мы то тестируем БД, а не все остальное. Так что в данном случае теституруется только СУБД и ничего больше.
onstat-ом пользуемся, естественно, не спит :). Из всей оптимизации осталось только разнести log, таблицы, индексы, временные файлы, сам сервер на разные space'ы на разных дисках. Возьмем 5 дисков, разнесем, попробуем, должно хоть что -то улучшиться.
Какие могут быть еще советы по оптимизации?
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32235576
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
надо анализировать что именно делает информих

1 вы ожидаете эффекта от разделения данных по разным устройствам на основании чего?
просто так или есть основания. У меня довольно приличные БД по многу гиг лежат на одном диске и я не замечаю проблем.

2 сколько памяти у вас использует информикс? сколько блокировок стоит в конфигурации? сколько буферов?

3 сколько экстентов в больших таблицах?

4 наконец статистику собирали?
5 надо анализировать по профайлу характер загрузки
onstat -i
затем rz
затем -p
с периодом 5 сек будет обновляться профайл .


6 надо анализировать планы запросов
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236124
Привет !!!

>>надо анализировать что именно делает информих
>>
>>1 вы ожидаете эффекта от разделения данных по разным устройствам на основании чего?
>>просто так или есть основания. У меня довольно приличные БД по многу гиг лежат на одном диске и я не замечаю проблем.

На основании того что обращения к разным дискам будет про исходить на много быстрее чем к одному. Хотя в этом случаи желательно чтоб эти диски были на разных контролерах.

>>2 сколько памяти у вас использует информикс? сколько блокировок стоит в >>конфигурации? сколько буферов?

использует памяти 250 М
блокировок 2000
буферов стоит 15000

>>3 сколько экстентов в больших таблицах?


можно пояснить этот термин и если это устанавливается в настройках инфрмикса пояснить где?

>>4 наконец статистику собирали?

да после каждого теста я делаю onstat -a и анализирую данные вроде все было в порядке .

>>5 надо анализировать по профайлу характер загрузки
>>onstat -i
>>затем rz
>>затем -p
>>с периодом 5 сек будет обновляться профайл .
>>
>>
>>6 надо анализировать планы запросов
Буду очень благодарен если вы объясните как это сделать.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236262
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OLEDB для информикса как юзаете?

НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙТЕ IBM INFORMIX OLE DB PROVIDER - жутко тормозной

Используйте MS OLE Db Provider for ODBC и ODBC поновее, еще лучше ODBC или напрямую esqlc.

На чем написан сервер приложений?
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236271
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
Берите SUN

sun отстой, в 2 раза больше процессоров понадобится.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236309
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
>>надо анализировать что именно делает информих 
>> 
>> 1  вы ожидаете эффекта от разделения данных по разным устройствам на основании чего? 
>>просто так или есть основания. У меня довольно приличные БД по многу гиг лежат на одном диске и я не замечаю проблем. 

На основании того что обращения к разным дискам будет про исходить на 
много быстрее чем к одному. Хотя в этом случаи желательно чтоб эти диски 
были на разных контролерах. 

Лучше добиваться кеширования 99.99%, тогда будет пофиг сколько дисков.
Но если активный размер базы много больше чем размер ОЗУ, тогда надо разносить нагрузку на диски фрагментацией информикса, или еще лучше соединить диски в страйп, раид контроллером, и добится максимума производительности минимумом усилий.

Код: plaintext
1.
2.
3.
4.
>> 2  сколько памяти у вас использует информикс? сколько блокировок стоит в >>конфигурации? сколько буферов? 
использует памяти  250  М 
блокировок  2000  
буферов стоит  15000  

Ужас. Информикс использует столько памяти сколько сказано в онконфиге, вам надо максимум озу отдать под буферизацию. Рамер буфера у вас очевидно 2 кб.
onconfig в студию. поправим.

Код: plaintext
1.
2.
>> 3  сколько экстентов в больших таблицах? 
можно пояснить этот термин и если это устанавливается в настройках инфрмикса пояснить где? 

Экстент это количество кусочков на которое разбилась таблица в тейблспесе стремитесь к единице. Задается так:
CREATE TABLE protocol_tbl(
protocol_ident SERIAL NOT NULL,
cs_protocol CHAR(8))
EXTENT SIZE 32 NEXT SIZE 32 LOCK MODE PAGE;
EXTENT SIZE - размер 1-го экстента (кб)
NEXT SIZE - размер следующего (кб)

Код: plaintext
1.
2.
>> 4  наконец статистику собирали? 
да после каждого теста я делаю onstat -a и анализирую данные вроде все было в порядке . 

статистика собирается sql запросом update statistics ... - это сбор распределений значений для постороения планов оптимизатором.
хотя бы раз в день выполняйте к примеру update statistics high, или после массовых изменений таблиц(ы) выполняйте
update statistics high for table MYTABLENAME

Код: plaintext
1.
2.
3.
4.
5.
>> 5  надо анализировать по профайлу характер загрузки 
>>onstat -i 
>>затем rz 
>>затем -p 
>>с периодом  5  сек будет обновляться профайл . 

onstat -p показывает основные характеристики
очень важен уровень кеширования

Код: plaintext
1.
>> 6  надо анализировать планы запросов 
Буду очень благодарен если вы объясните как это сделать.

ушло мылом
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236395
>>Лучше добиваться кеширования 99.99%, тогда будет пофиг сколько дисков.
>>Но если активный размер базы много больше чем размер ОЗУ, тогда надо разносить нагрузку на диски фрагментацией информикса, или еще лучше соединить диски в страйп, раид контроллером, и добится максимума производительности минимумом усилий.


У меня так кэширования и идет.
rofile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
2647 2756 26425433 99.99 97703 229469 2655469 96.32
Страйпом я как разтаки сейчас и занимаюсь

>>Ужас. Информикс использует столько памяти сколько сказано в онконфиге, вам надо максимум озу отдать под буферизацию. Рамер буфера у вас очевидно 2 кб.
onconfig в студию. поправим.

ROOTNAME rootdbs # Root dbspace name
ROOTPATH /dev/vg00/online_roots # Path for device containing root dbspace
ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes)
ROOTSIZE 1048576 # Size of root dbspace (Kbytes)

# Disk Mirroring Configuration Parameters

MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)

# Physical Log Configuration

PHYSDBS logdbs # Location (dbspace) of physical log
PHYSFILE 524288 # Physical log file size (Kbytes)

# Logical Log Configuration

LOGFILES 23 # Number of logical log files
LOGSIZE 8192 # Logical log size (Kbytes)
# Diagnostics

MSGPATH /opt/informix/online.log # System message log file path
CONSOLE /dev/console # System console message path
ALARMPROGRAM /opt/informix/etc/log_full.sh # Alarm program path
TBLSPACE_STATS 1 # Maintain tblspace statistics

# System Archive Tape Device

TAPEDEV /dev/vg00/tapedev # Tape device path
TAPEBLK 16 # Tape block size (Kbytes)
TAPESIZE 10240 # Maximum amount of data to put on tape (Kbytes)

# Log Archive Tape Device

#LTAPEDEV /dev/vg00/tapedev # Log tape device path
LTAPEDEV /dev/null
LTAPEBLK 16 # Log tape block size (Kbytes)
LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes)

# Optical

STAGEBLOB # Informix Dynamic Server staging area
# System Configuration

SERVERNUM 0 # Unique id corresponding to a OnLine instance
DBSERVERNAME demo_on # Name of default database server
DBSERVERALIASES ifx_tcp # List of alternate dbservernames
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env.
RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)

MULTIPROCESSOR 0 # 0 for single-processor, 1 for multi-processor
NUMCPUVPS 1 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one

NOAGE 0 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
# Shared Memory Parameters

LOCKS 2000 # Maximum number of locks
BUFFERS 15000 # Maximum number of shared buffers
NUMAIOVPS 1 # Number of IO vps
PHYSBUFF 256 # Physical log buffer size (Kbytes)
LOGBUFF 16 # Logical log buffer size (Kbytes)
CLEANERS 1 # Number of buffer cleaner processes
SHMBASE 0x0 # Shared memory base address
SHMVIRTSIZE 10240 # initial virtual shared memory segment size
SHMADD 131072 # Size of new shared memory segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
LRUS 1 # 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 0x12c # Transaction timeout (in sec)
STACKSIZE 512 # Stack size (Kbytes)
# System Page Size
# BUFFSIZE - OnLine no longer supports this configuration parameter.
# To determine the page size used by OnLine on your platform
# see the last line of output from the command, 'onstat -b'.


# Recovery Variables
# OFF_RECVRY_THREADS:
# Number of parallel worker threads during fast recovery or an offline restore.
# ON_RECVRY_THREADS:
# Number of parallel worker threads during an online restore.

OFF_RECVRY_THREADS 1 # Default number of offline worker threads
ON_RECVRY_THREADS 1 # Default number of online worker threads

# Data Replication Variables
DRINTERVAL 30 # DR max time between DR buffer flushes (in sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /opt/informix/etc/dr.lostfound # DR lost+found file path

# CDR Variables
CDR_EVALTHREADS 1,2 # evaluator threads (per-cpu-vp,additional)
CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds)
CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue (Kb
ytes)
CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0 none, 9 m
x)
CDR_SERIAL 0,0 # Serial Column Sequence
CDR_DBSPACE # dbspace for syscdr database
CDR_QHDR_DBSPACE # CDR queue dbspace (default same as catalog)
CDR_QDATA_SBSPACE # CDR queue smart blob space
CDR_QDATA_SBFLAGS 0 # Log/no-log (default no log)


# Backup/Restore variables
BAR_ACT_LOG /opt/informix/bar_act.log # ON-Bar Log file - not in /tmp pleas
BAR_DEBUG_LOG /opt/informix/bar_dbug.log
# ON-Bar Debug Log - not in /tmp please
BAR_MAX_BACKUP 0
BAR_RETRY 1
BAR_NB_XPORT_COUNT 10
BAR_XFER_BUF_SIZE 31
RESTARTABLE_RESTORE on
BAR_PROGRESS_FREQ 0

# Informix Storage Manager variables
ISM_DATA_POOL ISMData
ISM_LOG_POOL ISMLogs
# Read Ahead Variables
RA_PAGES 4 # Number of pages to attempt to read ahead
RA_THRESHOLD 2 # Number of pages left before next group

# DBSPACETEMP:
# OnLine equivalent of DBTEMP for SE. This is the list of dbspaces
# that the OnLine SQL Engine will use to create temp tables etc.
# If specified it must be a colon separated list of dbspaces that exist
# when the OnLine system is brought online. If not specified, or if
# all dbspaces specified are invalid, various ad hoc queries will create
# temporary files in /tmp instead.

DBSPACETEMP tmpdbs # Default temp dbspaces

# DUMP*:
# The following parameters control the type of diagnostics information which
# is preserved when an unanticipated error condition (assertion failure) occurs
# during OnLine operations.
# For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
DUMPDIR /tmp # Preserve diagnostics in this directory
DUMPSHMEM 1 # Dump a copy of shared memory
DUMPGCORE 0 # Dump a core image using 'gcore'
DUMPCORE 0 # Dump a core image (Warning:this aborts OnLine)
DUMPCNT 1 # Number of shared memory or gcore dumps for
# a single user's session

FILLFACTOR 90 # Fill factor for building indexes

# method for OnLine to use when determining current time
USEOSTIME 0 # 0: use internal time(fast), 1: get time from O
S(slow)

# Parallel Database Queries (pdq)
MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
DS_MAX_QUERIES 8 # Maximum number of decision support queries
DS_TOTAL_MEMORY 8192 # Decision support memory (Kbytes)
DS_MAX_SCANS 1048576 # Maximum number of decision support scans

DATASKIP off # List of dbspaces to skip
# OPTCOMPIND
# 0 => Nested loop joins will be preferred (where
# possible) over sortmerge joins and hash joins.
# 1 => If the transaction isolation mode is not
# "repeatable read", optimizer behaves as in (2)
# below. Otherwise it behaves as in (0) above.
# 2 => Use costs regardless of the transaction isolation
# mode. Nested loop joins are not necessarily
# preferred. Optimizer bases its decision purely
# on costs.
OPTCOMPIND 2 # To hint the optimizer

DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or OFF (0)


ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 = ABORT,
2 = WAIT
OPCACHEMAX 131072 # Maximum optical cache size (Kbytes)

# HETERO_COMMIT (Gateway participation in distributed transactions)
# 1 => Heterogeneous Commit is enabled
# 0 (or any other value) => Heterogeneous Commit is disabled
HETERO_COMMIT 0
SBSPACENAME # Default smartblob space name - this is where b
lobs
# go if no sbspace is specified when the smartblob is
# created. It is also used by some datablades as
# the location to put their smartblobs.
SYSSBSPACENAME # Default smartblob space for use by the Informi
x
# Server. This is used primarily for Informix Server
# system statistics collection.

BLOCKTIMEOUT 3600 # Default timeout for system block
SYSALARMPROGRAM /opt/informix/etc/evidence.sh # System Alarm program path

# Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
OPT_GOAL -1

ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or anything
but 1)


>>ушло мылом

Спасибо большое за мыло:)
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236421
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
HP отстой
SUN рулез
процессоров потребуется в два раза меньше
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236442
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Начнем помаленьку:
Код: plaintext
1.
2.
3.
4.
ROOTNAME rootdbs # Root dbspace name 
ROOTPATH /dev/vg00/online_roots # Path for device containing root dbspace 
ROOTOFFSET  0  # Offset of root dbspace into device (Kbytes) 
ROOTSIZE  1048576  # Size of root dbspace (Kbytes) 


/dev/vg00/online_roots - Это чего файл? Или устройство?
если это raw device то ROOTOFFSET должен быть минимум 4, иначе все навернется.

ROOTSIZE 1048576

Нафига большой такой? Чего туда сложили? Метров 300 хватит за глаза.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236486
>>/dev/vg00/online_roots - Это чего файл? Или устройство?
если это raw device то ROOTOFFSET должен быть минимум 4, иначе все навернется.

Это отдельное устройство.

>>ROOTSIZE 1048576
>>
>>Нафига большой такой? Чего туда сложили? Метров 300 хватит за глаза.

Дело в том что при создании отдельный спейсов под физический и логический лог не было и он не давал создать меньше 600М
Хотя теперь можно сократить это т размер чуть ли не в 10 раз.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236556
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
>>/dev/vg00/online_roots - Это чего файл? Или устройство? 
если это raw device то ROOTOFFSET должен быть минимум  4 , иначе все навернется. 

Это отдельное устройство


В каком смысле отдельное?
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236604
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
LOGFILES  23  # Number of logical log files 
LOGSIZE  8192  # Logical log size (Kbytes) 

Для реальной работы наверно мало, я бы сделал 10 по 100 мегов.

Код: plaintext
TBLSPACE_STATS  1  # Maintain tblspace statistics 

Собирает статистику обращений к таблице (кол-во insert,update, ....)
TBLSPACE_STATS 0 - при реальной работе и замере производительности.

Код: plaintext
1.
LOCKS  2000  # Maximum number of locks 
BUFFERS  15000  # Maximum number of shared buffers 


LOCKS 100000 - размер лока 44 байта.
BUFFERS 350000 - при буфере 2кб = 700 мб

Код: plaintext
NUMAIOVPS  1  # Number of IO vps 

Я не курсе про hp-ux KAIO там можно использовать?

Код: plaintext
1.
SHMVIRTSIZE  10240  # initial virtual shared memory segment size 
SHMADD  131072  # Size of new shared memory segments (Kbytes) 

SHMADD больше SHMVIRTSIZE - забавно :)
SHMVIRTSIZE 131072
SHMADD 10240

Код: plaintext
1.
RA_PAGES  4  # Number of pages to attempt to read ahead 
RA_THRESHOLD  2  # Number of pages left before next group 

Упреждающее чтение, вещь нужная
RA_PAGES 48
RA_THRESHOLD 16

Код: plaintext
1.
DUMPDIR /tmp # Preserve diagnostics in this directory 
DUMPSHMEM  1  # Dump a copy of shared memory 

DUMPSHMEM 0 - врядли кто-то сможет понять содержимое дампа кроме IBM

Код: plaintext
OPTCOMPIND  2  # To hint the optimizer 

Иногда для OLTP систем лучше выставить 0, в этом случае индексы юзаются активней, меньше дискового чтения.

Код: plaintext
ONDBSPACEDOWN  2  

ONDBSPACEDOWN 0


Поменяйте онконфиг, перестартуйте информикс, прогоните тест, и киньте сюда

onstat -p
onstat -g iof
onstat -m (лучше кусок /opt/informix/online.log)
onstat -g seg
onstat -F
onstat -R
onstat -u
onstat -l
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236749
После всех изменений вот что получилось

root@hp:/opt/informix/etc/$ onstat -p

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 00:22:35 -- 804284
Kbytes

Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
1280 1621 5128876 99.98 97057 144491 1562547 93.79

isamtot open start read write rewrite delete commit rollbk
5858619 493158 156748 2311219 1072066 10284 11750 79923 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 209.99 37.69 6 14

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
197 0 5682517 0 0 4 3315 467

ixda-RA idx-RA da-RA RA-pgsused lchwaits
9 0 266 275 311251



root@hp:/opt/informix/etc/$ onstat -g iof

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 00:23:42 -- 804284
Kbytes

AIO global files:
gfd pathname totalops dskread dskwrite io/s
3 online_roots 73246 45 73201 51.5
4 /dev/vg00/tmpdbs 3 1 2 0.0
5 datadbs 1938 994 944 1.4
6 /dev/vg00/logdbs 13118 7 13111 9.2

root@hp:/opt/informix/etc/$ onstat -m

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 00:24:37 -- 804284
Kbytes

Message Log File: /opt/informix/online.log
17:47:31 Logical Log 1360 Complete.
17:47:33 Process exited with return code 142: /bin/sh /bin/sh -c /opt/informix/
etc/log_full.sh 2 23 "Logical Log 1360 Complete." "Logical Log 1360 Complete."
17:47:44 Logical Log 1361 Complete.
17:47:46 Process exited with return code 142: /bin/sh /bin/sh -c /opt/informix/
etc/log_full.sh 2 23 "Logical Log 1361 Complete." "Logical Log 1361 Complete."
17:47:58 Logical Log 1362 Complete.
17:48:00 Process exited with return code 142: /bin/sh /bin/sh -c /opt/informix/
etc/log_full.sh 2 23 "Logical Log 1362 Complete." "Logical Log 1362 Complete."
17:48:13 Logical Log 1363 Complete.
17:48:16 Process exited with return code 142: /bin/sh /bin/sh -c /opt/informix/
etc/log_full.sh 2 23 "Logical Log 1363 Complete." "Logical Log 1363 Complete."
17:48:26 Logical Log 1364 Complete.
17:48:28 Process exited with return code 142: /bin/sh /bin/sh -c /opt/informix/
etc/log_full.sh 2 23 "Logical Log 1364 Complete." "Logical Log 1364 Complete."
17:48:40 Logical Log 1365 Complete.
17:48:42 Process exited with return code 142: /bin/sh /bin/sh -c /opt/informix/
etc/log_full.sh 2 23 "Logical Log 1365 Complete." "Logical Log 1365 Complete."
17:48:54 Logical Log 1366 Complete.
17:48:57 Process exited with return code 142: /bin/sh /bin/sh -c /opt/informix
etc/log_full.sh 2 23 "Logical Log 1366 Complete." "Logical Log 1366 Complete."
17:49:08 Logical Log 1367 Complete.
17:49:11 Process exited with return code 142: /bin/sh /bin/sh -c /opt/informix
etc/log_full.sh 2 23 "Logical Log 1367 Complete." "Logical Log 1367 Complete."
17:50:53 Checkpoint Completed: duration was 2 seconds.
17:50:53 Checkpoint loguniq 1368, logpos 0x362018

17:50:53 Maximum server connections 2

root@hp:/opt/informix/etc/$ onstat -g seg

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 00:25:45 -- 804284
Kbytes

Segment Summary:
id key addr size ovhd class blkused bl
kfree
14606 1381386241 c0000000003bd000 801927168 448280 R 195756 27

618 1381386253 c000000030084000 10485760 952 V 1661 89
9
619 1381386254 c000000030a84000 10485760 952 V 2016 54
4
620 1381386255 c000000031484000 688128 656 M 135 33

Total: - - 823586816 - - 199568 15
03

(* segment locked in memory)


root@hp:/opt/informix/etc/$ onstat -F

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 00:28:34 -- 804284
Kbytes


Fg Writes LRU Writes Chunk Writes
0 0 10792

address flusher state data
c000000030332848 0 I 0 = 0X0
states: Exit Idle Chunk Lru

root@hp:/opt/informix/etc/$ onstat -R

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 00:29:13 -- 804284
Kbytes

1 buffer LRU queue pairs priority levels
# f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
0 F 350000 100.0% 350000 341180 8603 206 11
1 m 0.0% 0 0 0 0 0
0 dirty, 350000 queued, 350000 total, 524288 hash buckets, 2048 buffer size
start clean at 60% (of pair total) dirty, or 210000 buffs dirty, stop at 50%
0 priority downgrades, 0 priority upgrades

root@hp:/opt/informix/etc/$ onstat -u

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 00:29:46 -- 804284
Kbytes

Userthreads
address flags sessid user tty wait tout locks
nreads nwrites
c000000030332028 ---P--D 1 root - 0 0 0
25 269
c000000030332848 ---P--F 0 root - 0 0 0
0 10792
c000000030333068 ---P--- 9 root - 0 0 0
0 0
c000000030333888 ---P--B 10 root - 0 0 0
0 0
c0000000303350e8 ---P--D 13 root - 0 0 0
0 0
5 active, 128 total, 9 maximum concurrent

root@hp:/opt/informix/etc/$ onstat -l

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 00:30:23 -- 804284
Kbytes

Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-1 0 128 2668 26 102.62
phybegin physize phypos phyused %used
400835 262144 13940 0 0.00

Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-2 0 8 1593630 130990 86224 12.2 1.5
Subsystem numrecs Log Space used
OLDRSAM 1593630 141068620

address number flags uniqid begin size used %used
c000000030386928 1 U-B---- 1354 1004ef 2048 2048 100.00
c000000030386978 2 U-B---- 1355 100cef 2048 2048 100.00
c0000000303869c8 3 U-B---- 1356 1014ef 2048 2048 100.00
c000000030386a18 4 U-B---- 1357 101cef 2048 2048 100.00
c000000030386a68 5 U-B---- 1358 1024ef 2048 2048 100.00
c000000030386ab8 6 U-B---- 1359 102cef 2048 2048 100.00
c000000030386b08 7 U-B---- 1360 1034ef 2048 2048 100.00
c000000030386b58 8 U-B---- 1361 103cef 2048 2048 100.00
c000000030386ba8 9 U-B---- 1362 1044ef 2048 2048 100.00
c000000030386bf8 10 U-B---- 1363 104cef 2048 2048 100.00
c000000030386c48 11 U-B---- 1364 1054ef 2048 2048 100.00
c000000030386c98 12 U-B---- 1365 105cef 2048 2048 100.00
c000000030386ce8 13 U-B---- 1366 1064ef 2048 2048 100.00
c000000030386d38 14 U-B---- 1367 106cef 2048 2048 100.00
c000000030386d88 15 U---C-L 1368 1074ef 2048 867 42.33
c000000030386dd8 16 U-B---- 1346 107cef 2048 2048 100.00
c000000030386e28 17 U-B---- 1347 1084ef 2048 2048 100.00
c000000030386e78 18 U-B---- 1348 108cef 2048 2048 100.00
c000000030386ec8 19 U-B---- 1349 1094ef 2048 2048 100.00
c000000030386f18 20 U-B---- 1350 109cef 2048 2048 100.00
c000000030386f68 21 U-B---- 1351 400035 2048 2048 100.00
c000000030386fb8 22 U-B---- 1352 440835 2048 2048 100.00
c0000000302051b0 23 U-B---- 1353 441035 2048 2048 100.00
23 active, 23 total
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32236861
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Очень маленький размер журналов, слишком часто они кончаются.
С помощью onspaces создайте еще один спейс на 1 гиг
С помощью onparams в нем создайте 10 лог. журналов по 100мгб

SHMVIRTSIZE 25000

CLEANERS 10
LRUS 10

Используйте raw device.

покажи onstat -g ioq

Я уже спрашивал, но все же, На чем написан сервер приложений, и какой способ доступа к информиксу используется?
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237004
>>Очень маленький размер журналов, слишком часто они кончаются.
>>С помощью onspaces создайте еще один спейс на 1 гиг
>>С помощью onparams в нем создайте 10 лог. журналов по 100мгб
>>
>>SHMVIRTSIZE 25000
>>
>>CLEANERS 10
>>LRUS 10
>>
>>Используйте raw device.

ок сделаю.

>>покажи onstat -g ioq

root@hp:/opt/informix/etc/$ onstat -g ioq

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 02:50:00 -- 804284
Kbytes

AIO I/O queues:
q name/id len maxlen totalops dskread dskwrite dskcopy
adt 0 0 0 0 0 0 0
msc 0 0 1 259 0 0 0
aio 0 0 1 61 17 2 0
pio 0 0 1 83 0 83 0
lio 0 0 1 427250 0 427250 0
gfd 3 0 16 680 45 635 0
gfd 4 0 3 4 1 3 0
gfd 5 0 49 65609 1239 64370 0
gfd 6 0 1 7 7 0 0

>>Я уже спрашивал, но все же, На чем написан сервер приложений, и какой способ доступа к информиксу используется?

Сервет приложений пока не используеться пока проводяться только тесты
а доступ через IBM INFORMIX OLE DB PROVIDER
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237163
Хех, медленнее в 16 раз, это нужно уметь.

HP неплохая платформа, только имеет свои особенности.
с одним процессором, это для Informix'a не жизнь, но и с ним он будет бегат, лучше M$, хотя разница будет ощущаться от 4 CPU. с версии 7, ядро Informix'a рассчитано на мультипроцессорность.

Тут вроде бы уже подправили, так что я о специфике.

raw device - уже сказали, лучше их использовать, чем не использовать.

Обязательно включить KAIO , у HP они дадут увеличение IO на 10-15%
Прочитать как, можно в $INFORMIXDIR/release/IDS_9.3
Там же будут рекомендации по параметрам HP кернела и список patches. Проверить, поставить. С этого момента, HP готова к использованию.

NUMAIOVPS 1
Без KAIO, это как ездить на одном колесе. у вас нет лишних CPU, и использование виртуального IO процессора, Будет сжирать то немногое, что есть. Включить KAIO, и поставить после этого, этото параметр в 4. А сейчас у вас одна длинная очередь на один виртуальный процессор.

NOAGE 0
HP Очень агрессивно понижает приоритеты, поэтому для этот параметр всегда ставится в 1.

Большое у меня подозрение, что с посоветованными параметрами буферов и виртуального сегмента, после загрузки, система сидит в свопинге.
swapinfo, sar -w

В зависимости от природы тестов, тут память можно перебрасывать в разные стороны, но проверьте свопинг сначало ;)

какой striping size на RAID, если 2К, то это очень и очень плохо.

И это мы ещё не пришли к оптимизации Informix'a, только специфика платформы.

CLEANERS 1 # Number of buffer cleaner processes
CKPTINTVL 300 # Check point interval (in sec)
LRUS 1 # Number of LRU queues
LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limi

Эти параметры тоже нужно риxтовать, так как по приведенной статистике это следуяшее узкое место в системе, скорее всего тратится неоправданно много времени на checkpoints.

Но оптимизация Informix'a уже базируется на знании приложения, пусть даже и тестового, так что пальцем в небо тыкать не хочется.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237393
wan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет!

>>Обязательно включить KAIO , у HP они дадут увеличение IO на 10-15%
>>Прочитать как, можно в $INFORMIXDIR/release/IDS_9.3
>>Там же будут рекомендации по параметрам HP кернела и список patches. Проверить, поставить. С этого момента, HP готова к использованию.

KAIO сейчас включаем
на счет патчев в доке указаны очень ранние версии у нас стоят но более поздние так что вот дилемма ставить или нет?

>>Большое у меня подозрение, что с посоветованными параметрами буферов и >>виртуального сегмента, после загрузки, система сидит в свопинге.
>>swapinfo, sar -w

я давно наблюдал за этим и по данным в своп не чего не падает только отдельные страницы и то редко

>>какой striping size на RAID, если 2К, то это очень и очень плохо.

striping size = 16K

>>Но оптимизация Informix'a уже базируется на знании приложения, пусть даже и тестового, так что пальцем в небо тыкать не хочется.

тестовое приложения использует вот такую логику

/*
Создание таблиц
*/
create table SpecTaxModes
(
id int not null primary key,
code int not null unique,
name nvarchar(255) not null unique,
name_K nvarchar(255) not null,
shortName nvarchar(50) not null unique,
shortName_k nvarchar(50) not null
)

go
create table PaymentTypes
(
paymentType tinyint not null primary key,
name varchar(255) not null unique
)

go
create table TaxClassification
(
id int not null primary key,
code varchar(255) not null unique,
shortName varchar(100) not null unique,
name varchar(255) not null unique
)


go
create table ReportData_Operations
(
id int not null primary key,
docDate smalldatetime not null,
classId int not null references TaxClassification(id),
specTaxModeId int not null references SpecTaxModes(id),
opDate smalldatetime not null,
value float not null,
paymentType tinyint not null references PaymentTypes (paymentType),
attr tinyint not null,
autoPen tinyint not null,
writedate smalldatetime not null,
effectiveDate smalldatetime not null
)

go
create index index1 on ReportData_Operations (opDate)
go
create index index2 on ReportData_Operations (classId)
go
create index index3 on ReportData_Operations (specTaxModeId)
go
create index index4 on ReportData_Operations (paymentType)

/*
заполнение справочников
количество записей в справочнике SpecTaxModes 9
количество записей в справочнике PaymentTypes 4
количество записей в справочнике TaxClassification MAX/2
*/
INSERT into PaymentTypes (paymentType, name) VALUES(0, 'Налог0')

INSERT INTO SpecTaxModes (id, code, name, name_k, shortName,shortName_k ) VALUES
(0, 0, 'Специальный налоговый режим на основе патента для субъектов малого бизнеса0','Специальный налоговый режим на основе патента для субъектов малого бизнеса0','Спец. нал. режим на основе патента0','Спец. нал. режим на основе патента0')

INSERT into TaxClassification(id, code, shortName, name) VALUES(0,'0' , 'Внебюджетная классификация № 0','Внебюджетная классификация № 0')
/*
заполнение основной таблицы MAX раз
*/
Insert into ReportData_Operations (id,docDate,classId,specTaxModeId,opDate,value,paymentType,attr,autoPen,writedate,effectiveDate) values
(0,'2003-8-7 00:00:00',0,0,'2003-8-7 00:00:00',0,0,0,0,'2003-8-7 00:00:00','2003-8-7 00:00:00')
/*
поиск еденичной записи MAX раз
*/
select id,docDate,classId,specTaxModeId,opDate,value,paymentType,attr,autoPen,writedate,effectiveDate from ReportData_Operations where id = 1
/*
поиск группы записей MAX раз (максимальное количество строк 366)
*/
select id,docDate,classId,specTaxModeId,opDate,value,paymentType,attr,autoPen,writedate,effectiveDate from ReportData_Operations where opdate >= '2003-8-7 00:00:00' and opdate <= '2004-8-6 00:00:00' and attr=0
/*
создание и заполнение временной таблицы 100раз
*/
create table #ReportData_Operations
(
id int not null,
docDate smalldatetime not null,
classId int not null,
specTaxModeId int ,
opDate smalldatetime not null,
value float not null,
paymentType tinyint not null,
attr tinyint not null,
autoPen tinyint not null,
writedate smalldatetime not null,
effectiveDate smalldatetime not null
)
go
insert into #ReportData_Operations select * from ReportData_Operations
go
drop table #ReportData_Operations
/*
обновление MAX раз
*/
Update ReportData_Operations set writedate = '2003-8-7 00:00:00',effectiveDate = '2003-8-7 00:00:00' where id = 0
/*
удаление MAX раз
*/
Delete from ReportData_Operations where id = 0
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237501
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я бы тест видоизменил. То что исполняется max раз, я бы запускал вперемешку, по рандому, и в 100 коннектах, вот тогда это стала бы реальная симуляция работы нескольких пользователей. Иначе информикс будет проигрывать MSSQL причем я считаю по двум причинам:

1. Informix OLE DB Provider - отстой (офигительно тормознутый и к тому же основательно грузит процессор клиента при конвертации данных).

2. MS SQL кеширует планы выполнения SQL запросов, Informix нет (такая возможность есть (STMT_CACHE), но это глюк сплошной).
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237534
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
Я чевойто не понял
у вас в реальной работе все время создаются таблицы что ли?
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237539
По поводу сервера приложений:

Первоначально доуступ к Informix'у мы пытались осуществить посредством IBM Informix OLE DB Provider 2.60 и 2.80. Обе эти версии не работают с распределёнными транзакциями.
После этого мы стали использовать IBM Informix JDBC Driver 2.21. Этот драйвер реализует распределённые транзакции посредством XA_Transaction.

Наш сервер приложений написан на C++ под Windows. В качестве менеджера распределённых транзакций используется MS DTC. Поэтому нам пришлось писать мост XA<->MS DTC для работы посредством JDBC.
При работе посредством JDBC запросы и транзакции отрабатывались успешно, без сбоев. Тест на производительность драйвера IBM Informix JDBC Driver 2.21 не производился, но работал он достаточно быстро, чтоб обвинить его в торможении.

По поводу запросов в тесте. Для эмуляции нескольких одновременных соединений так и сделали. Завтра будут результаты.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237554
to cpr

Да, есть в паре мест в нашей Системе такой механизм, который создает таблицы для расширения функциональности. Например необходимо создать новые представления/отчеты, которые формируются поэтапно с промежуточными результатами (поскольку система сильно территориально распределенная). Вот там логика сервера приложения использует автоматическое создание таблиц нужной структуры. Конечно, это работает не постоянно, но используется.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237692
Нет таблицы конечно не создаются но данные вноситься постоянно
а ради частоты теста все создается с нуля.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32237702
Макс не прав, он не совсем в курсе, таблицы, как я уже говорил, автоматически создаются сервером приложений (нужно для определенной специфичной функциональности Системы), однако не постоянно, конечно.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32238024
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
кстати по вашему профайлу
это данные за какой период времени?

надо за короткий период во время теста .

После увеличения количества буферов и блокировок что нибудь изменилось или нет?
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32238347
Ага. Резюме того, что есть.
IDS 9.31FC1
HP A500 9000, 1 x HP PA-RISC 64bit Processor at 440Mhg,
1Gb RAM,
HP SCSI320 INTEGRATE CONTROLLER
2 x 36Gb 15k rpm, организованных в RAID 1 (striping size 16K)

Набор железок слабоват, но жить вполне можно.
К сожалению, с таким обьемом памяти и количеством процессоров, многие радости 9 версии буду не доступны. Поэтому нужно идти по пути экономии, где только можно.

Сразу хочется заметить, что в такой конфигурации железа вы за Informix переплачиваете, так как большая часть его возможностей вам недоступна. Минимум 2 CPU, более менее серьезная система начинается от 4 ну и память конечно. Возможно, что использование старой версии Informix OnLine для вас окажется экономически выгоднее сначало, да и работать она на таком железе будет быстрее, а потом мигрировать на девятку. Ну да это мысли в слух.

Вернемся к прозе. Старые патчи ставить не нужно. Они уже включены в поставку, тут есть нюансы при подготовке рабочего сервера, но для тестового вполне сойдет и так. KAIO надеюсь включили ?

Еще немного о конфигурации железок.
stripping size лучше увеличить до 32К/64К т.к. настроенной базе где то такими блоками и будет происходить чтение.
HP имеет не лучшую архитектуру shared memory, поэтому чем меньше сегментов тем лучше.Старайтесь, что бы у вас было максимум три/четыре сегмента по onstat -g seg.

Еще немного лирики. Идеологически тестовый сервер должен настраиваться как рабочий, т.е. уровень затрат ДБА на настройку почти такой же, поэтому начальная настройка любой серьезной базы достаточно муторное дело, зато потом система стоит 24х7 и если вы думаете, что конфигурация Informix'a сложна и недружелюбна (не один клик), то могу вас уверить, что это неправда ;) это еще очень просто, если мы будем сравнивать с Oracle,DB2.

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

Собственно, приведенный тест можно разделить на три части:
-Создание и загрузка таблиц
-поиск по таблицам
-временные таблицы.
Подозреваю, что все три пункта на стороне Informix'a были выполнены с грубыми ошибками.

1. Создание и загрузка таблиц
Для таблиц принято сначало рассчитывать extent size, чтобы данная таблица лежала в одном непрерывным куском и время не тратилось на переходы по extents
В данном extents случае _должны_ быть рассчитаны для
TaxClassification
ReportData_Operations

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

Тэкс, на пальцах
TaxClassification (500000) + index ~350000K
ReportData_Operations(1000000) +indexes ~170000K
Это очень грубый подсчет(мог чего нибудь и не учесть), если интересно, то более точно пересчитайте сами, но лучше хоть так, чем вообще никак

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

M$ не имеет/ел(насколько я знаю) понятия физический журнал. Они его только сейчас открывают. :)

Более корретным бы было сравнение утилит загрузки bcp от MS и HPL от Informix'a.
В любом случае, вставки такой интенсивности делаются обычно через курсоры.

Так же принят другой порядок загрузки: создание таблицы, загрузка, создание индексов, включение журналирования (да у и Informix включение/выключение журналирования возможны)

2. поиск по таблицам
Сбор статистики в правило. Возмите например mkupdstats с http://iiug.org/software/index_DBA.html
и собирайте статистику после окончания загрузки.

3. временные таблицы.
Добавте еще минимум два dbspaces для временных таблиц, умеет работать с ними параллельно и с включенными KAIO, может существенно помочь.
По умолчанию временные таблицы в Informix'e _журналируемые_, обязательно создаваюте временную таблицы с WITH NO LOG.

Конфигурация:

LOGSIZE 8192 (Тут есть разные подходы, но в принципе для теста можно и увеличить до 50-100Мб)
TBLSPACE_STATS 1 (В 0)
NOAGE 0 (в 1)
RESIDENT 0 (-1) (Какой смысл от буферов лежащих в свопинге ? )
BUFFERS 15000 (Уже увеличили по моему и даже без свопинга.)
NUMAIOVPS 1 (Включить KAIO, а этот параметр в 2 или 4)
CLEANERS 1 (8-10)

Вот тут масса вариантов, да еще и связанных с возможностями железок
Можно попробовать выставить
LRUS 1 (127)
LRU_MAX_DIRTY 60 (2)
LRU_MIN_DIRTY 50 (1 )
CKPTINTVL 300 (6000)
Более полно можно почитать дискуссии в newsgroup

RA_PAGES 4 (16)
RA_THRESHOLD 2 (8)
(Уже поменяли, в принципе нужно высчитывать по статистике и типам запросов, в данном тесте особой роли не играет)

DBSPACETEMP tmpdbs (tmpdbs,tmpdbs1,tmpdbs2)

MAX_PDQPRIORITY 100 (0) (Проще выключить, у вас нет процессоров и памяти потдерживать эту роскошь)

OPTCOMPIND 2(0) (По тестовым запросам не видно, что вы нуждаетесь в сверхоптимизации. Этот параметр в OLTP обычно 0)
OPT_GOAL -1 (0 (?) ) (Можно попробовать выставить в 0)

В принципе, вы же собираетесь принимать решение о возможности потдержки вашей системы Informix, почему бы не нанять информиксоида и системщика(если его нет) на несколько дней для конфигурации тестового сервера. это обычно дешевле чем ошибки в принятии решения.
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32239775
Привет
вот что получаеться

>>LRUS 1 (127)
>>LRU_MAX_DIRTY 60 (2)
>>LRU_MIN_DIRTY 50 (1 )
>>CKPTINTVL 300 (6000)

после изменения этих параметров
время вставки увеличилось на порядок

сейчас тесты проводятся на другой машине вот ее характеристики

аппаратная платформа - HP Rp5470,
4 x HP PA-RISC 64bit Processor at 550Mhg,
8Gb RAM,
HP SCSI320 INTEGRATE CONTROLLER
2 x 18Gb 10k rpm
VA7100 12*36GB 15K RPM

работы ведутся на одном CPU оставшиеся 3 отключены
и 2G памяти

Тест был исправлен так что одновременно работают 10 сессий и на каждую по до 100000 итераций

испытания по следующим позициям
Создание таблиц, заполнение справочников
Время вставки единичных записей
Время поиска единичных записей
Время поиска группы
Время вставки записей из запроса Время обновления записей. Время удаления записей

На сервере HP PROLIANT ML370 G3 + MSSQL тест прошел за 2 часа
на HP_Ux + INFORMIX тест еще не закончился и идет уже более 10 часов
ядро HP_UX оттюнено как и положено по доке
вот конфиг файл



#**************************************************************************
#
# INFORMIX SOFTWARE, INC.
#
# Title: onconfig.std
# Description: Informix Dynamic Server Configuration Parameters
#
#**************************************************************************

# Root Dbspace Configuration

ROOTNAME rootdbs # Root dbspace name
ROOTPATH /dev/vginf/rlvol1 # Path for device containing root dbspace
ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes)
ROOTSIZE 51200

# Disk Mirroring Configuration Parameters

MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)

# Physical Log Configuration

PHYSDBS phlog # Location (dbspace) of physical log


PHYSFILE 2080000 # Physical log file size (Kbytes)

# Logical Log Configuration

LOGFILES 28 # Number of logical log files
LOGSIZE 51200 # Logical log size (Kbytes)

# Diagnostics

MSGPATH /home/informix/online.log # System message log file path
CONSOLE /dev/console # System console message path
ALARMPROGRAM /home/informix/etc/log_full.sh # Alarm program path
TBLSPACE_STATS 0 # Maintain tblspace statistics

# System Archive Tape Device

TAPEDEV /dev/null # Tape device path
TAPEBLK 16 # Tape block size (Kbytes)
TAPESIZE 10240 # Maximum amount of data to put on tape (Kbytes)

# Log Archive Tape Device

LTAPEDEV /dev/null # Log tape device path
LTAPEBLK 16 # Log tape block size (Kbytes)
LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes)

# Optical

STAGEBLOB # Informix Dynamic Server staging area

# System Configuration

SERVERNUM 0 # Unique id corresponding to a OnLine instance
DBSERVERNAME astana # Name of default database server
DBSERVERALIASES ifx_tcp # List of alternate dbservernames
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env.
RESIDENT 1 # Forced residency flag (Yes = 1, No = 0)

MULTIPROCESSOR 0 # 0 for single-processor, 1 for multi-processor
NUMCPUVPS 1 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one

NOAGE 1 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors

# Shared Memory Parameters

LOCKS 100000 # Maximum number of locks
BUFFERS 350000 # Maximum number of shared buffers
NUMAIOVPS # Number of IO vps
PHYSBUFF 256 # Physical log buffer size (Kbytes)
LOGBUFF 16 # Logical log buffer size (Kbytes)
CLEANERS 10 # Number of buffer cleaner processes
SHMBASE 0x0 # Shared memory base address
SHMVIRTSIZE 25000 # initial virtual shared memory segment size
SHMADD 10240 # Size of new shared memory segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 400 # Check point interval (in sec)
LRUS 10 # 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 0x12c # Transaction timeout (in sec)
STACKSIZE 512 # Stack size (Kbytes)

# System Page Size
# BUFFSIZE - OnLine no longer supports this configuration parameter.
# To determine the page size used by OnLine on your platform
# see the last line of output from the command, 'onstat -b'.


# Recovery Variables
# OFF_RECVRY_THREADS:
# Number of parallel worker threads during fast recovery or an offline restore.
# ON_RECVRY_THREADS:
# Number of parallel worker threads during an online restore.

OFF_RECVRY_THREADS 1 # Default number of offline worker threads
ON_RECVRY_THREADS 1 # Default number of online worker threads

# Data Replication Variables
DRINTERVAL 30 # DR max time between DR buffer flushes (in sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /home/informix/etc/dr.lostfound # DR lost+found file path

# CDR Variables
CDR_EVALTHREADS 1,2 # evaluator threads (per-cpu-vp,additional)
CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds)
CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue (Kbytes)
CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0 none, 9 max)
CDR_SERIAL 0,0 # Serial Column Sequence
CDR_DBSPACE # dbspace for syscdr database
CDR_QHDR_DBSPACE # CDR queue dbspace (default same as catalog)
CDR_QDATA_SBSPACE # CDR queue smart blob space
CDR_QDATA_SBFLAGS 0 # Log/no-log (default no log)


# Backup/Restore variables
BAR_ACT_LOG /usr/informix/bar_act.log # ON-Bar Log file - not in /tmp please
BAR_DEBUG_LOG /usr/informix/bar_dbug.log
# ON-Bar Debug Log - not in /tmp please
BAR_MAX_BACKUP 0
BAR_RETRY 1
BAR_NB_XPORT_COUNT 10
BAR_XFER_BUF_SIZE 31
RESTARTABLE_RESTORE on
BAR_PROGRESS_FREQ 0

# Informix Storage Manager variables
ISM_DATA_POOL ISMData
ISM_LOG_POOL ISMLogs

# Read Ahead Variables
RA_PAGES 48 # Number of pages to attempt to read ahead
RA_THRESHOLD 16 # Number of pages left before next group

# DBSPACETEMP:
# OnLine equivalent of DBTEMP for SE. This is the list of dbspaces
# that the OnLine SQL Engine will use to create temp tables etc.
# If specified it must be a colon separated list of dbspaces that exist
# when the OnLine system is brought online. If not specified, or if
# all dbspaces specified are invalid, various ad hoc queries will create
# temporary files in /tmp instead.

DBSPACETEMP tmpdbs # Default temp dbspaces

# DUMP*:
# The following parameters control the type of diagnostics information which
# is preserved when an unanticipated error condition (assertion failure) occurs
# during OnLine operations.
# For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.

DUMPDIR /tmp # Preserve diagnostics in this directory
DUMPSHMEM 0 # Dump a copy of shared memory
DUMPGCORE 0 # Dump a core image using 'gcore'
DUMPCORE 0 # Dump a core image (Warning:this aborts OnLine)
DUMPCNT 0 # Number of shared memory or gcore dumps for
# a single user's session

FILLFACTOR 90 # Fill factor for building indexes

# method for OnLine to use when determining current time
USEOSTIME 0 # 0: use internal time(fast), 1: get time from OS(slow)

# Parallel Database Queries (pdq)
MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
DS_MAX_QUERIES 8 # Maximum number of decision support queries
DS_TOTAL_MEMORY 8192 # Decision support memory (Kbytes)
DS_MAX_SCANS 1048576 # Maximum number of decision support scans
DATASKIP off # List of dbspaces to skip

# OPTCOMPIND
# 0 => Nested loop joins will be preferred (where
# possible) over sortmerge joins and hash joins.
# 1 => If the transaction isolation mode is not
# "repeatable read", optimizer behaves as in (2)
# below. Otherwise it behaves as in (0) above.
# 2 => Use costs regardless of the transaction isolation
# mode. Nested loop joins are not necessarily
# preferred. Optimizer bases its decision purely
# on costs.
OPTCOMPIND 0 # To hint the optimizer

DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or OFF (0)

ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT
OPCACHEMAX 131072 # Maximum optical cache size (Kbytes)

# HETERO_COMMIT (Gateway participation in distributed transactions)
# 1 => Heterogeneous Commit is enabled
# 0 (or any other value) => Heterogeneous Commit is disabled
HETERO_COMMIT 0

SBSPACENAME # Default smartblob space name - this is where blobs
# go if no sbspace is specified when the smartblob is
# created. It is also used by some datablades as
# the location to put their smartblobs.
SYSSBSPACENAME # Default smartblob space for use by the Informix
# Server. This is used primarily for Informix Server
# system statistics collection.

BLOCKTIMEOUT 3600 # Default timeout for system block
SYSALARMPROGRAM /home/informix/etc/evidence.sh # System Alarm program path

# Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
OPT_GOAL -1

ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or anything but 1)


$ onstat -d

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 01:47:46 -- 819044
Kbytes

Dbspaces
address number flags fchunk nchunks flags owner name
c00000003011ce58 1 0x1 1 1 N informix rootdbs
c00000003028b980 2 0x2001 2 1 N T informix tmpdbs
c00000003028baf8 3 0x1 3 2 N informix phlog
c00000003028bc70 4 0x1 5 2 N informix llog
c00000003028bde8 5 0x1 7 2 N informix datadbs
c000000031043028 6 0x1 9 2 N informix inddbs
6 active, 2047 maximum

Chunks
address chk/dbs offset size free bpages flags pathname
c00000003011d028 1 1 0 25600 23623 PO- /dev/vginf/rlvol1
c00000003011db48 2 2 0 1040384 1040331 PO- /dev/vgtemp/rlvol1
c00000003011dcd0 3 3 0 1040384 331 PO- /dev/vgphlog/rlvol1
c00000003011de58 4 3 0 1040384 1040381 PO- /dev/vgphlog/rlvol2
c00000003028b050 5 4 0 1040384 528331 PO- /dev/vglog/rlvol1
c00000003028b1d8 6 4 0 1040384 1040381 PO- /dev/vglog/rlvol2
c00000003028b360 7 5 0 1040384 978881 PO- /dev/vgdata/rlvol1
c00000003028b4e8 8 5 0 1040384 1040381 PO- /dev/vgdata/rlvol2
c00000003028b670 9 6 0 1040384 1034691 PO- /dev/vgind/rlvol1
c00000003028b7f8 10 6 0 1040384 1040381 PO- /dev/vgind/rlvol2
10 active, 2047 maximum


В своп не чего не валиться
root@ #vmstat -S 2 1000
procs memory page
faults cpu
r b w avm free si so pi po fr de sr in
sy cs us sy id
1 0 0 17154 200948 0 0 0 0 2 0 0 303
1610 647 94 2 4
1 0 0 17154 200897 0 0 0 0 0 0 0 0
271 179 100 0 0
1 0 0 17154 200897 0 0 0 0 0 0 0 0
235 171 100 0 0
1 0 0 16665 200897 0 0 0 0 0 0 0 0
230 177 100 0 0
1 0 0 16665 200897 0 0 0 0 0 0 0 0
248 179 100 0 0
1 0 0 16594 200897 0 0 0 0 0 0 0 0
222 173 100 0 0
1 0 0 16594 200897 0 0 0 0 0 0 0 0
226 176 100 0 0
1 0 0 16594 200897 0 0 0 0 0 0 0 0
216 175 100 0 0
1 0 0 16840 200897 0 0 0 0 0 0 0 0
208 173 99 1 0

$ onstat -g seg

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 19:57:05 -- 819044
Kbytes

Segment Summary:
id key addr size ovhd class blkused bl
kfree
39003 1381386241 c0000000002d5000 801927168 448280 R* 195756 27

4 1381386242 c00000002ff9c000 25600000 1416 V 5784 46
6
5 1381386243 c000000031806000 688128 656 M 135 33

6 1381386244 c0000000318e9000 10485760 952 V 259 23
01
Total: - - 838701056 - - 201934 28
27

(* segment locked in memory)


$ onstat -p

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 19:59:20 -- 8190
Kbytes

Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
13184 13232 8529678498 100.00 929037 1078114 15098176 93.85

isamtot open start read write rewrite delete commit rollbk
7738614797 30697108 12395172 7598512074 2100386 20 358 2100052 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 67943.48 1647.70 15 342

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
6137 974 7652111497 0 0 101 739997 34

ixda-RA idx-RA da-RA RA-pgsused lchwaits
8 0 0 8 598063

$ onstat -g iof

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 20:02:54 -- 819044
Kbytes

AIO global files:
gfd pathname totalops dskread dskwrite io/s
3 rlvol1 1429 24 1405 0.0
4 rlvol1 3 1 2 0.0
5 rlvol1 287 3 284 0.0
6 rlvol2 1 1 0 0.0
7 rlvol1 786193 4 786189 10.9
8 rlvol2 1 1 0 0.0
9 rlvol1 21591 13137 8454 0.3
10 rlvol2 1 1 0 0.0
11 rlvol1 2201 9 2192 0.0
12 rlvol2 1 1 0 0.0
$ onstat -F

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 20:04:12 -- 819044
Kbytes


Fg Writes LRU Writes Chunk Writes
0 0 141161

address flusher state data
c00000003024a848 0 I 0 = 0X0
c00000003024b068 1 I 0 = 0X0
c00000003024b888 2 I 0 = 0X0
c00000003024c0a8 3 I 0 = 0X0
c00000003024c8c8 4 I 0 = 0X0
c00000003024d0e8 5 I 0 = 0X0
c00000003024d908 6 I 0 = 0X0
c00000003024e128 7 I 0 = 0X0
c00000003024e948 8 I 0 = 0X0
c00000003024f168 9 I 0 = 0X0
states: Exit Idle Chunk Lru

$ onstat -R

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 20:04:26 -- 81904
Kbytes

10 buffer LRU queue pairs priority levels
# f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
0 f 35000 97.9% 34255 28272 5933 50 0
1 m 2.1% 745 0 745 0 0
2 f 35000 97.9% 34263 28326 5879 54 4
3 m 2.1% 737 0 737 0 0
4 f 35000 97.8% 34221 28223 5926 69 3
5 m 2.2% 779 0 779 0 0
6 f 35000 98.1% 34321 28482 5781 56 2
7 m 1.9% 679 0 679 0 0
8 f 35000 97.8% 34218 28220 5947 48 3
9 m 2.2% 782 0 782 0 0
10 f 35000 97.8% 34229 28363 5818 47 1
11 m 2.2% 771 0 771 0 0
12 f 35000 97.9% 34264 28345 5864 55 0
13 m 2.1% 736 0 736 0 0
14 f 35000 97.7% 34184 28269 5867 45 3
15 m 2.3% 816 0 816 0 0
16 f 35000 97.9% 34279 28409 5814 55 1
17 m 2.1% 721 0 721 0 0
18 F 34999 97.9% 34264 28345 5860 58 1
19 m 2.1% 735 0 735 0 0
7501 dirty, 349999 queued, 350000 total, 524288 hash buckets, 2048 buffer size
start clean at 60% (of pair total) dirty, or 21000 buffs dirty, stop at 50%
0 priority downgrades, 0 priority upgrades
$ onstat -u

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 20:05:14 -- 81904
Kbytes

Userthreads
address flags sessid user tty wait tout locks
nreads nwrites
c00000003024a028 ---P--D 1 informix - 0 0 0
32 1339
c00000003024a848 ---P--F 0 informix - 0 0 0
0 104536
c00000003024b068 ---P--F 0 informix - 0 0 0
0 32572
c00000003024b888 ---P--F 0 informix - 0 0 0
0 4053
c00000003024c0a8 ---P--F 0 informix - 0 0 0
0 0
c00000003024c8c8 ---P--F 0 informix - 0 0 0
0 0
c00000003024d0e8 ---P--F 0 informix - 0 0 0
0 0
c00000003024d908 ---P--F 0 informix - 0 0 0
0 0
c00000003024e128 ---P--F 0 informix - 0 0 0
0 0
c00000003024e948 ---P--F 0 informix - 0 0 0
0 0
c00000003024f168 ---P--F 0 informix - 0 0 0
0 0
c00000003024f988 ---P--- 9 informix - 0 0 0
0 0
c0000000302501a8 ---P--B 10 informix - 0 0 0
0 0
c0000000302509c8 ---P--- 58 informix M1 0 0 1
0 40590
c0000000302511e8 ---P--- 54 informix M1 0 0 1
0 41485
c000000030251a08 ---P--D 13 informix - 0 0 0
0 0
c000000030252228 ---P--- 60 informix M1 0 0 1
1 40063
c000000030252a48 ---P--- 50 informix M1 0 0 1
0 41342
c000000030253268 ---P--- 59 informix M1 0 0 1
0 40872
c000000030253a88 ---P--- 30 informix M1 0 0 1
0 95819
c0000000302542a8 ---P--- 57 informix M1 0 0 1
0 40873
c000000030254ac8 ---P--- 55 informix M1 0 0 1
1 41327
c0000000302552e8 ---P--- 56 informix M1 0 0 1
0 41516
c000000030255b08 ---P--- 53 informix M1 0 0 1
0 40868
24 active, 128 total, 26 maximum concurrent

$ onstat -l

Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up 20:17:24 -- 819044
Kbytes

Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-2 0 128 35273 284 124.20
phybegin physize phypos phyused %used
300035 1040000 914165 0 0.00

Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-2 0 8 18776859 901362 787558 20.8 1.1
Subsystem numrecs Log Space used
OLDRSAM 18776859 1054528620

address number flags uniqid begin size used %used
c00000003011d288 1 U-B---- 747 10016b 100 100 100.00
c00000003011d2d8 2 U-B---- 748 1001cf 100 100 100.00
c00000003011d328 3 U-B---- 749 100233 100 100 100.00
c00000003011d378 4 U-B---- 750 10047b 100 100 100.00
c00000003011d3c8 5 U-B---- 751 10051f 100 100 100.00
c00000003011d418 6 U-B---- 752 1005d3 100 100 100.00
c00000003011d468 7 U-B---- 753 100a0a 100 100 100.00
c00000003011d4b8 8 U-B---- 754 100a6e 100 100 100.00
c00000003011d508 9 U-B---- 755 500035 25600 25600 100.00
c00000003011d558 10 U-B---- 756 506435 25600 25600 100.00
c00000003011d5a8 11 U-B---- 757 50c835 25600 25600 100.00
c00000003011d5f8 12 U-B---- 758 512c35 25600 25600 100.00
c00000003011d648 13 U-B---- 759 519035 25600 25600 100.00
c00000003011d698 14 U-B---- 760 51f435 25600 25600 100.00
c00000003011d6e8 15 U-B---- 761 525835 25600 25600 100.00
c00000003011d738 16 U-B---- 762 52bc35 25600 25600 100.00
c00000003011d788 17 U-B---- 763 532035 25600 25600 100.00
c00000003011d7d8 18 U---C-L 764 538435 25600 9414 36.77
c00000003011d828 19 U-B---- 737 53e835 25600 25600 100.00
c00000003011d878 20 U-B---- 738 544c35 25600 25600 100.00
c00000003011d8c8 21 U-B---- 739 54b035 25600 25600 100.00
c00000003011d918 22 U-B---- 740 551435 25600 25600 100.00
c00000003011d968 23 U-B---- 741 557835 25600 25600 100.00
c00000003011d9b8 24 U-B---- 742 55dc35 25600 25600 100.00
c00000003011da08 25 U-B---- 743 564035 25600 25600 100.00
c00000003011da58 26 U-B---- 744 56a435 25600 25600 100.00
c00000003011daa8 27 U-B---- 745 570835 25600 25600 100.00
c00000003011daf8 28 U-B---- 746 576c35 25600 25600 100.00
28 active, 28 total
...
Рейтинг: 0 / 0
Переход с MS SQL на INFORMIX под HP-PA-RISC
    #32245024
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. Рекомендую увеличить SHMVIRTSIZE до таких размеров, чтобы onstat -g seg
не рапортовал о еще одном добавленном сегменте. В более старых версиях на HP-UX-e были серьезные проблемы с производительностью именно из большого количества сегментов. В особенности, если учесть, что и во втором добавленном сегменте памяти осталось совсем не много. В общем, хотя бы раза в два, а то и больше.
Если с памятью получатся напряги, то можно немного (до 300000) уменьшить BUFFERS.

2. Так и не понятно, KAIO включили или нет?
В связи с этим NUMAIOVPS - пусто, несколько не понятен.

3. Дай также onstat -g glo и onstat -g ioq.
...
Рейтинг: 0 / 0
33 сообщений из 33, показаны все 2 страниц
Форумы / Informix [игнор отключен] [закрыт для гостей] / Переход с MS SQL на INFORMIX под HP-PA-RISC
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]