影响CPU使用率的配置参数和环境变量(转)

looxb

影响CPU使用率的配置参数和环境变量
Online 配置文件onconfig中的下列参数对CPU的利用率有明显的影响:
•        NUMCPUVPS
•        SINGLE_CPU_VP
•        MULTIPROCESSOR
•        AFF_NPROCS
•        AFF_SPROC
•        NUMAIOVPS
•        OPTCOMPAND
•        NETTYPE

NUMCPUVPS、MULTIPROCESSOR和SINGL_CPU_VP
       NUMCPUVPS参数规定了Online 开始启动的CPU VP的数量。分配的CPU VP的个数不要超过可以为它们服务的CPU的个数。
•            对于单处理器的计算机系统，Informix 建议使用一个CPU VP。
•            对于有4个以上CPU，主要用做数据库服务器的多处理器系统，Informix 建议设置NUMCPUVPS的值等于处理器总数减一。
•            对于双处理器系统，运行两个CPU VP可能会改善性能。这需要监控操作系统的CPU使用情况。可以使用操作系统命令sar 或 vmstat。   
    如果运行多个CPU VP，应将MULTIPROCESSOR 设置为1，当设置MULTIPROCESSOR为1时， Online 以对应于多处理器的方式执行锁定。否则，设置该参数为0。

注意：如果设置SINGLE_CPU_VP参数为，则NUMCPUVPS 参数的值也必须是1，如果后者大于1，Online就不能初始化并显示下面的错误信息：
        Cannot have 'SINGLE_CPU_VP' now-zero and 'NUMCPUVPS' greater than 1

AFF_NPROCS 和 AFF_SPROC
    在支持Online和客户应用的系统上，可以通过操作系统把应用连接到某些特定的CPU。这样做可以有效地保留剩余的CPU给Online CPU VP使用，它们是用AFF--NPROCES和AFF_SPROC配置参数连接到剩余CPU的。
    AFF_NPROCS指定了连接到Online的CPU VP上的CPU的个数。连接一个CPU VP到一个CPU 会引起该CPU VP在这个CPU上的排它性运行。
    AFF_SPROC指定了Online把CPU VP连接到CPU上时所启动的CPU。
    AFF_NPROCS规定了计算机上可以帮定CPU VP的CPU的数目。NUMCPUVPS参数指定了 Online将启动的CPU VP的数目，AFF_SPROC参数指定了Online连接第一个CPU序号。例如，某个Online 系统所在的硬件平台有8个CPU，AFF_NPROCS设置为8（即可用于帮定CPU VP的CPU有8个），NUMCPUVPS设置为3，AFF_SPROC设置为5，则3个CPU VP需要帮定到CPU上，是从第五个CPU开始，帮定到第五、六、七个CPU上。需要注意的是，AFF_SPROC的取值是在0和（AFF_NPROCS - NUMCPUVPS + 1)这两个值之间的，不能大于后者。

NUMAIOVPS
    参数NUMAIOVPS指定最初产生的AIO VP的数目。如果所在的操作系统不支持核心异步I/O（KAIO），Online使用AIP VP来处理所有数据库I/O请求。
    推荐的AIP VP数目取决于Online 使用的硬盘个数。如果所在操作系统不支持或没有使用
KAIO，则Informix建议对包含数据库表的每一个磁盘分配一个AIO VP。可以对Online 频繁访问的每六块增加额外的AIO VP。
    如果所在的操作系统使用KAIO VP，CPU VP将直接向操作系统发出原始的I/O请求。在这种情况下，可以只配置一个AIO VP，此时AIO VP只处理文件系统方式的chunk。如果文件系统方式的chunk有增加时，可以增大AIO VP的数目。
    分配AIO VP的目的是要分配足够的AIO VP以便I/O请求队列的长度保持很短，即队列中保持尽可能少的I/O请求。

OPTCOMPIND
    OPTCOMPIND参数帮组优化程序为应用选择合适的访问方法。
•        如果OPTCOMPIND等于0，优化程序给予现存索引优先权，即使在表扫描比较快时。
•        如果OPTCOMPIND设置为1，给定查询的隔离级设置为Repeatable Read时，优化程序才使用索引。
•        如果OPTCOMPIND等于2，优化程序选择基于开销选择查询方式。，即使表扫描可以临时锁定整个表。

NETTYPE
    NETTYPE参数为Online实例支持的每个连接类型配置轮询线索。如果sqlhosts文件中支持一个以上的接口或协议的连接，就必须对每个连接类型规定独立的NETTYPE参数。也即，每中与数据库服务器名字有关的连接类型都需要单独指定一个NETTYPE参数。
    每个用NETTYPE表项配置或动态加入的轮询线索在不同的VP上运行，轮询线索可以在两类VP上运行：NET VP和CPU VP。为得到最佳性能，Informix建议使用NETTYPE表项为CPU VP类只分配一个轮询线索，将其余轮询线索轮询线索分配给NET VP。分配给任何一种连接类型的轮询线索不得超过NUMCPUVPS的取值。
    单CPU计算机上每个轮询线索的最佳连接个数不超过300，多CPU机上可多达350个。但一个轮询线索最多支持1，024甚至更多的连接。
    NETTYPE的配置格式如下：
        NETTYPE        connection_type，poll_threads，c_per_t，vp_class
