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

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

солярис 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

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 однозначно

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

>По поводу причины, я думаю, что она одназначно в том, что у тебя слишком >много буфферов, 700000 - это 1.4Гб!!, то, что они достаточно долго >сливаются, с чем не справляются либо диски либо очередей слишком мало. >Т.е. надо мониторить во время чекпоинта onstat -R, onstat -F и т.д

Я може чего-то не врубаюсь, но AFAIK сливать ему надо не все 1.4 гига а только измененные страницы. (?)

дисковая система файбер ченал
быстрее не бывает млин

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

"TBLSPACE_STATS 0" не ликвидирует тормоза, но похоже уменьшает.
У меня тормоза уже возникали раз в 4 дня, теперь видимо реже, но еще не достаточно времени для того чтобы делать окончательные выводы.

Уменьшали количество буферов с 700000 до 100000 - эффект нулевой.

И вообще есть сильные подозрения на тормоза при записи на винты.
Может кто сталкивался -
у нас большие винты по 36 гигов разбиты соляровским дисксъютом на мета устройства по 2 гига, тк соляра не позволяет создать более 8и партиций.

Сброс чекпойнта производится со скоростью не более 6-и метров в секунду на файбрченал винте, что не правильно совсем.
Простое копирование на файловую систему более 20и метров в секунду.

каио включено.

а я прислушиваюсь ...

токо руки не до всего доходят сразу

пока читаю пэйджер типа ...

мда картина несколько отличается от той что по ссылке

session #RSAM total used
id user tty pid hostname threads memory memory
88816 informix 64 14336 sf880 3 17006592 16881984

tid name rstcb flags curstk status
88970 ontape 15b09f868 --AP--M 3935 sleeping(secs: 1)
89002 arcbacku 15b098a68 ----X-- 4943 sleeping(Forever)
89003 arcbacku 15b093108 ------- 2879 sleeping(secs: 1)

Memory pools count 1
name class addr totalsize freesize #allocfrag #freefrag
88816 V 15e3e2028 17006592 124608 422 19

name free used name free used
overhead 0 176 scb 0 144
opentable 0 5664 filetable 0 2696
log 0 6504 temprec 0 1656
keys 0 424 gentcb 0 21336
ostcb 0 2824 net 0 16821328
sort 0 104 sqscb 0 11080
rdahead 0 224 hashfiletab 0 1656
osenv 0 2392 sqtcb 0 3696
fragman 0 80

Informix Dynamic Server Version 7.31.FD6 -- On-Line (Prim) -- Up 2 days 23:34:48 -- 2331648 Kbytes

Stack for thread: 89002 arcbackup1
base: 0x000000016e44a000
len: 270336
pc: 0x00000001004e57b0
tos: 0x000000016e48aed1
state: sleeping
vp: 4

0x1004e57b0 ?unknown? :: ?unknown? + 0x0 sp=0x16e48b6d0(0x9204f8, 0x5c5d0cd0, 0x925400, 0x5b014ed8, 0x6e4fe0d0, 0x5b014e60)
0x1004fd320 ?unknown? :: ?unknown? + 0x0 sp=0x16e48b780 delta_sp=176(0x5c98dae8, 0x9202d4, 0x3, 0x9204f8, 0x5c98dae8, 0x45)
0x100349f84 ?unknown? :: ?unknown? + 0x0 sp=0x16e48b830 delta_sp=176(0x2000, 0x9253c0, 0x587a4000, 0x800, 0x1, 0x29)
0x10034a954 ?unknown? :: ?unknown? + 0x0 sp=0x16e48ba70 delta_sp=576(0x8, 0x1, 0x6d870400, 0x5, 0x5b0c5e80, 0xb0f48)
0x10041f9ec ?unknown? :: ?unknown? + 0x0 sp=0x16e48bb40 delta_sp=208(0x0, 0x6cdc9c00, 0x3ff800, 0x6e48be44, 0x910e90, 0xd814)
0x10041f868 ?unknown? :: ?unknown? + 0x0 sp=0x16e48bcd0 delta_sp=400(0x6e48be44, 0x6e48be48, 0x265, 0x5d6f8240, 0x5d9dc678, 0x6e48be48)
0x10041e6a4 ?unknown? :: ?unknown? + 0x0 sp=0x16e48bd80 delta_sp=176(0xffffbfff, 0x8590, 0x4f030, 0x1, 0x5d6f8240, 0x1)
0x1004f31a4 ?unknown? :: ?unknown? + 0x0 sp=0x16e48be50 delta_sp=208(0x9204f8, 0x7, 0x925400, 0x5b014ed8, 0x0, 0x5b014e60)
0x1004eb284 ?unknown? :: ?unknown? + 0x0 sp=0x16e48bf00 delta_sp=176(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)

^Constat>



