Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
...Раз пошла такая пьянка , то может кто подскажет... хотелось бы уменьшить время чекпойнтов 10:05:36 Checkpoint Completed: duration was 5 seconds. 10:10:42 Checkpoint Completed: duration was 5 seconds. 10:15:47 Checkpoint Completed: duration was 6 seconds. 10:20:53 Checkpoint Completed: duration was 5 seconds. 10:26:01 Checkpoint Completed: duration was 8 seconds. 10:31:08 Checkpoint Completed: duration was 8 seconds. 10:36:26 Checkpoint Completed: duration was 17 seconds. 10:41:37 Checkpoint Completed: duration was 11 seconds. 10:46:42 Checkpoint Completed: duration was 5 seconds. 10:51:55 Checkpoint Completed: duration was 13 seconds. 10:57:12 Checkpoint Completed: duration was 17 seconds. 11:02:16 Checkpoint Completed: duration was 4 seconds. 11:07:22 Checkpoint Completed: duration was 7 seconds. 11:12:32 Checkpoint Completed: duration was 9 seconds. 11:17:38 Checkpoint Completed: duration was 6 seconds. 11:22:42 Checkpoint Completed: duration was 4 seconds. 11:27:51 Checkpoint Completed: duration was 9 seconds. 11:33:00 Checkpoint Completed: duration was 9 seconds. 11:38:11 Checkpoint Completed: duration was 11 seconds. 11:43:21 Checkpoint Completed: duration was 10 seconds. 11:48:30 Checkpoint Completed: duration was 9 seconds. 11:53:45 Checkpoint Completed: duration was 15 seconds. 11:58:54 Checkpoint Completed: duration was 9 seconds. 12:04:00 Checkpoint Completed: duration was 6 seconds. 12:09:06 Checkpoint Completed: duration was 6 seconds. 12:14:15 Checkpoint Completed: duration was 9 seconds. 12:19:20 Checkpoint Completed: duration was 5 seconds. 12:24:29 Checkpoint Completed: duration was 9 seconds. 12:29:23 Checkpoint Completed: duration was 12 seconds. 12:29:25 Checkpoint Completed: duration was 1 seconds. 12:29:26 Checkpoint Completed: duration was 1 seconds. 12:29:27 Checkpoint Completed: duration was 1 seconds. 12:30:03 Checkpoint Completed: duration was 10 seconds. 12:30:05 Checkpoint Completed: duration was 1 seconds. 12:30:06 Checkpoint Completed: duration was 1 seconds. 12:30:07 Checkpoint Completed: duration was 1 seconds. 12:30:08 Checkpoint Completed: duration was 1 seconds. 12:35:31 Checkpoint Completed: duration was 12 seconds. 12:40:40 Checkpoint Completed: duration was 9 seconds. 12:45:49 Checkpoint Completed: duration was 9 seconds. 12:51:00 Checkpoint Completed: duration was 11 seconds. 12:56:14 Checkpoint Completed: duration was 14 seconds. 12:57:55 Checkpoint Completed: duration was 7 seconds. вот конфигурация #************************************************************* # # INFORMIX SOFTWARE, INC. # # Title: onconfig.std # Description: Informix Dynamic Server Configuration Parameters # #************************************************************* # Root Dbspace Configuration ROOTNAME rootdbs # Root dbspace name ROOTPATH /dev/md/rdsk/d50 # Path for device containing root dbspace ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) ROOTSIZE 2097150 # Size of root dbspace (Kbytes) # Disk Mirroring Configuration Parameters MIRROR 1 # Mirroring flag (Yes = 1, No = 0) MIRRORPATH /dev/md/rdsk/d84 # Path for device containing mirrored root MIRROROFFSET 0 # Offset into mirrored device (Kbytes) # Physical Log Configuration PHYSDBS rootdbs # Location (dbspace) of physical log PHYSFILE 10000 # Physical log file size (Kbytes) # Logical Log Configuration LOGFILES 60 # Number of logical log files LOGSIZE 2000 # 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 SYSALARMPROGRAM /opt/informix/etc/evidence.sh # System Alarm program path TBLSPACE_STATS 1 # System Archive Tape Device TAPEDEV /dev/rmt/0 # Tape device path TAPEDEV /dev/rmt/0 # Tape device path #TAPEDEV /dev/null TAPEBLK 4096 # Tape block size (Kbytes) TAPESIZE 51000000 # Maximum amount of data to put on tape (Kbytes) # Log Archive Tape Device LTAPEDEV /dev/null # Log tape device path LTAPEBLK 4096 # Log tape block size (Kbytes) LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes) # Optical STAGEBLOB # Informix Dynamic Server/Optical staging area # System Configuration SERVERNUM 0 # Unique id corresponding to a Dynamic Server instance DBSERVERNAME sf880on # Name of default database server DBSERVERALIASES fast0spx,sf880tli # List of alternate dbservernames NETTYPE ipcshm,2,100,CPU # Configure poll thread(s) for nettype #NETTYPE tlispx,5,10,NET # Configure poll thread(s) for nettype NETTYPE tlitcp,1,10,NET # Configure poll thread(s) for nettype DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. RESIDENT 1 # Forced residency flag (Yes = 1, No = 0) MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor NUMCPUVPS 4 # 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 4 # Affinity number of processors # Shared Memory Parameters LOCKS 3000000 # Maximum number of locks BUFFERS 700000 # Maximum number of shared buffers NUMAIOVPS # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes) LOGSMAX 60 # Maximum number of logical log files CLEANERS 8 # Number of buffer cleaner processes SHMBASE 0x10A000000L # Shared memory base address SHMVIRTSIZE 8000 # initial virtual shared memory segment size SHMADD 8192 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 300 # Check point interval (in sec) LRUS 8 # Number of LRU queues LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit LTXHWM 50 # Long transaction high water mark percentage LTXEHWM 60 # Long transaction high water mark (exclusive) TXTIMEOUT 300 # Transaction timeout (in sec) STACKSIZE 256 # Stack size (Kbytes) # System Page Size # BUFFSIZE - Dynamic Server no longer supports this configuration parameter. # To determine the page size used by Dynamic Server 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 10 # Default number of offline worker threads ON_RECVRY_THREADS 1 # Default number of online worker threads # Data Replication Variables # DRAUTO: 0 manual, 1 retain type, 2 reverse type DRAUTO 0 # DR automatic switchover DRINTERVAL -1 # 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_LOGBUFFERS 2048 # size of log reading buffer pool (Kbytes) 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_LOGDELTA 30 # % of log space allowed in queue memory CDR_NUMCONNECT 16 # Expected connections per server CDR_NIFRETRY 300 # Connection retry (seconds) CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0 none, 9 max) # Backup/Restore variables BAR_ACT_LOG /tmp/bar_act.log BAR_DEBUG_LOG /usr/informix/bar_dbug.log # ON-Bar Debug Log - not in /tmp pleas BAR_MAX_BACKUP 0 BAR_RETRY 1 BAR_NB_XPORT_COUNT 10 BAR_XFER_BUF_SIZE 31 # Informix Storage Manager variables ISM_DATA_POOL ISMData # If the data pool name is changed, be sure to # update $INFORMIXDIR/bin/onbar. Change to # ism_catalog -create_bootstrap -pool <new name> ISM_LOG_POOL ISMLogs # Read Ahead Variables RA_PAGES # Number of pages to attempt to read ahead RA_THRESHOLD # Number of pages left before next group # DBSPACETEMP: # Dynamic Server equivalent of DBTEMP for SE. This is the list of dbspaces # that the Dynamic Server SQL Engine will use to create temp tables etc. # If specified it must be a colon separated list of dbspaces that exist # when the Dynamic Server 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 tempdbs # 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 Dynamic Server 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 Dynamic Server) DUMPCNT 1 # Number of shared memory or gcore dumps for # a single user's session FILLFACTOR 90 # Fill factor for building indexes # method for Dynamic Server 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 # Maximum number of decision support queries DS_TOTAL_MEMORY # 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 ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT LBU_PRESERVE 0 # Preserve last log for log backup OPCACHEMAX 0 # 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 # Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS OPT_GOAL -1 # Optimizer DIRECTIVES ON (1/Default) or OFF (0) DIRECTIVES 1 # Status of restartable restore RESTARTABLE_RESTORE off ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 15:29 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
солярис 8 4 процессора приложение oltp Ввод документов осуществляется вручную довольно плотно и внезапные тормоза неприятны. юзеры не то чтобы возмущаются особо, но все равно лучше бы снизить по возможности. bash-2.03$ onstat -d|more Informix Dynamic Server Version 7.31.FD6 -- On-Line (Prim) -- Up 1 days 21:59:53 -- 2291712 Kbytes Dbspaces address number flags fchunk nchunks flags owner name 17607a1c0 1 1002 1 1 M informix rootdbs 177a0a028 2 2001 2 1 N T informix tempdbs 177a0a110 3 2 3 8 M informix maindbs 177a0a1f8 4 2 11 7 M informix logdbs 177a0a2e0 5 2 18 17 M informix docdbs 5 active, 2047 maximum Chunks address chk/dbs offset size free bpages flags pathname 17607a2a8 1 1 0 1048575 923314 PO- /dev/md/rdsk/d50 17607a3c0 1 1 0 1048575 0 MO- /dev/md/rdsk/d84 17607aa98 2 2 0 1048575 1021234 PO- /dev/md/rdsk/d51 17607abb0 3 3 0 1048575 13 PO- /dev/md/rdsk/d52 1760c3c50 3 3 0 1048575 0 MO- /dev/md/rdsk/d86 17607acc8 4 3 0 1048575 2 PO- /dev/md/rdsk/d53 1760c3d68 4 3 0 1048575 0 MO- /dev/md/rdsk/d87 17607ade0 5 3 0 1048575 2 PO- /dev/md/rdsk/d54 1760c3e80 5 3 0 1048575 0 MO- /dev/md/rdsk/d88 17607aef8 6 3 0 1048575 36149 PO- /dev/md/rdsk/d55 1770fe028 6 3 0 1048575 0 MO- /dev/md/rdsk/d89 17607b010 7 3 0 1048575 524524 PO- /dev/md/rdsk/d56 1770fe140 7 3 0 1048575 0 MO- /dev/md/rdsk/d90 17607b128 8 3 0 1048575 458591 PO- /dev/md/rdsk/d57 1770fe258 8 3 0 1048575 0 MO- /dev/md/rdsk/d91 17607b240 9 3 0 1048575 533569 PO- /dev/md/rdsk/d58 1770fe370 9 3 0 1048575 0 MO- /dev/md/rdsk/d92 17607b358 10 3 0 1048575 1048572 PO- /dev/md/rdsk/d59 1770fe488 10 3 0 1048575 0 MO- /dev/md/rdsk/d93 17607b470 11 4 0 1048575 56 PO- /dev/md/rdsk/d60 1770fe5a0 11 4 0 1048575 0 MO- /dev/md/rdsk/d94 17607b588 12 4 0 1048575 13 PO- /dev/md/rdsk/d61 1770fe6b8 12 4 0 1048575 0 MO- /dev/md/rdsk/d95 17607b6a0 13 4 0 1048575 226 PO- /dev/md/rdsk/d62 1770fe7d0 13 4 0 1048575 0 MO- /dev/md/rdsk/d96 17607b7b8 14 4 0 1048575 590858 PO- /dev/md/rdsk/d63 1770fe8e8 14 4 0 1048575 0 MO- /dev/md/rdsk/d97 17607b8d0 15 4 0 1048575 1047920 PO- /dev/md/rdsk/d64 1770fea00 15 4 0 1048575 0 MO- /dev/md/rdsk/d98 17607b9e8 16 4 0 1048575 1048572 PO- /dev/md/rdsk/d65 1770feb18 16 4 0 1048575 0 MO- /dev/md/rdsk/d99 17607bb00 17 4 0 524287 523696 PO- /dev/md/rdsk/d66 1770fec30 17 4 0 524287 0 MO- /dev/md/rdsk/d100 17607bc18 18 5 0 1048575 48522 PO- /dev/md/rdsk/d67 1770fed48 18 5 0 1048575 0 MO- /dev/md/rdsk/d101 17607bd30 19 5 0 1048575 0 PO- /dev/md/rdsk/d68 1770fee60 19 5 0 1048575 0 MO- /dev/md/rdsk/d102 17607be48 20 5 0 1048575 48572 PO- /dev/md/rdsk/d69 1770fef78 20 5 0 1048575 0 MO- /dev/md/rdsk/d103 1760b3050 21 5 0 1048575 48572 PO- /dev/md/rdsk/d70 1770ff090 21 5 0 1048575 0 MO- /dev/md/rdsk/d104 1760b3168 22 5 0 1048575 48572 PO- /dev/md/rdsk/d71 1770ff1a8 22 5 0 1048575 0 MO- /dev/md/rdsk/d105 1760b3280 23 5 0 1048575 48572 PO- /dev/md/rdsk/d72 1770ff2c0 23 5 0 1048575 0 MO- /dev/md/rdsk/d106 1760b3398 24 5 0 1048575 48572 PO- /dev/md/rdsk/d73 1770ff3d8 24 5 0 1048575 0 MO- /dev/md/rdsk/d107 1760b34b0 25 5 0 1048575 48572 PO- /dev/md/rdsk/d74 1770ff4f0 25 5 0 1048575 0 MO- /dev/md/rdsk/d108 1760b35c8 26 5 0 1048575 848572 PO- /dev/md/rdsk/d75 1770ff608 26 5 0 1048575 0 MO- /dev/md/rdsk/d109 1760b36e0 27 5 0 1048575 1048572 PO- /dev/md/rdsk/d76 1770ff720 27 5 0 1048575 0 MO- /dev/md/rdsk/d110 1760b37f8 28 5 0 1048575 1048572 PO- /dev/md/rdsk/d77 1770ff838 28 5 0 1048575 0 MO- /dev/md/rdsk/d111 1760b3910 29 5 0 1048575 1048572 PO- /dev/md/rdsk/d78 1770ff950 29 5 0 1048575 0 MO- /dev/md/rdsk/d112 1760b3a28 30 5 0 1048575 1048572 PO- /dev/md/rdsk/d79 1770ffa68 30 5 0 1048575 0 MO- /dev/md/rdsk/d113 1760b3b40 31 5 0 1048575 1048572 PO- /dev/md/rdsk/d80 1770ffb80 31 5 0 1048575 0 MO- /dev/md/rdsk/d114 1760b3c58 32 5 0 1048575 1048572 PO- /dev/md/rdsk/d81 1770ffc98 32 5 0 1048575 0 MO- /dev/md/rdsk/d115 1760b3d70 33 5 0 1048575 1048572 PO- /dev/md/rdsk/d82 1770ffdb0 33 5 0 1048575 0 MO- /dev/md/rdsk/d116 1760b3e88 34 5 0 524287 524284 PO- /dev/md/rdsk/d83 1770ffec8 34 5 0 524287 0 MO- /dev/md/rdsk/d117 34 active, 2047 maximum ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 15:34 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
bash-2.03$ onstat -F статистика за ~30 min характерного режима Informix Dynamic Server Version 7.31.FD6 -- On-Line (Prim) -- Up 1 days 22:10:37 -- 2291712 Kbytes Fg Writes LRU Writes Chunk Writes 0 0 14073 address flusher state data 17607c708 0 I 0 = 0X0 17607cde8 1 I 0 = 0X0 17607d4c8 2 I 0 = 0X0 17607dba8 3 I 0 = 0X0 17607e288 4 I 0 = 0X0 17607e968 5 I 0 = 0X0 17607f048 6 I 0 = 0X0 17607f728 7 I 0 = 0X0 states: Exit Idle Chunk Lru 15:09:58 Checkpoint Completed: duration was 7 seconds. 15:15:12 Checkpoint Completed: duration was 14 seconds. 15:20:23 Checkpoint Completed: duration was 10 seconds. 15:25:35 Checkpoint Completed: duration was 12 seconds. 15:30:43 Checkpoint Completed: duration was 8 seconds. 15:35:50 Checkpoint Completed: duration was 7 seconds. 15:40:55 Checkpoint Completed: duration was 5 seconds. это не LRU однозначно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 15:46 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
bash-2.03$ onstat -R Informix Dynamic Server Version 7.31.FD6 -- On-Line (Prim) -- Up 1 days 22:14:51 -- 2291712 Kbytes 8 buffer LRU queue pairs priority levels # f/m pair total % of length LOW MED_LOW MED_HIGH HIGH 0 f 87465 98.8% 86438 26771 55021 4473 173 1 m 1.2% 1026 1 1021 5 0 2 F 87370 99.0% 86471 26740 55410 4139 182 3 m 1.0% 899 0 896 2 0 4 f 87497 98.9% 86566 26676 55545 4168 177 5 m 1.1% 931 0 923 7 0 6 f 87422 98.8% 86410 26693 55162 4369 186 7 m 1.2% 1012 0 1001 11 0 8 f 87383 98.8% 86352 26618 55243 4323 168 9 m 1.2% 1031 0 1022 9 0 10 f 87460 98.8% 86435 26700 55346 4201 188 11 m 1.2% 1025 0 1015 10 0 12 f 87401 98.8% 86376 26653 55331 4212 180 13 m 1.2% 1025 0 1019 6 0 14 f 87386 98.8% 86302 26653 55101 4385 163 15 m 1.2% 1084 0 1070 14 0 8033 dirty, 699383 queued, 700000 total, 1048576 hash buckets, 2048 buffer size start clean at 60% (of pair total) dirty, or 52500 buffs dirty, stop at 50% 0 priority downgrades, 0 priority upgrades ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 15:48 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
>По поводу причины, я думаю, что она одназначно в том, что у тебя слишком >много буфферов, 700000 - это 1.4Гб!!, то, что они достаточно долго >сливаются, с чем не справляются либо диски либо очередей слишком мало. >Т.е. надо мониторить во время чекпоинта onstat -R, onstat -F и т.д Я може чего-то не врубаюсь, но AFAIK сливать ему надо не все 1.4 гига а только измененные страницы. (?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 15:59 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Код: plaintext Да. 8033 dirty - если чекпоинт будет сейчас, значит надо записать ~16 МГб. Я перепутал - хотел onstat -D. Хотя все равно не понятно сколько дисков. В общем смотри чем информикс занимается во время чекпоинта, если он пишет то старайся сбалансировать запись по дискам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 16:41 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Проблема в том что синхронизировать буферы и диск надо :). Вопрос в том когда это делать, во время чекпоинта? или все время? автор Fg Writes LRU Writes Chunk Writes 0 0 14073 15:25:35 Checkpoint Completed: duration was 12 seconds. 15:30:43 Checkpoint Completed: duration was 8 seconds. 15:35:50 Checkpoint Completed: duration was 7 seconds. 15:40:55 Checkpoint Completed: duration was 5 seconds. это не LRU однозначно Да Chunk Writes. Буферы и диск синхронизируются только во время чекпоинта. Это хорошо - это дает максимальную скорость записи между чекпоинтами (пишем в память). Купи более быструю дисковую систему -> время чекпоинта сократится. Или переходи на LRU Writes. Производительность информикса упадет (будет тратится время на синхронизацию буферов и диска), и чекпоинт укоротится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 16:52 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
дисковая система файбер ченал быстрее не бывает млин ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 17:17 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Для полноты картины нужен был бы еще onstat -p и onstat -g iof. onstat -R интересен именно в момент выполнения чекпоинта. Вот этот кусочек новодит на раздумья: 12:29:23 Checkpoint Completed: duration was 12 seconds. 12:29:25 Checkpoint Completed: duration was 1 seconds. 12:29:26 Checkpoint Completed: duration was 1 seconds. 12:29:27 Checkpoint Completed: duration was 1 seconds. 12:30:03 Checkpoint Completed: duration was 10 seconds. 12:30:05 Checkpoint Completed: duration was 1 seconds. 12:30:06 Checkpoint Completed: duration was 1 seconds. 12:30:07 Checkpoint Completed: duration was 1 seconds. 12:30:08 Checkpoint Completed: duration was 1 seconds Если такое (слишком частые чекпоинты) бывает часто, то следует увеличить PHYSFILE. Еще хорошо бы помониторить кто именно вызывает подобные проблемы. Например, создание временных таблиц без WITH NO LOG. По onstat -F действительно видно, что LRU не юзаются, если заставить их работать (путем уменьшения параметров LRU_MAX_DIRTY,LRU_MIN_DIRTY), упадет производительность системы, но зато чекпоинт ускорится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2003, 17:19 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Кстати, то, что производительность упадет при увеличении LRU writes - не факт. Если диск стоит недогружен (мало чтения, в основном inserts) - то производительность между чекпойнтами почти не изменится. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2004, 20:07 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Кстати, при таком количестве буферов (700000) и dirty buffers (~8000) весьма трудно заставить работать LRU, поскольку это порог получается меньше 2%. Поставь LRU_MAX 2, LRU_MIN 1 и или уменьши число буферов, или увеличь физический лог (чекпойнт начинается при заполнении 75% phys log). В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2004, 20:11 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
TBLSPACE_STATS 0 не уменьшил чекпойнты, но (стук по дереву) кажется убрал тормоза при архивации нулевого уровня, впрочем надо еще с месяц покопироваться и будет видно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2004, 22:12 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Подземный стук через "TBLSPACE_STATS 0" к сожалению не лечится :-(. У меня оно отродясь в нулях стоит, тормоза на архиве нуля наблюдаю раз в месяц при еженедельном выполнении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2004, 10:17 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
"TBLSPACE_STATS 0" не ликвидирует тормоза, но похоже уменьшает. У меня тормоза уже возникали раз в 4 дня, теперь видимо реже, но еще не достаточно времени для того чтобы делать окончательные выводы. Уменьшали количество буферов с 700000 до 100000 - эффект нулевой. И вообще есть сильные подозрения на тормоза при записи на винты. Может кто сталкивался - у нас большие винты по 36 гигов разбиты соляровским дисксъютом на мета устройства по 2 гига, тк соляра не позволяет создать более 8и партиций. Сброс чекпойнта производится со скоростью не более 6-и метров в секунду на файбрченал винте, что не правильно совсем. Простое копирование на файловую систему более 20и метров в секунду. каио включено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2004, 14:48 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Кстати, я бы прислушался к совету Выбегалло. "LRU_MAX 2, LRU_MIN 1 ". Кстати, тогда заработают LRU и появится смысл увеличивать их количество. Кроме того, чанков много, а CLENERS-ов всего 8, я бы их тоже увеличил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2004, 15:33 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
а я прислушиваюсь ... токо руки не до всего доходят сразу пока читаю пэйджер типа ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2004, 17:18 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
1. Не понял, про какие тормоза теперь идет речь : при чекпойнте или при архивации нулевого уровня ? Был такой nasty bug который заставлял изменять таймстемп на странице во время архивирования при пол-обороте таймстемпа, но в твоей версии его кажись починили. 2. Если скорость записи при чекпойнте намного меньше скорости прямой записи на диск, то скорей всего Информикс не успевает сортировать буфера в LRU по причине их большой длины. Надо увеличить число LRU и CLEANERов 3. Если есть подозрения на соляровский LVM, то надо сравнивать яблоки с яблоками - создать raw 2GB LV и попытаться писать в него, а не в файловую систему. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2004, 20:33 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Кстати, о длинных архивированиях уровня 0 : http://dbforums.com/t586429.html ---------------- BUG: 101062 ARCHIVE PERFORMANCE DEGRADATION WHEN MANY CALLS TO ARC_VERY_OLD_PAGE() Description: Highly oltp systems that also contain a large amount of static pages, occasional archive performance severly degrades when those pages qualify as very old pages. This is because of a re-read of the pages in the archive buffer from disk to update the Timestamp. in my opinion you have two choices: 1) upgrade to a newer/higher IDS-Version 2) The functionality introduced by the fix to Bug 101062 is not turned on by default. You must enable the new functionality by setting the following ONCONFIG parameter before bringing the engine online. CCFLAGS 0x400000 To verify that the proper CCFLAGS settings are in effect: Using dbaccess, select database 'sysmaster'. Run the following query: select hex(value) from sysshmhdr where name = "ccflags"; This will return: (expression) 0x00400000 -------------- Баг-то починили, но в Onconfig надо вставлять CCFLAGS 0x400000 Чтобы убедиться, что архив тормозит именно по этой причине, рекомендую несколько раз проверить onstat -g stk <ontape thread>. Если нить постоянно торчит в процедуре ARC_VERY_OLD_PAGE - то это именно оно и есть. Первый бэкап после установки CCFLAG - ненадежный, надо сразу сделать второй. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2004, 00:05 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Памятуя количество индусов, по крайней мере в Informix ODBC Team, могу сказать, что баг то починили, но он остался :-(. Я получил сей баг сразу после перехода на 7.3, надеялся, что при переходе 9.2 он уйдет, а фиг Вам. Весьма подробный рассказ на эту тему. Резюме: 1. Upgrade до 9.21.UC7 > 2. Upgrade до 7.31.UC7 + CCFLAGS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2004, 09:54 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Ну так по твоей ссылке английским по белому пишут, что "по умолчанию" фикс включен в 9.3, у всех остальных его надо включать ручками через CCFLAGS. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2004, 17:59 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Дык, это понятно :-)). Другое дело что делать мне с моим 9.21.UC2. Под Solaris X86 более свежей версии нет и видимо не будет :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2004, 18:19 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
А самого Соляриса-86 свежего-то будет ? Я бы смотрел в сторону Линукса. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2004, 19:11 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
К моменту когда IBM подумал-подумал и забил на выпуск под x86 и Informix и Lotus Notes, Sun раздуплился и объявил что передумал сворачивать проект x86. Так что новая Соляра есть, а свежих версий аппликух - фигвам. Думать, то я про Линух думаю, но в любом случае время на перенос системы у меня по графику не раньше, чем через 2 года :-). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2004, 19:20 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Диьиэй, мечтающий о переходе на новую систему - это неправильный, негодный дибиэй :-) В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2004, 00:00 |
|
||
|
длинный чекпойнт
|
|||
|---|---|---|---|
|
#18+
Думать!=Мечтать :-). У меня сейчас запас по мощности примерно на порядок. Сконфигурированных чанков еще на 2 года хватит, потом можно будет или докупить еще одну стойку (имею 2 свободных канала на контролере) или поменять винты на покрупнее. Приложение менятся скорее всего не будет, так что зачем мечтать о большем :-). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2004, 10:33 |
|
||
|
|

start [/forum/topic.php?fid=44&startmsg=32367055&tid=1608367]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 358ms |

| 0 / 0 |
