Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Недавно заказчик захотел перейти с 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 на указанном железе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 08:14 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Бери четырех процессорный UNIX и не ошибешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 12:23 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
и двух камней за глаза ... под энтей четыре камня все равно только электричество жрали :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2003, 16:16 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Исходя из типичных задач составили тест, эмулирующий типичную нагрузку на СУБД в Системе (похожа на нагрузку в типичных 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 может помочь в его оптимизации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 09:25 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Берите SUN ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 12:11 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Вообще то вы явно что то не то там оптимизировали. К тому же при вашей трехзвенной архитектуре проблема может быть вообще не в информиксе. Начинайте тестировать с самого сервера, напишите прогу на esqlc. По платформе вашей подсказать ничего не могу тк сам работаю с SUN и INTEL. Начните с того что оцените загрузку сервака onstat-ом например, может он у вас спит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 12:19 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
SUN взять не можем, т.к. HP и INFORMIX - требования заказчика, которые менятся не могут. Потом, я думаю, что HP явно не хуже SUN'а будет. Тест написан не на Сервере приложений, а как отдельное приложение, которое напрямую работает с БД через OLE DB. Мы то тестируем БД, а не все остальное. Так что в данном случае теституруется только СУБД и ничего больше. onstat-ом пользуемся, естественно, не спит :). Из всей оптимизации осталось только разнести log, таблицы, индексы, временные файлы, сам сервер на разные space'ы на разных дисках. Возьмем 5 дисков, разнесем, попробуем, должно хоть что -то улучшиться. Какие могут быть еще советы по оптимизации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 13:48 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
надо анализировать что именно делает информих 1 вы ожидаете эффекта от разделения данных по разным устройствам на основании чего? просто так или есть основания. У меня довольно приличные БД по многу гиг лежат на одном диске и я не замечаю проблем. 2 сколько памяти у вас использует информикс? сколько блокировок стоит в конфигурации? сколько буферов? 3 сколько экстентов в больших таблицах? 4 наконец статистику собирали? 5 надо анализировать по профайлу характер загрузки onstat -i затем rz затем -p с периодом 5 сек будет обновляться профайл . 6 надо анализировать планы запросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2003, 16:07 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Привет !!! >>надо анализировать что именно делает информих >> >>1 вы ожидаете эффекта от разделения данных по разным устройствам на основании чего? >>просто так или есть основания. У меня довольно приличные БД по многу гиг лежат на одном диске и я не замечаю проблем. На основании того что обращения к разным дискам будет про исходить на много быстрее чем к одному. Хотя в этом случаи желательно чтоб эти диски были на разных контролерах. >>2 сколько памяти у вас использует информикс? сколько блокировок стоит в >>конфигурации? сколько буферов? использует памяти 250 М блокировок 2000 буферов стоит 15000 >>3 сколько экстентов в больших таблицах? можно пояснить этот термин и если это устанавливается в настройках инфрмикса пояснить где? >>4 наконец статистику собирали? да после каждого теста я делаю onstat -a и анализирую данные вроде все было в порядке . >>5 надо анализировать по профайлу характер загрузки >>onstat -i >>затем rz >>затем -p >>с периодом 5 сек будет обновляться профайл . >> >> >>6 надо анализировать планы запросов Буду очень благодарен если вы объясните как это сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 09:45 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
OLEDB для информикса как юзаете? НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙТЕ IBM INFORMIX OLE DB PROVIDER - жутко тормозной Используйте MS OLE Db Provider for ODBC и ODBC поновее, еще лучше ODBC или напрямую esqlc. На чем написан сервер приложений? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 11:19 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Код: plaintext sun отстой, в 2 раза больше процессоров понадобится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 11:23 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Лучше добиваться кеширования 99.99%, тогда будет пофиг сколько дисков. Но если активный размер базы много больше чем размер ОЗУ, тогда надо разносить нагрузку на диски фрагментацией информикса, или еще лучше соединить диски в страйп, раид контроллером, и добится максимума производительности минимумом усилий. Код: plaintext 1. 2. 3. 4. Ужас. Информикс использует столько памяти сколько сказано в онконфиге, вам надо максимум озу отдать под буферизацию. Рамер буфера у вас очевидно 2 кб. onconfig в студию. поправим. Код: plaintext 1. 2. Экстент это количество кусочков на которое разбилась таблица в тейблспесе стремитесь к единице. Задается так: 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. статистика собирается sql запросом update statistics ... - это сбор распределений значений для постороения планов оптимизатором. хотя бы раз в день выполняйте к примеру update statistics high, или после массовых изменений таблиц(ы) выполняйте update statistics high for table MYTABLENAME Код: plaintext 1. 2. 3. 4. 5. onstat -p показывает основные характеристики очень важен уровень кеширования Код: plaintext 1. ушло мылом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 11:40 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
>>Лучше добиваться кеширования 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) >>ушло мылом Спасибо большое за мыло:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 12:24 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
HP отстой SUN рулез процессоров потребуется в два раза меньше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 12:38 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Начнем помаленьку: Код: plaintext 1. 2. 3. 4. /dev/vg00/online_roots - Это чего файл? Или устройство? если это raw device то ROOTOFFSET должен быть минимум 4, иначе все навернется. ROOTSIZE 1048576 Нафига большой такой? Чего туда сложили? Метров 300 хватит за глаза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 12:44 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
>>/dev/vg00/online_roots - Это чего файл? Или устройство? если это raw device то ROOTOFFSET должен быть минимум 4, иначе все навернется. Это отдельное устройство. >>ROOTSIZE 1048576 >> >>Нафига большой такой? Чего туда сложили? Метров 300 хватит за глаза. Дело в том что при создании отдельный спейсов под физический и логический лог не было и он не давал создать меньше 600М Хотя теперь можно сократить это т размер чуть ли не в 10 раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 12:58 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. В каком смысле отдельное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 13:31 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. Для реальной работы наверно мало, я бы сделал 10 по 100 мегов. Код: plaintext Собирает статистику обращений к таблице (кол-во insert,update, ....) TBLSPACE_STATS 0 - при реальной работе и замере производительности. Код: plaintext 1. LOCKS 100000 - размер лока 44 байта. BUFFERS 350000 - при буфере 2кб = 700 мб Код: plaintext Я не курсе про hp-ux KAIO там можно использовать? Код: plaintext 1. SHMADD больше SHMVIRTSIZE - забавно :) SHMVIRTSIZE 131072 SHMADD 10240 Код: plaintext 1. Упреждающее чтение, вещь нужная RA_PAGES 48 RA_THRESHOLD 16 Код: plaintext 1. DUMPSHMEM 0 - врядли кто-то сможет понять содержимое дампа кроме IBM Код: plaintext Иногда для OLTP систем лучше выставить 0, в этом случае индексы юзаются активней, меньше дискового чтения. Код: plaintext ONDBSPACEDOWN 0 Поменяйте онконфиг, перестартуйте информикс, прогоните тест, и киньте сюда onstat -p onstat -g iof onstat -m (лучше кусок /opt/informix/online.log) onstat -g seg onstat -F onstat -R onstat -u onstat -l ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 13:53 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
После всех изменений вот что получилось 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 15:08 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Очень маленький размер журналов, слишком часто они кончаются. С помощью onspaces создайте еще один спейс на 1 гиг С помощью onparams в нем создайте 10 лог. журналов по 100мгб SHMVIRTSIZE 25000 CLEANERS 10 LRUS 10 Используйте raw device. покажи onstat -g ioq Я уже спрашивал, но все же, На чем написан сервер приложений, и какой способ доступа к информиксу используется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 16:05 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
>>Очень маленький размер журналов, слишком часто они кончаются. >>С помощью 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 17:26 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Хех, медленнее в 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 уже базируется на знании приложения, пусть даже и тестового, так что пальцем в небо тыкать не хочется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2003, 19:02 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Привет! >>Обязательно включить 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 11:20 |
|
||
|
Переход с MS SQL на INFORMIX под HP-PA-RISC
|
|||
|---|---|---|---|
|
#18+
Я бы тест видоизменил. То что исполняется max раз, я бы запускал вперемешку, по рандому, и в 100 коннектах, вот тогда это стала бы реальная симуляция работы нескольких пользователей. Иначе информикс будет проигрывать MSSQL причем я считаю по двум причинам: 1. Informix OLE DB Provider - отстой (офигительно тормознутый и к тому же основательно грузит процессор клиента при конвертации данных). 2. MS SQL кеширует планы выполнения SQL запросов, Informix нет (такая возможность есть (STMT_CACHE), но это глюк сплошной). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2003, 12:29 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=32236421&tid=1609384]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
62ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 257ms |
| total: | 407ms |

| 0 / 0 |
