none
PhysicalDisk: Avg. Current Disk Queue Lengt和PhysicalDisk: %Disk time的问题 RRS feed

  • 问题

  •    1,最近发现我的DB系统PhysicalDisk: %Disk time的值经常会超过100%,而且PhysicalDisk: Avg. Current Disk Queue Lengt量也经常是达到10以上,我有12块硬盘,做了raid10,现在想问一下,PhysicalDisk: Avg. Current Disk Queue Lengt量要不要除以12呀?
      2,我的 DB server有16GB内存,AWE打开了,但没有设置max memory size,跟踪得到Total server memory和   Tager server memory都是15.2GB,但又发现page fault/sec有的时候能达到200多,不过available Memory 倒一直维持在200mB左右。不知道是不是据此可以断定是因为没有限制sql server的max memory size而导致了OS的分页呢?



    2009年12月23日 9:51

答案

全部回复

  • 1. Divide by 6, but still doesn't sound right. Did you put data files, log fils and tempdb on separate arrays?
    2. Better to set max memory and ensure sql service account has 'lock pages in memory' user rights on the server.
    2009年12月23日 13:39
  •    1, 存储子系统与DB server是直连的。 12个磁盘都做在成了一个array,data files, log fils and tempdb 都放在了这个阵列上。
      2,16GB的物理内存,max memory  size射程多少比较合理?
    2009年12月24日 1:17
  • 1. that's why you see heavy disk i/o.
    2. assume it's dedicated sql server. Give 14gb to sql, don't put /3gb in boot.ini file if it's 32-bit machine. 
    2009年12月24日 1:58
  • %Disk time意义不大,不如看Idle time。
    Current Disk Queue经常在10以上,是连续的还是约一分钟一次?如果约一分钟一次,应该是由于checkpoint引起的,是正常现象。
    想不想时已是想,不如不想都不想。
    2009年12月24日 7:25
    版主
  • 根据你描述的情况,硬盘使用率应该数据正常的,如果你担心硬盘IO有瓶颈你可以观察一下AVG.Disk Queue Length 和Idle Time 的值,既然你使用了AWE最好给定一个最大使用内存值
    2009年12月28日 0:54
  •      这几天忙活了下,做了下基线跟踪。跟踪时间24小时,每15秒取样一次。
             经计算得,如果按AVG.Disk Queue Length >12来算,则
            Avg_Disk_Queue_Length  大于 12的时间是151分钟;
           
       如果按AVG.Disk Queue Length >24来算,则
         Avg_Disk_Queue_Length  大于 24的时间是132分钟;

    进一步计算Avg_Disk_Queue_Length,Idle_Time,Avg_Disk_sec_Read,Disk_sec_Write平均值,结果如下:
    --按Avg_Disk_Queue_Length>12计算
    select
          avg(cast([PhysicalDisk_E_F_Avg_Disk_Queue_Length] as numeric(20,5)))  队列长度的平均值,
          avg(cast([PhysicalDisk_E_F_%_Idle_Time] as numeric(20,5)))  磁盘队列的Idle_time,
          avg(cast([PhysicalDisk_E_F_Avg_Disk_sec_Read] as numeric(20,5)))*1000 磁盘读的延时,
          avg(cast([PhysicalDisk_E_F_Avg_Disk_sec_Write] as numeric(20,5))) *1000 磁盘写的延时
    from temp
    where   cast([PhysicalDisk_E_F_Avg_Disk_Queue_Length] as numeric(20,5)) > 12

    队列长度的平均值                                磁盘队列的Idle_time                          磁盘读的延时(ms)                                  磁盘写的延时(ms)
    --------------------------------------- --------------------------------------- --------------------------------------- ---------------------------------------
    83.686588                                   57.001945                                       23.245000                                          107.944000



    按Avg_Disk_Queue_Length  大于 24来计算:
    select
          avg(cast([PhysicalDisk_E_F_Avg_Disk_Queue_Length] as numeric(20,5)))  队列长度的平均值,
          avg(cast([PhysicalDisk_E_F_%_Idle_Time] as numeric(20,5)))  磁盘队列的Idle_time,
          avg(cast([PhysicalDisk_E_F_Avg_Disk_sec_Read] as numeric(20,5)))*1000 磁盘读的延时,
          avg(cast([PhysicalDisk_E_F_Avg_Disk_sec_Write] as numeric(20,5))) *1000 磁盘写的延时
    from temp
    where  cast([PhysicalDisk_E_F_Avg_Disk_Queue_Length] as numeric(20,5)) > 24

    队列长度的平均值                                磁盘队列的Idle_time                          磁盘读的延时(ms)                                  磁盘写的延时(ms)
    --------------------------------------- --------------------------------------- --------------------------------------- ---------------------------------------
    93.298126                               55.154833                               25.253000                               113.625000

    从以上数据来看,我的IO还是有压力的。



    因为在晚上2:00到 4:00之间有备份,压缩,索引优化等作业,因此这段时间的IO压力会非常大,其队列会非常长。因此扣除这段时间内的数据,可以计算得出在其他时间段里Avg_Disk_Queue_Length大于12的时间为33分钟,Avg_Disk_Queue_Length>24的时间为27.5分钟。

    因此,我最后的结论是我的IO确实压力。


    不知道各位高手如何看呢?

    2009年12月31日 6:25
  • Should put data files, log files and tempdb on their own disk arrays.
    2009年12月31日 20:00
  • thanks!
    2010年1月6日 8:32