Eric Liu(The Road to Architect)

有些人注定要生活在彼岸 可以亲近可以爱怜 甚至可以穷尽一生去思念 只是无法触及 有些距离 注定不能跨越 只能俩俩相望 就像有些爱只能养在心里 长在眼中 不要捧在手里 放在身边 注定只能邂逅 无法遭遇

用户操作
[留言]  [发消息]  [加为好友] 
订阅我的博客
XML聚合    FeedSky
订阅到鲜果
订阅到Google
订阅到抓虾
liuruhong的公告
<ul> <li>从最近开始,我会逐步写一些关键软件架构方面的话题,也是对于我过去几年以来技术的一个总结,不管对的还是错的,谨代表我个人在写作时期的观点.</li> <br>可以通过<img src="http://services.nexodyne.com/email/icon/x%2BgpFAEtFjbE/BydyNWE%3D/R01haWw%3D/0/image.png"/>和我取得联系 </li> <li><a href="http://twitter.com/liuruhong">Twitter</a>(follow me) </ul> <div style="width:166px;text-align:center"> <ul id="twitter_update_list"></ul> <a href="http://twitter.com/liuruhong" id="twitter-link" style="display:block;text-align:right;">follow me on Twitter</a> </div> <script type="text/javascript" src="http://twitter.com/javascripts/blogger.js"></script> <script type="text/javascript" src="http://twitter.com/statuses/user_timeline/liuruhong.json?callback=twitterCallback2&amp;count=5"></script>
文章分类
个人推荐
技术站点
Asp.Net
WindowsForms
博客堂
存档

原创  优化你的系统（一） 收藏

 
         前几天和几个朋友聊天,提到一些关于SQL Server方面的一些问题，褒贬不一，他们也碰到了一些性能问题，我给了一些个人的建议，也不知道是否奏效。
 
Q：SQL Server 2000的数据库压力很大，CPU和内存老不够，但是调整的时间又有限，应该如何解决？
 
         从表面来看，无疑是程序问题，但是大多时候碰到这种情况是比较冤枉的
1． 程序不是自己写的
2． 在线系统已经没有足够的时间去调整程序
3． 数据库设计有些致命的问题
4． …..
 
不熟悉、不能和不足够时间，我想问题大抵如此吧，简单的建议如下
1． 超过2G内存的机器，请确定是否在启动参数中加入了 /PAE /3GB选项
2． 是否在组策略中给运行SQL Server的帐号指派了使用AWE的权限，假若没有，查阅相关文档启用
3． 在SQL Server中启用AWE，需要通过sp_configure命令来做
4． 将内存调整成固定内存，2005会好一点，如果是2000，请务必检查启动日志，设置太高的最小内存会有可能实效
5． 这些都做了，发现还是有问题，升级到SQL Server 2005。
 
这些建议都是治标不治本的，不过或许能够帮助适当缓解数据库的压力，内存管理不当会让SQL Server晕菜的。
 
如果还是有问题，如果还是不熟悉SQL Server，不能修改程序，更加没有足够的时间，那么可以考虑做下面的一些工作
1． 使用SQL Profiler，抓出执行最长的这些语句，然后看看那些where之后的字段是否建立了索引，在该建立索引的地方建立索引
2． 如果发现这个是比较复杂或者麻烦的事情，使用SQL优化向导，从某种意义上，这个小工具还是可以帮助解决问题的，听天由命吧，能优化多少算多少
3． 如果这个也没辙了，看看那些执行效率比较低的代码是否是存储过程，通过一些工具，如SQL Expert，来帮助你做一些SQL优化，然后乖乖地拷贝回去
4． 如果发现是插入语句过慢，那么有可能是吃撑了，也就是你的索引建多了，适当看看语句的情况，该去则去吧。
 
1． 关键集中在查询时间占据最多的语句，基本上你可以理解为这是整体数据库系统消耗的百分比
2． 另外可以适当看看I/O占有最大的语句，可能适当的磁盘系统优化也能够帮你解决问题
 
因为这个问题回答的是希望能够最简单快速解决部分问题的情况，一些比较复杂的情况和调整就不去做了，虽然时日不长，不过一时半会应该可以撑过去。
 
Q：数据库中有某个表特别大，导致查询性能比较低，应该如何解决？
         这个问题是去参加TechED的时候路上和一个朋友讨论CSDN的Blog而引发的，虽然我阅读过部分.Text的代码，但是了解依旧有限，只是从个人的角度给出了一些建议
1． 如果这个表包括了大量的可空字段、频繁更新的字段（如点击数）、大文本（文章内容），再加上这个表超过10万条记录，差不多剩下的日子就是等死了，那么这个时候就是分拆。
a)         将文章和评论拆开（这点CSDN似乎很多年前就干了）
b)         将频繁更新的字段拆到另外一个表，虽然我们可以说主表ID建立了聚集索引，但是不管如何都存在读写锁的代价
c)         大文本字段务必拆解到另外一个表上，因为不管如何，你让一个表文件几十个G对系统没有任何好处
d)         另外不要将统计相关的信息和大文本放在同一个数据文件
e)         如果磁盘读些速率还有区别，频繁更新的表所在的数据文件放在高速磁盘上
2． 尽可能升级到2005，从而利用其分区功能
3． 根据业务调整分区规则，一般来说，按照年/月来归档就足够了，详细的分区使用可以查阅相关的帮助
4． 大多文本内容是可以缓存的，如果非要使用MemCached，尽量不要使用Windows版本的，而是假设在Linux上
5． 更加简单的做法是建立一个自己的CacheServer，不需要太多的工作，使用Remoting提供服务就可以了，协议当然是TCP，而后台可以利用HttpRuntime.Cache和文件来实现双缓冲，如果担心文件读写在多线程的情况下会产生比较大的压力，可以使用异步I/O来解决
6． 维护一个自己的缓存过期列表，尽量不工作，而是通过时间戳判断来决定是否超时
7． 缓存引发的另外一个问题是缓存超时或者对象更新（如文章更新）之后的对象移除，可以利用MSMQ异步通知缓存系统删除缓存
8． 当然了，如果只有单台Web Server，放在进程内是更加合理的
 
另外，如果可以静态化的，尽可能静态化，因为静态HTML能够充分利用windows 2003的kernel mode cache
 

发表于 @ 2007年12月25日　20:40:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:SD 2.0 China:一场开发者狂欢的盛宴 | 新一篇:.NET和Web 3.0
查看最新精华文章 请访问博客首页相关文章
  • 发表评论
  • 评论内容：
  •  
Copyright © liuruhong
Powered by CSDN Blog