SQL Server的一个问题，tuning方面的

北风

其实总量还好2000个xml file, 9G左右的大小
主要是种类schema很多, 每一种要求的逻辑都不同
所以短时间把这个.net的程序用SQL替换掉比较难,这是没得办法的事情了
我所说的row by row,也是在多线程的基础上的, connection pool也有100
也tuning过, index没有大问题
我估算来看不应该用这么长的时间,test的环境上跑的更快

所以我想这周末从这几个地方看一看
1. 弄掉那个SnareCore
2. 监视Resource Monitor
3. tracing 1-3分钟
如果还看不出来, 就再review code看有没有可能变慢的地方, 再fully test在test环境
再叫上一个sys admin下下周一起看
没有performance tester, 就会这样sys那边说是SQL的问题, SQL就说是编程的问题, 编程就说是网络的问题, 网络就说是server的问题.....................

Fernando

还是Oracle好啊

交易人生

还是review code吧，举个例子，当做schema/xml transformation的时候，尤其是当shema很多的时候，最常犯的错误就是每次都load schema，很慢，所有的schema应当是pre-loaded，这个在一个公司发生过，换句话讲，要预先load schema到内存里，然后做validation和transformation ，比如可以用XmlSchemaCollection 或者别的什么技术。

线程不是越多越好，一般的情况是 线程数量=cpu*2+1，不然适得其反。

用各种profiler 追踪，很慢的活，但学东西。

还有一种情况，本来就应当这么慢，哈哈，谁也没辙。

交易人生

原帖由 Fernando 于 2012-5-1 12:55 发表
还是Oracle好啊

碰到烂的程序，啥也不行，不过oracle的确比sql server好，这个不服不行。

Fernando

服务器上加几块SSD花不了多少钱的

菜地一块

看了一下，提一点建议吧：
1、可以开一下SQL SERVER的监视器，即从SQL SERVER自身的角度来看看，被调用了哪些SQL语句。这个跟你是否用.net什么的没什么关系，比较有用。可以反映出来你的程序有没有毛病。这个工具SQL SERVER自带有的，不用另外购买或者下载。
2、着重看一下程序在加解锁方面，有没有问题。有可能不是SQL SERVER慢了，是你的程序在多线程同步方面有问题。
3、看下有没有其他的问题，例如句柄是否有泄漏。如果在WINDOWS下面的话可以在进程管理器中把句柄打开。这个问题也会导致速度变慢的。

Wangx813

监测一下SQL Server服务器的内存使用，SQL Server的一个问题就是不释放内存（MS不承认，但实际使用如此）。

典

原帖由 Wangx813 于 2012-5-3 22:43 发表
监测一下SQL Server服务器的内存使用，SQL Server的一个问题就是不释放内存（MS不承认，但实际使用如此）。

不释放内存对SQL Server来讲不是问题，SQL Server有自己的一套管理机制，很多时候就是占而不用，就象房地产公司占了地皮，划分了，埋了管子，但实际上没有被用，

所以SQL Server就算100G内存被占，但实际上可能50G是Free的。

Fernando

几种主流数据库都是不释放内存的，Oracle是直接预占
这对DB server的性能来说只有好处，没有坏处，除非DB Server上还有其他应用要竞争内存

北风

谢谢建议，1，2我都做了，第3不是很理解，这里句柄是指什么？

原帖由 菜地一块 于 3/5/2012 01:04 发表
看了一下，提一点建议吧：
1、可以开一下SQL SERVER的监视器，即从SQL SERVER自身的角度来看看，被调用了哪些SQL语句。这个跟你是否用.net什么的没什么关系，比较有用。可以反映出来你的程序有没有毛病。这个工具SQL SERVER自 ...

philowen

个人观点，你要是抱着不改代码的想法，那真不是路子，一行就是一次SQL transaction，再怎么优化都很丑啦。。。内存，锁等都可能是问题。
这次优化了好了，假设速度变为10个小时，如果几个月后数据量大了一倍呢？

Fernando

而且不改代码，就意味着你愿意接受developer开发的任何rubbish code，以后他们就会更不注重代码质量。很多差的developer都不考虑性能问题的，认为性能问题是DBA的事情，他们只管写code，这样出来的项目质量都很差

菜地一块

原帖由 北风 于 2012-5-4 10:08 发表
谢谢建议，1，2我都做了，第3不是很理解，这里句柄是指什么？

