调整数据库的性能的问题

rockgqq

你的逻辑日志是多大的,你设置的检查点是多长时间
你的TEMPDBS,LOGDBS是多大的

newince

我的逻辑日志是150*5M,检查点是300
没有分出来tmpdbs和logdbs.
我看过一些资料,说,从根分出来会提高效率,但也增加了故障点.

skyearqin

多次提交才成功？
我觉得informix的优化是个不断修改探索的过程，多次提交才能成功肯定是某些资源的争用比较严重所致，一般的资源有Cpu、内存、IO资源等，我见过不少online实例，像你这种情况IO出现争用的可能性最大。

onsatat －p中的顺序读取和索引读取都是多少？都阿贴出来阿。

多次提交拆成功原因较多，建议检查：
1-锁模式，是否都是使用的页锁，如果数据规模不大，建议修改为row
2-楼上说的对，锁等待确实不小，每个锁占用四十四字节共享内存，建议加大。
3-buffer可以开到600－800兆，应该没什么问题，看你的具体qing况。
4-出错的数据表是否索引不良？
5-疑问中？cleaners＝5？LRUS＝8?一般的lrus＝CPU个数就行，onstat －R如果脏页过多，调整cleaners加大，一般的cleaners＝1就够用。很多参数太大了无益。
6-aio的cpu VP市多少个？


－－－－－还是多萜些信息出来，省得大家猜

newince

好的，我把其他信息帖出来，给大家诊断
onstat -p的输出是：


Informix Dynamic Server Version 7.31.UC2   -- On-Line -- Up 5 days 10:53:34 -- 901120 Kbytes

Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
12049974 2512666  2235878804 99.46   438407   777779   5189317  91.55  

isamtot  open     start    read     write    rewrite  delete   commit   rollbk
237255834 2208108  4527743  214564654 1190938  412661   235210   182615   2193

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        32852.02 1128.38  707      3080   

bufwaits lokwaits lockreqs deadlks  dltouts  ckpwaits compress seqscans
2483624  3483     3410820814 1133     0        448      65111    546452  

ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
179921   61489    11302509 11539165   382

newince

onstat -R的输出是：


Informix Dynamic Server Version 7.31.UC2   -- On-Line -- Up 5 days 10:57:37 -- 901120 Kbytes

8 buffer LRU queue pairs                     priority levels
# f/m  pair total  % of    length     LOW   MED_LOW  MED_HIGH   HIGH
0 F     49995   100.0%    49985        1    49446      524       14
1 m               0.0%       10        0        8        2        0
2 f     49995   100.0%    49984        1    49471      492       20
3 m               0.0%       11        0        8        3        0
4 f     49997   100.0%    49989        0    49477      495       17
5 m               0.0%        8        0        7        1        0
6 f     49996   100.0%    49984        1    49473      489       21
7 m               0.0%       12        0        9        3        0
8 f     49998   100.0%    49980        1    49465      495       19
9 m               0.0%       18        0       12        6        0
10 f     49995   100.0%    49977        0    49412      543       22
11 m               0.0%       18        0       11        7        0
12 f     49996   100.0%    49987        0    49451      524       12
13 m               0.0%        9        0        6        3        0
14 f     49999   100.0%    49984        1    49466      504       13
15 m               0.0%       15        0       10        5        0
101 dirty, 399971 queued, 400000 total, 524288 hash buckets, 2048 buffer size
start clean at 60% (of pair total) dirty, or 30000 buffs dirty, stop at 50%
0 priority downgrades, 0 priority upgrades

newince

CU的人真是奇怪，看来大家都是喜新厌旧的人。
我帖出了更多的信息，却没有DX愿意回帖了。
再帖点信息吧，算是自顶一下。


onstat -d:

Informix Dynamic Server Version 7.31.UC2   -- On-Line -- Up 5 days 10:53:06 -- 901120 Kbytes

Dbspaces
address  number   flags    fchunk   nchunks  flags    owner    name
4605413c 1        1        1        4        N        informix rootdbs
1 active, 2047 maximum

Chunks
address  chk/dbs offset   size     free     bpages   flags pathname
460541f8 1   1   500      1000000  498901            PO-   /usr/informix/chunks/rootchunk
46055224 2   1   250      1000000  16                PO-   /usr/informix/chunks/chunk1
46055300 3   1   250      1000000  677978            PO-   /usr/informix/chunks/chunk2
460553dc 4   1   250      1000000  999997            PO-   /usr/informix/chunks/chunk3
4 active, 2047 maximum

lmtok

还是强烈建议楼主把tmpdbs和logdbs分出来
另外的一点建议是，tmpdbs可以建很多个，尽量多
建几个并把这些tmpchunk分布到不同的物理磁盘
上，以平衡因tmpdbs读写引发的大量IO

bigsunflower

300000万个锁还多阿，搞成2000000还差不多阿，你的锁等待这么多！
lokwaits *100/lockreqs 应《0。01

bigsunflower

300000万个锁还多阿，搞成2000000还差不多阿，你的死锁怎么这样多啊！

newince

[quote]原帖由 "bigsunflower"]300000万个锁还多阿，搞成2000000还差不多阿，你的死锁怎么这样多啊！[/quote 发表：


300000个锁已经是调整之前的参数了。目前是800000。
奇怪的是，在lock值是300000时，lockwaits还没有这么大。
我认为是我调整了clears和lrus的原因。关于这两个参数。我看到的
资料和CU上的DX说的都很不一致。有人说是CPU的个数，有人说是硬盘
的个数。书上说在单CPU下是max(4,??)（我忘了，要查一下）。

我怀疑是CLEARS设大了造成了，不知道对不对。
有趣的是，现在大家看到我的onstat -p，觉得性能很差，lockwait大，
deadlink都不算小。  但是，就是这样的情况下，我最早提到的问题（反复提交才能成功）居然得到了解决！！！

是参数上看性能指标正确还是实际工作事实证明是正确的？？？