我碰巧注意到了这一点，并认为我会在几年前敲响铃铛时做出回应。

Sybase/SAP经历了各种计数器的无数次迭代，这些计数器在各种情况下均无法正常工作，我们放弃了说实话，因为每次它们修复一个计数器又一个计数器损坏时。

我们的主要监视查询使用sysprocesses中的physical_io（是的，在95％的情况下可以使用此方法），并且有条件地将monProcessObject用于您提到的命令（以及其他）

我没有看过您的第二个例子。

 

 physical_io = p.physical_io，

 

 total_lio = mpa.LogicalReads，
         stmt_lio = isull（（当cmd in（'UPDATE STATISTICS'，'CREATE INDEX'，'DROP INDEX'，'REORG'，'TRUNCATE TABLE'，'WORKER PROCESS'，'DBCC'时的情况）然后（选择sum（LogicalReads） 来自master..monProcessObject mpo，其中mpa.SPID = mpo.SPID和mpa.KPID = mpo.KPID），否则mps.LogicalReads结束），0），
         stmt_cpu = isull（如果cmd ='WORKER PROCESS'然后mpa.CPUTime否则mps.CpuTime end/100，0），
         tot_physical_writes = mpa.PhysicalWrites，
         tot_physical_reads = mpa.PhysicalReads，
         mem_tot = mpa.MemUsageKB
 

  从master..sysprocesses p
     在p.spid = mpa.SPID和p.kpid = mpa.KPID上加入master..monProcessActivity mpa
     左联接master..monProcessStatement上的mps（mpa.SPID = mps.SPID和mpa.KPID = mps.KPID）

  

请记住，等待时间就是在事件上花费的时间，因此，如果您错过了6秒，则可能是引擎上的任务花费的时间，即cpu时间 在本质上。 因此，在这20秒钟中，有70％的时间是在等待，有30％的时间是在使用CPU。

我假设您将"内核模式"设置为"线程化" 新的ASE 16安装。 这改变了一些有关I/O如何运行以及ASE中谁（哪个线程）实际运行I/O的事情。

如果您运行

 sp_sysmon" 00:00:10"，"内核" 

并转到输出的"线程利用率"部分，您将看到有单独的线程在做网络I/O和磁盘I/O。

线程利用率（OS％）用户忙系统忙
   ------------------------- ------------ -------------  ---------
   ThreadPool：syb_blocking_pool：采样期间无活动

   线程池：syb_default_pool
    线程2（引擎0）7.6％0.0％92.4％
    线程3（引擎1）15.6％0.2％84.2％
    线程4（引擎2）25.0％0.4％74.6％
    线程5（引擎3）34.6％0.2％65.2％
    线程6（引擎4）12.8％0.2％87.0％
    线程7（引擎5）10.2％0.0％89.8％
    线程8（引擎6）6.0％0.2％93.8％
    线程9（Engine 7）11.4％0.2％88.4％
   ------------------------- ------------ -------------  ---------
   汇总池总计123.2％1.4％675.4％
                   平均值15.4％0.2％84.4％


   线程池：syb_system_pool
    线程14（NetController）0.2％1.8％98.0％
    线程15（DiskController）0.6％0.6％98.8％
 

我想知道您的进程是否显示更多空闲状态，因为在线程模式下，您的进程在等待网络I/O或磁盘I/O线程时不会显示为繁忙。

在sp_sysmon中的"内核使用率"部分中，FYI大多也忽略I/O繁忙号码。 如果有任何I/O待处理（甚至只有1个），则任何空闲引擎都将被视为I/O繁忙

尊敬的西蒙，

这对于物理/逻辑I/O错误很有帮助。 出于任何原因，您从sysprocesses而不是monProcessObject中获取物理I/O？ 谢谢！！

最后，对monProcessWaits的任何评论。 让我们知道的是，MonProcessWaits（应该被认为是MDA等待的前7个表之一）并没有考虑到将近30％的时间，这让我们感到不安。 我们的查询很简单....

->按col4从表顺序中选择*

**我们发现spid是597

从monProcessWaits中选择*，其中SPID = 597-sample1

等待延迟" 00:00:20"

从monProcessWaits中选择*，其中SPID = 597-sample2

monProcessWaits中的数据显示，sample1和sample2之间等待SPID 597的总时间为14秒，而不是实际的20秒。 因此，缺少20秒中的6秒。 换句话说，monProcessWaits缺少了将近30％的采样时间。

致谢

Anurag Bhattacharjee。