句柄就是HANDLE,是标识一个windows kernal对象的标识符。windows kernal object包括互斥量、线程、管道、邮槽，等等。句柄泄漏也是一种资源泄漏，它不一定跟内存泄漏同时出现，但如果有句柄泄漏的话，程序也会越来越慢的。
可以在windows任务管理器里将进程的句柄数显示出来（默认是不显示的），看看你那个进程占用的句柄数有没有异乎寻常地大。

在编程开发上，任何现象总是事出有因的，只要付出足够多的时间和精力，大部分问题都能够找到具体原因并加以解决。祝你早日搞定它。

清风拂山岗

建议试一试 SqlBulkCopy.

pswyjz

看了你的描述：

1. 过程其中前一个小时的batch requests/sec可以达到3000/sec，但是之后长时间只有100-200/s，即使重新开始也之后这么多
   我在另一个几乎同样的测试环境（一样的CPU, RAM, 用一个SAN），做的测试时也可以达到3000/sec，没有测试到一小时很多

A: seems related. Result set / table  
试一下 10%  and  1% 数据用多长时间.  如果用的时间远远小于 10% or 1%,  考虑大家的建议.  tunning DB side.  
如果线性减小, 改进余地不大.   只有改设计, 改Code, eg. 用 数据库SP CLR run.

eg. drop index, especially clustered index.  reduce the time of maintain index during insert.  Best way would be  bulk in.
partition dataset,  using parallel process by multi thread.  insert into partitioned table or  Merge result from smaller table.
总之,减少log操作, 控制当前工作数据大小, 批量倒入后在数据库中统一合并,排序.

2. 在过程中查看resource waits，最多的是network I/O 大概是300ms/s，请问这个值是不是太高了？
看看query plan, table lock, isolating level.
降低Thread数量,看看和parallel有关系吗?

[ 本帖最后由 pswyjz 于 2012-5-4 23:24 编辑 ]

北风

好了，这周的时间减少到7小时了
虽然还是不好，但总算可以接受了
如果能有时间真应该重做这个project
这本来应该是个database project，却被.net做了

交易人生

9gb的东西折腾20多个小时，的确过分。当然也看你的库有多大。

北风

就是那个SnareCore.exe
这是一个log tool他会log每一个SQL logon/logout，然后传到另一个server上去备份
本来这个没什么大问题
但是我们那个.net application会产生非常多的connection，就会使SnareCore产生非常多的log
装这个SnareCore的时候我不在，当时那个DBA也不知道。后来请了一个consultant也没搞定。这个东西已经困扰他们几个月了
说实话我觉得这是个不太好的结局
我把这个解决了，也告诉了他们原因，结果是一个这么无聊的原因。他们也不会觉得我多了不起，而且我还多少得罪了一点那个装这个东西的人
虽然他们都看起来很高兴，很惊喜。可是我总感觉到他们多是惊喜，而没有太多对我的工作内容的赞扬

原帖由 北风 于 7/5/2012 10:01 发表
好了，这周的时间减少到7小时了
虽然还是不好，但总算可以接受了
如果能有时间真应该重做这个project
这本来应该是个database project，却被.net做了

交易人生

有些事情把自己的事情做了，该说说，爱谁谁，想太多不好。

IsDonIsGood

原帖由 北风 于 2012-5-7 12:25 发表
就是那个SnareCore.exe
这是一个log tool他会log每一个SQL logon/logout，然后传到另一个server上去备份
本来这个没什么大问题
但是我们那个.net application会产生非常多的connection，就会使SnareCore产生非常多的log
...

那当时为什么要装这个snarecore呢？如果仅仅是作为测试用的话也就算了，如果不是测试用的话会不会有什么特殊的需求？
最好搞清楚啦，不然到时候发现少了什么没记录，还是要找到你啊。宁可慢点，这个责任要撇干净啊，在missing requirement document 的情况下宁可不改，也不要为了performance冲动啊~~

典

说不定他们认为snarecore没问题，问题是.net方案
我们的系统intranet也有类似的LOG系统，不知道叫什么名字，所有的login/logout event都会有记录，

[ 本帖最后由 典 于 2012-5-7 19:28 编辑 ]

北风

这个snare主要关于是windows event
所以我决定还是turn on它，但是设置SQL不把log给windows event，只是存在SQL自己的log里
今天测试了一下还可以