CCFLAGS не установлен
на днях собираюсь поменять

долго не меняли тк решили сначала получить подтверждение суппорта.
Подтверждение получили, параметр CCFLAGS установлен,
все зашибись!

До чекпойнта пока руки не дошли :-(

Проблема длинного чекпойнта так и не решена.
На сегодняшний момент установлен старт очистителя с 1% грязных страниц до 0.
Переехали на SF890 и стало полегче.

По проблеме удалось только экспериментально определиться что Solaris Volume Manager не причем (во что впрочем и не очень то верилось). Разворачивал тестовый пример на чистом дбспэйсе на нормальных рав-девайсах без метаустройств - эффект тотже.
Чем занят Informix во время сброса чек-пойнта непонятно :-(

Уменьшать же количество буферов не выход, т.к. упадет кэширование. К тому же это никакое не решение, а только другой способ заставить работать LRU еще раньше.

Журавлев Денис cpr...
Переехали на SF890 и стало полегче.
Кстати что такое SF890? Кэш у нее сколько? Rootdbs (PHYSDBS) не пробовал на отдельный от данных (raid) lun положить?

sf890 - Ultra SPARC IV , двухъядерный процессор.

rootdbs, logdbs, пространства с данными находятся на независимых устройствах.

АлексанДобрый день всем.
На Вашем сервере слишком малое количество LRU-очередей и они, как следуствие, слишком длинные. Просто просканировать такие очереди занимает время! Кроме того, число клинеров в несколько раз меньше числа чанков.
Мне кажется, полегчает, если Вы увеличите количество LRU-очередей хотя бы до 63 (а лучше до 128, тем более что это ничего не стоит) и количество клинеров увеличите до того же числа (ресурсов они не занимают, поскольку эти нити существуют только во время их работы).
Эти действия также уменьшат конкуренцию за сами LRU-очереди, если у Вас достаточно много конкурентных пользовательских сессий.

-------
С уважением,
Александр Спирин

Вообще то в настоящий момент 34 очереди и никакой разницы с 8-ю.
ИМХО механизм скана LRU у Informix сделан оптимально.

АлексанДобрый день всем.
На Вашем сервере слишком малое количество LRU-очередей и они, как следуствие, слишком длинные. Просто просканировать такие очереди занимает время! Кроме того, число клинеров в несколько раз меньше числа чанков.
Мне кажется, полегчает, если Вы увеличите количество LRU-очередей хотя бы до 63 (а лучше до 128, тем более что это ничего не стоит) и количество клинеров увеличите до того же числа (ресурсов они не занимают, поскольку эти нити существуют только во время их работы).
Эти действия также уменьшат конкуренцию за сами LRU-очереди, если у Вас достаточно много конкурентных пользовательских сессий.

-------
С уважением,
Александр Спирин

Делал тестовый скрипт, который запускал на машине с одним чанком, скорость сброса 4 метра в секунду.

Журавлев ДенисИ еще: предположим во время чекпоинта надо записать 15 мег., мои дисковые массивы при direct random write при 4кб записях показывают от 0.5 до 15 мег/сек (меряю iozone), поэтому легко можно и 30 секунд писать на дешевом массиве с маленьким кэшем на запись.

к сожалению все на локальных FC дисках. Возможности поработать с RAID-ом нет.

Журавлев ДенисИ еще: предположим во время чекпоинта надо записать 15 мег., мои дисковые массивы при direct random write при 4кб записях показывают от 0.5 до 15 мег/сек (меряю iozone), поэтому легко можно и 30 секунд писать на дешевом массиве с маленьким кэшем на запись.

А какое железо с операционкой?

Тан cprВообще то в настоящий момент 34 очереди и никакой разницы с 8-ю.
ИМХО механизм скана LRU у Informix сделан оптимально.
Откуда разница, если механизм LRU writes не работает?
По крайней мере он не работал 3 года назад, когда LRU_MAX_DIRTY/LRU_MIN_DIRTY были 60/50

сейчас LRU_MAX_DIRTY/LRU_MIN_DIRTY были 1/0
вот он то сейчас и работает

Журавлев ДенисЕсли обратится к документации и почитать про чекпоинты то увидим:

1. Ждать можно на 1-м шаге выход пользовательских нитей из крит. секции (иногда очень долго 10-20-30 мин. :).

2. Ждать можно сброса буферов на шаге 4, с медленными дисками ждать можно долго. Это можно разрулить либо перейдя на LRUwrites LRU_MAX_DIRTY 0.5; либо перейти на собственный чекпоинт CKPTINTVL 9999, в цикле onmode -B&&onmode -C пауза 10 мин. onmode -B -- сброс буферов (нити не блокирует).

а на 7.31 доступен собственный чекпойнт?
дорбный процент для старта очистителя точно недоступен