ASE15多用户并发时的效率问题

1017of

好象CPU的使用率好多了，是使用了多tempdb吗？事务处理效率也得到了一点提高。
试试把large I/O的page放大点，看看效果，你的系统好象最大可以放到32k。

还可以试试关闭tempdb相关device的sync属性，也许就可以不用tempcache了。最好不要关闭其他设备的sync属性，有安全隐患。

gaowd

原帖由 jarjar 于 2009-3-16 21:35 发表
你的页面大小是多大？
select @@maxpagesize

页大小为4K

gaowd

目前还没用多tempdb，large io放大到过16K，没什么效果又调回来了

tempdb相关device的sync属性这个可以试一下

1017of

怎么第二个sysmon的I/O busy比第一个少这么多?可能当时的繁忙程度不太一样?

你先试试sync属性吧，还有一招可以调整I/O size，不过这个也许有点浪费内存。
最好还是试试多tempdb吧，tempcache的spinlock ratio都超过10%太多了，怀疑tempdb的system table争用比较厉害。这也是让你观察tempdb lock的原因。

gaowd

好的，我试一下，多谢！

gaowd

又配置了2个tempdb，下面是多tempdb下出来的结果

1017of

CPU负荷降低了,是因为做sysmon的时候业务少了吗?

返回sp_configure 'disk'看一下,前面我居然没有注意到,唉
device sync的属性做了吗?

gaowd

业务没少，跟以前操作一样，只是数据量大了点

修改新增临时库设备的sync时，增加下图错误

sp_configure "disk" 的结果如下

disable disk mirroring                  1                  0                   1                   1        switch        static
disk i/o structures                256                 58                 256                 256        number        dynamic

1017of

把disk i/o structures放大一点,比如4096或者8192

这个warning是正常的,因为关闭这个属性,有可能引起其上数据丢失。而tempdb在系统重新启动时会重建，所以影响并不大。但对其他设备尽量不要关闭此属性。

gaowd

disk i/o structures 这一项记得原来根据sp_sysmon报告的提示改过，不起作用

新创建的tempdb是否有必要绑定到命名缓存中？