求教：检查点执行时间间隔大于onconfig文件CKPTINTVL参数的值

houhuaw

回复 10# liaosnet

从手册上看到的检查点触发执行的条件：
1 到达CKPTINTVL指定的时间并切有修改
2 物理日志占用超过75％
3 ...

另外一台没有承载业务的机子，配置都是一样的，如下
# Shared Memory Parameters      

LOCKS           500000          # Maximum number of locks
NUMAIOVPS        3              # Number of IO vps
PHYSBUFF        64              # Physical log buffer size (Kbytes)
LOGBUFF         64              # Logical log buffer size (Kbytes)
CLEANERS        16               # Number of buffer cleaner processes
SHMBASE         0x44000000L     # Shared memory base address
SHMVIRTSIZE     200000          # initial virtual shared memory segment size
SHMADD          81920           # Size of new shared memory segments (Kbytes)
EXTSHMADD       8192            # Size of new extension shared memory segments (Kbytes)
SHMTOTAL        0               # Total shared memory (Kbytes). 0=>unlimited
SHMVIRT_ALLOCSEG .80,4          # Values between 0 and .99 are %, values > 1 are
                                # KB - when this much virtual memory is used we
                                # try to get a new segment. 0 means "off". 2nd
                                # parameter is alarm level
CKPTINTVL       300             # Check point interval (in sec)
TXTIMEOUT       300             # Transaction timeout (in sec)
STACKSIZE       128     # Stack size (Kbytes)

执行onstat -g ckp结果如下，这个是到5分钟就坚决执行检查点的，但是不承载业务：
> onstat -g ckp

IBM Informix Dynamic Server Version 11.10.FC2     -- On-Line -- Up 134 days 23:38:57 -- 1375204 Kbytes

AUTO_CKPTS=On   RTO_SERVER_RESTART=Off   

                                                                    Critical Sections                          Physical Log    Logical Log   
           Clock                                  Total Flush Block #      Ckpt  Wait  Long  # Dirty   Dskflu  Total    Avg    Total    Avg   
Interval   Time      Trigger    LSN               Time  Time  Time  Waits  Time  Time  Time  Buffers   /Sec    Pages    /Sec   Pages    /Sec  
66802      14:35:05  CKPTINTVL  247:0x4bc018      0.0   0.0   0.0   0      0.0   0.0   0.0   56        56      42       0      11       0     
66803      14:40:05  CKPTINTVL  247:0x4bd23c      0.0   0.0   0.0   0      0.0   0.0   0.0   26        26      8        0      1        0     
66804      14:45:06  CKPTINTVL  247:0x4c0018      0.0   0.0   0.0   0      0.0   0.0   0.0   32        32      19       0      3        0     
66805      14:50:06  CKPTINTVL  247:0x4c103c      0.0   0.0   0.0   0      0.0   0.0   0.0   13        13      0        0      1        0     
66806      14:55:06  CKPTINTVL  247:0x4c4018      0.0   0.0   0.0   0      0.0   0.0   0.0   32        32      19       0      3        0     
66807      15:00:06  CKPTINTVL  247:0x4c503c      0.0   0.0   0.0   0      0.0   0.0   0.0   13        13      0        0      1        0     
66808      15:05:06  CKPTINTVL  247:0x4c8018      0.0   0.0   0.0   0      0.0   0.0   0.0   32        32      19       0      3        0     
66809      15:10:06  CKPTINTVL  247:0x4c903c      0.0   0.0   0.0   0      0.0   0.0   0.0   13        13      0        0      1        0     
66810      15:15:06  CKPTINTVL  247:0x4cc018      0.0   0.0   0.0   0      0.0   0.0   0.0   32        32      19       0      3        0     
66811      15:20:06  CKPTINTVL  247:0x4cd03c      0.0   0.0   0.0   0      0.0   0.0   0.0   13        13      0        0      1        0     
66812      15:25:06  CKPTINTVL  247:0x4d0018      0.0   0.0   0.0   0      0.0   0.0   0.0   32        32      19       0      3        0     
66813      15:30:07  CKPTINTVL  247:0x4d103c      0.0   0.0   0.0   0      0.0   0.0   0.0   13        13      0        0      1        0     
66814      15:35:07  CKPTINTVL  247:0x4fa018      0.0   0.0   0.0   0      0.0   0.0   0.0   92        92      76       0      41       0     
66815      15:40:07  CKPTINTVL  247:0x4fc308       0.0   0.0   0.0   0      0.0   0.0   0.0   61        61      50       0      2        0     
66816      15:45:07  CKPTINTVL  247:0x4ff018       0.0   0.0   0.0   0      0.0   0.0   0.0   32        32      19       0      3        0     
66817      15:50:07  CKPTINTVL  247:0x50003c      0.0   0.0   0.0   0      0.0   0.0   0.0   13        13      0        0      1        0     
66818      15:55:07  CKPTINTVL  247:0x503018      0.0   0.0   0.0   0      0.0   0.0   0.0   32        32      19       0      3        0     
66819      16:00:08  CKPTINTVL  247:0x50403c      0.0   0.0   0.0   0      0.0   0.0   0.0   13        13      0        0      1        0     
66820      16:05:08  CKPTINTVL  247:0x507018      0.0   0.0   0.0   0      0.0   0.0   0.0   32        32      19       0      3        0     
66821      16:10:08  CKPTINTVL  247:0x50803c      0.0   0.0   0.0   0      0.0   0.0   0.0   13        13      0        0      1        0     

Max Plog       Max Llog       Max Dskflush   Avg Dskflush   Avg Dirty      Blocked      
pages/sec      pages/sec      Time           pages/sec      pages/sec      Time         
1408           2592           0              1              0              0            

> onstat -R

IBM Informix Dynamic Server Version 11.10.FC2     -- On-Line -- Up 134 days 23:52:04 -- 1375204 Kbytes

Buffer pool page size: 2048

32 buffer LRU queue pairs              priority levels
# f/m   pair total     % of    length       LOW      HIGH
0 f      15625     100.0%    15625      15416        209
1 m                  0.0%        0          0          0
2 f      15625     100.0%    15625      15406        219
3 m                  0.0%        0          0          0
................................
60 f      15625     100.0%    15624      15429        195
61 m                  0.0%        1          0          1
62 f      15625     100.0%    15625      15398        227
63 m                  0.0%        0          0          0
31 dirty, 500000 queued, 500000 total, 524288 hash buckets, 2048 buffer size
start clean at   0.780% (of pair total) dirty, or 122 buffs dirty, stop at
   0.390%

目前确实是不影响业务运行，但我真的很想搞明白到底是为什么，为什么没有承载业务的机子LRU dirty总是好几十，而业务量很大的LRU dirty在前5分钟几乎全是0，难道真的不往LRU里面写吗，呵呵

liaosnet

回复 11# houhuaw


    检查下两个库是不是都使用的 buffered-log，再检查点logbuff的大小是不是一样。。

houhuaw

回复 12# liaosnet


    都是buffered-log的库，LOGBUFF都是 64(Kbytes)