•        connection_type                标识轮询线索分配的连接协议。
•        poll_threads                是分配给该连接类型的轮询线索数目。对任何连接类型，这个值不能超过NUMCPUVPS值。
•        c_per_t                        是每个轮询线索的连接数目。可以用如下公式计算这个值：
                                c_per_t  = connections / poll_threads
                                connections        是所希望指定的连接类型支持的最大连接数。对于共享内存连接（ipcshm)，该值应该加倍以获得最好的性能。
•        vp_class                是可运行轮询线索的VP类。如果CPU VP上只运行一个轮询线索，那么指定为CPU VP。为了达到最好性能，当要求多个轮询线索时应该指定为NET VP。
    如果c_per_t的值超过了350，而当前连接的轮询线索数小于NUMCPUVPS，可以增加轮询线索数目，但不能超过NUMCPUVPS，然后重新计算c_per_t的取值。
注意：每个ipcshm连接需要一个信号量。当c_per_t的值很大时，对于某些操作系统要相应增加信号量。

如何监控系统CPU的使用情况：
1.        使用UNIX的监控工具sar或vmstat来监控CPU的使用情况。例：sar  5  10
                %usr                %sys                %wio                %idle
10:06:22        34                1                0                65
10:06:27        34                2                0                64
10:06:32        34                1                0                65
10:06:37        17                1                0                82
10:06:47        1                1                0                98
连续监控%idle来确认CPU没有超载。如果%sys的值很大则可能应用有问题。
2.        监控CPU vp的方法
        onstat  -g  glo
        Individual virtual processors:
        vp         pid        class        usercpu                syscpu                total
可以通过该监控看出CPU忙占用的时间(隔60秒分别监控结果）。如果非常忙，则需要增加CPU VP。       

        onstat -g rea
        Ready threads
        tid        tcb        rstcb        prty        status                vp-class        name
如果有大量的线索在等待队列中，则说明需要增加CPU VP。

影响内存使用效率的Online配置参数
•        SHMVIRTSIZE
•        SHMADD
•        BUFFERS
•        RESIDENT
•        STACKSIZE
•        LOCKS
•        LOGBUFF
•        PHYSBUFF

SHMVIRSIZE
    SHMVIRTSIZE参数规定了初始分配给Online的共享内存的虚拟区的大小。共享存储器的虚拟区存储与会话、请求有关的数据及其它信息。虽然Online按处理大型查询或高峰负荷的需要增加共享内存给虚拟区，但共享内存的分配增加事务处理的时间，Informix建议设置SHMVIRTSIZE以提供一个满足一般日常操作需要的虚拟接口。

SHMADD
    SHMADD参数规定Online自动加到虚拟区的共享内存增量的大小。在决定该值的大小时有些折中因素。增加共享内存要占用CPU周期：每次的增加量越大，增加次数就越少，留给其它的进程的内存也越少。通常采用大增加量，但当内存负荷很重时，少量增加使其他程序更好的共享内存资源。Informix 有如下建议：
        内存大小                SHMADD
        <=256MB                8192KB(default)
        256--512MB                16,384KB
        >;=512                        32,768KB

BUFFERS
    BUFFERS是可以用于Online的数据缓冲区数。这些缓冲区驻留在驻留区，用来缓存主存中的数据库的数据页。可用的缓冲区越多，所需的数据页就越可能用于前一次请求而已经在内存里。这个参数对数据库I/O和事务处理吞吐量有明显的影响。但是，分配过多的缓冲区会影响内存系统并导致过多的页面活动。
    Informix建议设置BUFFERS为物理内存(以MB为单位)的20%到25%。实际BUFFERS的单位为页，不同操作系统的页大小是不同的，因此需要计算。
    使用onstat -p监控读缓存的频率。这个频率代表一个查询请求的数据库页已经在共享内存里的百分比。（还没有存在的页必须从磁盘拷贝到内存中）。如果此值很低，可增加BUFFERS并重新启动Online。在增加BUFFERS值时，到达某一点后，增加BUFFERS也不再明显改善读缓存的频率，或者达到操作系统共享内存分配的上限。 如果读高速缓存的比率很高，则应下调BUFFERS并重启动Online。

RESIDENT
    RESIDENT 参数规定是否强制共享内存驻留作为Online共享内存驻留区。这个参数只对支持强制驻留的机器有效。Online中的驻留区，包含用于数据库读写作业的LRU队列。

LOCKS
    参数LOCKS设置任意时刻可用的锁的最大数量。Online中每个锁需要占用驻留区段的44个字节，分配共享内存时要考虑锁所用的资源。一般锁可以分配的大些，对应用比较忙的系统可以到800万以上。

LOGBUFF
    参数LOGBUFF指定为三个用来保存逻辑日志记录的缓冲区分别保留的共享内存的数量。这些缓冲区保存着逻辑日志记录，直到它们被刷新到硬盘上的逻辑日志文件。缓冲区的大小决定了它被添满的频率，从而决定了它必须被刷新到硬盘上的逻辑文件中的频率。

PHYSBUFF
参数PHYSBUFF指定为两个用来暂时保存将被修改的数据页的缓冲区分别保留的共享内存的数量。缓冲区的大小决定了它被添满的频率，从而也决定了它被写到硬盘上的物理日志的频率。

如何监控内存使用情况：
1. 使用onstat -g seg命令监控共享内存的segments。
        onstat -g seg
        Segment Summary
          (resident segments are not locked)
        id         key           addr     size        ovhd        class        blkused            blkfree
这里三行分别代表了驻留内存段（class为R)、虚拟内存段(class为V)、消息内存段(class为M)。blkused和blkfree 分别代表使用空间和空闲空间。如果虚拟内存段的blkused 频繁增加，则需要将SHMVIRTSIZE和SHMADD相应调大，调整后重新启动Online。
2. 使用onstat -p
        1）ovlock指出分配的locks的不足量，如果该值持续增长，则需要增大参数 LOCKS的值。
        2）ovbuf指出分配的buffers的不足量，如果该值持续增长，则需要增大参数 BUFFERS的值。
        3）lockwaits/lockreqs * 100应该小于1%，如果这个计算值比较高，则应有如下考虑：
                a. 是否用了太多的page level locks。如果是，可以考虑用row level locks。
                b. 考虑用了table level lock的应用是否可以用其它类型的lock。
                c. 是否有太多的isolation设置为Repeatable Read 和Cursor Stability。确定是否可以使用更多的Dirty Read来替代。
            4）bufreads %cached的值指出buffer读的百分比，该值建议大于95%，否则增大BUFFERS，bufwrits %cached的值指出buffer写的百分比，该值建议大于85%，但太大如大于97%则可以将BUFFERS 相应减少些。

