通常的做法是:
max memory = physical memory * 70-80%
default data cache = max memory * 50%
procedure cache size = max memory * 20-30%
number of user connections = n (default = 25)
number of lock = n * 单个用户所需的最大锁数 * 120%
(一般这个比较难估计,syabse的资深工程师给我的参考值:有用户配到180万,对于你的10G的数据量我估计先配 100000)
number of open objects = 10000
number of open indexed = 10000
引擎放弃CPU次数:% of total=1个引擎放弃次数/所有引擎放弃次数,如果显示引擎利用率较低,可通过放弃数判断是否真实反映引擎的停止情况。增加“runnable process search count”(引擎放弃CPU给OS之前一个引擎循环查找可执行任务的次数)参数可增加CPU的驻留时间,而如果想减少引擎在空闲时检查I/O的时间,可减少该参数的值。
Network Checks
Total Network I/O Checks 0.0 0.0 0 n/a
引擎发送或接收网络包的次数。引擎空闲时频繁检查网络包,如果该值很低而“CPU Yields by Engine”的值高,表明引擎可能被频繁放弃。
可能包括阻塞和非阻塞两种检查方式。非阻塞方式不管有无I/O等待都对网络进行I/O检查。如果引擎已被放弃并正执行阻塞网络检查,则在网络包到达以后仍保持一段睡眠时间(潜伏期)。此时增加“runnable process search count”(缺省2000)参数可减少潜伏期,保持引擎有较长的循环检查时间,而不是过早被放弃。
Disk I/O Checks磁盘I/O检查情况:
Total Disk I/O Checks 693.2 58.8 415939 n/a
Checks Returning I/O 469.9 39.9 281921 67.8 %
引擎对I/O情况的有效检查(I/O完成次数),如过高或过低,用“i/o polling process count”(Server的调度程序在检查磁盘I/O或网络I/O之前可执行的最大进程数)参数增加或减少检查频率。通常说增加该值可增加有大量磁盘或网络I/O的应用的吞吐量,反之,减少该值有可改善其响应时间。
Avg Disk I/Os Returned n/a n/a 0.03020 n/a
增加引擎在检查期间的等待时间可改善吞吐量,因为减少引擎检查I/O时间相应增加执行进程的时间。