我想对数据库改善性能,各位看看这样可否???

小叶子sy

如下:
还有别的吗?这样做是否合理??

谢谢!

1)目标:系统性能增加
2）相关数据
CPU：
#sar -u 1 6
15:48:33    %usr    %sys    %wio   %idle
15:48:34     100       0       0       0
15:48:35     100       0       0       0
15:48:36     100       0       0       0
15:48:37      98       0       0       2
15:48:38      99       1       0       0
15:48:39      99       1       0       0
Average       99       0       0       0
硬盘
#iostat -t 5 10
、、、、、、、
  device    bps     sps    msps
  c1t2d0      5     0.6     1.0
  c2t2d0      5     0.6     1.0
  c1t0d0     12     5.6     1.0最忙/dev/vg01下数据盘
  c2t0d0      0     0.0     1.0
内存交换区
#swapinfo -t
             Kb      Kb      Kb   PCT  START/      Kb
TYPE      AVAIL    USED    FREE  USED   LIMIT RESERVE  PRI  NAME
dev     2097152    1428 2095724    0%       0       -    1  /dev/vg00/lvol2
reserve       -  933360 -933360
total   2097152  934788 1162364   45%       -       0    -
3)主要在CPU利用率忙
下面的改动针对CPU来做的:
4）操作系统参数
核心参数 当前值  改成
SEMMNS = 6640----8192
nfile  = 12008---5000
5)数据库参数
onconfig参数  当前值   改成
NUMCPUVPS      6 ------2
6）优化CHUNK和DBSPACE的分配
三个数据库均放在PICSDBS一个表空间中，而且均在2块硬盘上都有数据,开始没考虑这些,
现在改善是 ：
a)新增加表空间dbspacenew,建CHUNK全在硬盘2上，将最大的一个数据库倒出再重建在表空间dbspacenew上，
倒入数据，这样数据库均分开在不同的硬盘上，会使速度加快
#onstat -d(目前)
address  number   flags    fchunk   nchunks  flags    owner    name
aa908158 1        1        1        1        N        informix rootdbs
aa908f78 2        2001     2        1        N T      informix tempdbs
aa909038 3        1        3        11       N        informix picsdbs
3 active, 2047 maximum
Chunks
address  chk/dbs offset   size     free     bpages   flags pathname
aa908218 1   1   0        500000   428919            PO-   /pics/informix/dev/rootdbs
aa9084f8 2   2   0        750000   749947            PO-   /pics/informix/dev/tempdbs
aa9085d8 3   3   0        1000000  127               PO-   /pics/informix/dev/picsdbs0
aa9086b8 4   3   0        1000000  17504             PO-   /pics/informix/dev/picsdbs1
aa908798 5   3   0        1000000  3525              PO-   /pics/informix/dev/picsdbs2
aa908878 6   3   0        1000000  37213             PO-   /pics/informix/dev/picsdbs3
aa908958 7   3   0        1000000  48442             PO-   /pics/informix/dev/picsdbs4
aa908a38 8   3   0        1000000  44668             PO-   /pics/informix/dev/picsdbs5
aa908b18 9   3   0        1000000  3078              PO-   /pics/informix/dev/picsdbs7
aa908bf8 10  3   0        1000000  179156            PO-   /pics/informix/dev/picsdbs8
aa908cd8 11  3   0        1000000  136168            PO-   /pics/informix/dev/picsdbs9
aa908db8 12  3   0        1000000  1024              PO-   /pics/informix/dev/picsdbs10
aa908e98 13  3   0        1000000  0                 PO-   /pics/informix/dev/picsdbs11
13 active, 2047 maximum
b)逻辑日志文件开大(但我们长事物并不多)
开大SIZE到12500（20个）
#onstat -l(目前的)
Physical Logging
Buffer bufused  bufsize  numpages numwrits pages/io
  P-1  182      256      73398    348      210.91
      phybegin physize  phypos   phyused  %used
      10003f   20000    2559     438      2.19
Logical Logging
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io
  L-1  0        128      3815473  516761   31625    7.4        16.3
        Subsystem    numrecs  Log Space used
        OLDRSAM      3815473  1014894504
address  number   flags    uniqid   begin        size     used    %used
83532024 1        U-B----  7720     104e5f       2500     2500   100.00
83532040 2        U-B----  7721     105823       2500     2500   100.00
8353205c 3        U-B----  7722     1061e7       2500     2500   100.00
83532078 4        U-B----  7723     106baf       2500     2500   100.00
83532094 5        U-B----  7724     107573       2500     2500   100.00
835320b0 6        U-B----  7725     107f37       2500     2500   100.00
835320cc 7        U-B----  7726     1088fb       2500     2500   100.00
835320e8 8        U-B----  7727     1092bf       2500     2500   100.00
83532104 9        U-B----  7728     109c83       2500     2500   100.00
83532120 10       U-B----  7729     10a647       2500     2500   100.00
8353213c 11       U-B----  7730     10b00b       2500     2500   100.00
83532158 12       U-B----  7731     10b9cf       2500     2500   100.00
83532174 13       U-B----  7732     10c393       2500     2500   100.00
83532190 14       U-B----  7733     10cd57       2500     2500   100.00
835321ac 15       U-B----  7734     10d71b       2500     2500   100.00
835321c8 16       U-B----  7735     10e0df       2500     2500   100.00
835321e4 17       U---C-L  7736     10eaa3       2500     2259    90.36
83532200 18       U-B----  7717     10f467       2500     2500   100.00
8353221c 19       U-B----  7718     10fe2b       2500     2500   100.00
83532238 20       U-B----  7719     1107ef       2500     2500   100.00
7)优化表存放位置和EXTEND大小和分段处理
给一些频繁使用的表和数据量大的表加EXTENT大小
改善INDEX

ifx

机器的配置情况？应用都有什么？
CPU瓶颈的系统不太好调整，如果硬件不能扩充的话，只能靠减少进程的办法，限制系统的活动了。

小叶子sy

系统配置:硬盘4个(2*18G,2*36G),内存1G,CPU1个(1G)
操作系统HP-UX11.00,INFORMIX7.3
每天均是INFORMIX的进程在前面,用户不多,只要20几个

ifx

onconfig，onstat -贴上来，或者onstat -a，vmstat 1 10发给我看看。

muzx

原帖由 "小叶子sy" 发表：
系统配置:硬盘4个(2*18G,2*36G),内存1G,CPU1个(1G)
操作系统HP-UX11.00,INFORMIX7.3
每天均是INFORMIX的进程在前面,用户不多,只要20几个

只有一个CPU的话NUMCPUVPS 6 ------2配置不对
应该为

1. MULTIPROCESSOR  0
   
2. NUMCPUVPS       1  
   
3. SINGLE_CPU_VP   1

复制代码

wolfop

我觉得的你的问题的瓶颈在CPU，而且全部是USER说明你的INFORMIX配置基本没有问题了。你现在的方法只有想办法看看你应用和数据库的逻辑设计的问题 了，否则只能靠增加CPU解决。一般情况下user高，sys io idle都低的系统必须从应用层找问题。

muzx

#sar -u 1 6
15:48:33 %usr %sys %wio %idle
15:48:34 100 0 0 0
15:48:35 100 0 0 0
15:48:36 100 0 0 0
15:48:37 98 0 0 2
15:48:38 99 1 0 0
15:48:39 99 1 0 0
Average 99 0 0 0
一直是这样吗？
下面的参数看过吗？
sar -b 2 10
sar -q 2 10
onstat -g iov;sleep 100;onstat -g iov

蓝色键盘

看看本版的性能调有的文章