影响I/O的配置参数
•        CKPTINTVL
•        PHYSFILE
•        CLEANERS
•        LRUS
•        LRU_MAX_DIRTY
•        LRU_MIN_DIRTY

CKPINTVL，PHYSFILE
    CKPINTVL参数指定检查点之间的时间间隔。当检查点间隔到了，则系统执行检查点操作。但如果这期间的所有数据物理上是一致的，Online可以跳过检查点操作。另外，一旦物理日志（PHYSFILE）的75%已满，检查点也会发生。通过设置CKPTINTVL为长时间间隔，可以利用物理日志容量来触发基于实际数据库活动而不是任意时间单位的检查点操作。但是，使用长检查点间隔回增加失败事件之后的恢复时间。

LRUS、LRU_MAX_DIRTY和LRU_MIN_DIRTY
    LRUS参数指示共享内存缓冲池中设置的最近最少使用（LRU）队列数目。配置较多的LRU队列将允许有更多的页清除器操作，并减少每个LRU队列的大小。对于单CPU系统，Informix建议设置LRUS参数为最小值4。对于多CPU系统，Informix建议设置LRUS为最小值4和NUMCPUVPS的取值之中较大的一个。
    可以用LRUS和LRU_MAX_DIRTY及LRU_MIN_DIRTY来控制在满的检查点之间页被刷新到磁盘的频度。在某些情况下，通过设置这些参数，使得在检查点发生时需要刷新的修改的页数量很少，可以达到高的吞吐量；这样，检查点的主要功能是更新物理日志和逻辑日志文件。

CLEANERS
    CLEANERS参数指定执行的页清除线索的数目。对于少于20磁盘的系统，Informix推荐CLEANERS的取值为磁盘的个数。对于20至100的磁盘的系统，Informix推荐每两个磁盘分配一个CLEANERS。对于更多的磁盘系统，Informix推荐每四个磁盘分配一个CLEANERS。

如何监控系统的I/O情况
使用onstat -g ioq，onstat -g iof, onstat -d 监控磁盘的负载情况：
        onstat -g ioq
        AIO I/O queues:
        class/hvp-id        len        maxlen        totalops   dskread   dskwrite        dskcopy
如果aio队列很大，则可增加一个AIO VP。
如果某些class 为gfd 所对应的len 和maxlen 非常大，则需要考虑你的数据分布是否合理，记住这些gfd 所对应的hvp-id的值，再通过onstat -g iof 查出是那几个设备，
        onstat -g iof
        gfd        pathname        totalops                 dskread  dskwriteio/s
这里gfd的值等于onstat -g ioq 中那几个hvp-id的值所对应的pathname就是I/O负载较大的设备。用onstat -d可确定是哪个dbspace。则可以考虑重新分配磁盘或给表分片。

大约在冬季

实用价值很高，不错

czw1413_cn

顶一下

大梦

顶~~~

cjt

不错！

大梦

真的很不错~~

horse

对于调整CPU性能很有帮助.

horse

　　为１。

wangel

学习了