手里有一个小网站 每天访问大概3~4万IP (页面数倒不高 但几个搜索引擎机器人读的厉害) 
访问一直比较慢(打开页面 快的2~4秒 人多时还要慢 偶尔超时) 以为是服务器老了 
今天新加了一台   结果还是不快 无奈查看性能 有两项
Current Disk Queue Length为 20~30  (正常要<2) 
% Disk Time   3000     (正常要<90%)上网一了解 说是瓶颈在硬盘 我用的是普通的7200转硬盘 有点郁闷啊 这么点访问 怎么办?1. 换高速硬盘 但估计也提高不了多少性能2. 把经常访问的页面 生成html页面 单独存放在web服务器上? 
   但页面很多 上百万页 比较占空间吧 而且还要大批改文件名 搜索引擎收录也要重新来 
   而且是要经常更新的 (会员资料 会员发布的资料 检索页)
   我程序是asp 如果不访问sql 而用FileSystemObject读html页面再显示 效率似乎也不高
 
3. 第三方服务?楼主又比较抠门 舍不得投入很大 毕竟收入有限 

解决方案 »

  1.   

    但大部分访问 都是从500万条记录中检索数据 我感觉不是磁盘慢的问题,500w的数据量也不算大,可以查看一下检索时的关键sql
    是不是性能出在sql上,还有表的索引碎片
      

  2.   

    1:频繁访问硬盘不一定是硬盘的问题,可能是你的内存不大,所以导致经常访问内存。
    增加数据库使用内容的数量。
    最大限制io操作:http://technet.microsoft.com/zh-cn/magazine/jj643251.aspx2:优化索引
    http://www.cnblogs.com/worfdream/articles/2840582.html
      

  3.   

    1、用系统性能监视器监视服务器(windows Server),
    2、打开数据库的sql profiler 抓T-SQL语句,超过2秒的都抓出来。
    将这两个的数据保存下来进行分析,确定你的问题所在
      

  4.   


    内存8G 数据库只使用了1.7G
    CPU占用也不高 10%左右
      

  5.   


    内存8G 数据库只使用了1.7G
    CPU占用也不高 10%左右32位的系统吧?AWE开了没?
    速度慢的sql语句,试试优化一下索引。
      

  6.   


    第一次使用sql 时间探查器 
    发现很多sql语句 duration超过2000毫秒 
    有些reads也比较多 上万的I/O操作
    然后执行了几分钟 把>2s的结果保存成工作负荷文件 
    然后使用索引优化向导 让系统自动优化去了
    不知道效果如何
      

  7.   

    举个简单的例子 看我做的索引 和查询sql语句 对不对表table1
    id  (自动编号 大概数百万条)
    cat   (分类 聚集索引 大概几百个分类 每个分类几千到几万条信息不等)
    mem (会员编号 大概10几万会员 加非聚集索引)  
    pro   (产品名称 加非聚集索引)
    memo   (产品详细资料)
    hits   (浏览量) 网站中主要的查询语句大概是
    1. 按类别显示 分页
    select pro,cat,id from table1 where cat=123
    2. 查询某条具体产品
    select * from table1 where cat=123 and id=45600
    3. 查找某会员的产品
    select top 10 * from table1 where member=120000
    4. 查找某产品的相关产品
    select top 5 pro from table1 where pro like '%xxx%'
    5. 产品浏览+1
    update table1 set hits=hits+1 where cat=123 and id=45600网站访问高的页面 主要也就是 2/3/4几个页面了
      

  8.   

    是独立的数据库服务器前天晚上一直搞这个 基本每过十几分钟 统计出来一些>2s语句 就存成负荷文件 然后去索引优化 重复多次后
    当时感觉 >2s查询少了很多 不过因为当过了12点 访问很少 体现不出来第二天上午 继续观察 过了9点 随着访问增加 Current Disk Queue Length又上去了 到30 最高甚至上百 继续用事件探查器观察 发现一个查询语句(用了select count(*) ...... group by) reads数值很高 上万了  
    当时无意识的 把这块程序改了改 就是专门生成一个表 存放统计数字 不需要每次都从大表里读  然后 奇迹出现了 Current Disk Queue Length 迅速下降到0~1  而% Disk Time也下降到40%
    打开网页快了很多 持续观察一段时间 认定问题最终解决 差点哭了 做了这么多年程序员 才发现不懂的太多了 浪费了多少机会啊
      

  9.   

    现在观察下来 还有一个最常见的查询 比较耗I/O读操作 那就是分页
    比如有几万个查询结果 分成上千页显示 
    每次的sql查询 reads上万 甚至10万 
    不知道有没有好的分页办法 
      

  10.   

    你这个是T-SQL语句没写好,你尝试优化一下程序的T-SQL语句,肯定没有问题的,
    像计数器 avg. disk queue length数值过高,都是因为有查询或操作读取大量数据,而数据不在内存中,导致内存疯狂从硬盘读取数据然后再加载到内存里,这个操作会引起巨大的io等待,尽量减少这方面的操作。
      

  11.   

    越优化 发现要做的事情越多昨天把分页程序改了 
    用select top N ...where id> (select max(id).......) 的方法 
    这样前几页 IO就很低了 到100页后IO明显增加 一般也很少有人翻几百页 把select top N * from table where aaa like '%%'语句改成用专门表存放查询结果 然后定期自动更新这个表 这个IO原来也是几千 速度自然是快了 然后......数据库直接大了3G出来 查看系统自动优化的索引 又发现之前自己对索引的理解 是完全错误的 
    之前都是每个字段单独加索引 而没有和查询语句联系起来 效果自然很差 
    而自动索引 又很多重复索引 有时间要全部重新来过 ...头大啊
      

  12.   

    如果实时性要求不高,可以实现动态页面的静态化,数据库的压力就会降低很多如果是分页的问题,要看具体的分页技术
    那种全部读入应用再分的做法,是败家子的做法,但是很多语言提供的就是这样的做法
    多次top倒腾法,前面的效率会高一些
    如果sql2005了,可以rownumber()
      

  13.   

    如果真是盘的问题买个SSD插上不就搞定了,现在EMLC的盘又不贵