性能日志提示

时间:2010-03-23 19:57:13

标签: asp.net sql-server performance logging windows-services

我正在开发大数据收集ASP.Net/Windows服务应用程序对,它通过LINQ2Sql使用Microsoft SQL Server 2005。 性能始终是个问题。

目前,该应用程序分为多个较大的处理部分,每个部分记录其工作的持续时间。这不详细,对我们没有任何帮助。如果有一些数据库表包含应用程序本身从其自身行为中收集的统计信息,那将会很不错。

您建议使用哪些日志提示和数据结构来发现导致性能问题的部分?

编辑: 大多数情况下,我正在寻找可能在过度使用时削弱整个系统的部分应用程序。当应用的某些部分处于高负荷时,白天有高峰。一些高级日志记录将帮助我隔离需要更多关注和优化的部分。

6 个答案:

答案 0 :(得分:2)

请勿使用日志记录,而是使用性能计数器。性能计数器的运行时影响很小,您可以简单地将它们始终打开。要收集和监控效果,您可以依赖现有的效果计数器基础架构(perfmon.exelogman.exerelog.exe等。

我个人使用XML and XSLT to generate the counters。然后,我可以使用正在运行的性能计数器跟踪功能,平均呼叫持续时间,执行次数,每秒执行速率等来装饰我的所有代码,等等。良好的计数器选择将比记录能力更快地提供即时,准确的性能图像。虽然日志记录可以提供对某些事件路径(即导致某种状态的事件顺序)的更多洞察,但日志记录很少会“始终在线”,因为对性能的影响很大,不仅在性能上,而且最重要的是在并发性方面。现有的日志记录基础设施增加了争用。

答案 1 :(得分:1)

这不是记录工作。这是剖析器的工作。

尝试以下方法之一:

答案 2 :(得分:1)

虽然我还没有(但)为自己尝试过,但可能值得查看可以与Gibraltar一起使用的PostSharp将声明性性能记录放入代码中。

答案 3 :(得分:1)

SQL Server会为您跟踪一些内容,因此请尝试在您的系统上运行其中一些查询:

Wayback Machine: Uncover Hidden Data to Optimize Application Performance

这是链接中的一个示例:

--Identifying Most Costly Queries by I/O 
SELECT TOP 10 
 [Average IO] = (total_logical_reads + total_logical_writes) / qs.execution_count
,[Total IO] = (total_logical_reads + total_logical_writes)
,[Execution count] = qs.execution_count
,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2, 
         (CASE WHEN qs.statement_end_offset = -1 
            THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 
          ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) 
        ,[Parent Query] = qt.text
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Average IO] DESC;

该链接包含许多查询,包括以下内容:成本丢失的索引,逻辑碎片索引,识别最常执行的查询等等...

答案 4 :(得分:1)

在处理这样的问题时,我尝试通过手动添加日志记录/跟踪来增加任何额外的麻烦。进入应用程序本身的时间。如果您只想调整应用程序,那么我建议您使用一个分析器,它将向您显示哪些代码区域存在问题。我建议Red-Gate's Ant's Profiler

现在,如果您想收集用于监控或趋势分析的统计信息,那么分析器不是正确的工具。我使用PerformanceCounters取得了成功,让许多第三方工具从应用程序中提取性能信息。

那么你想要做什么来解决性能问题或监控以确保在性能问题变得严重之前就能解决?

修改

根据您的评论,我会考虑在代码的关键部分使用性能监视器,计算完成操作所需的时间。然后,您可以使用内置的性能监控工具或任意数量的第三方工具来监控和趋势统计数据。

答案 5 :(得分:0)

我会开始诊断这个性能问题的真正原因是什么?是CPU,内存,磁盘还是IO。这可以通过几个perfmon计数器来识别。

例如,Linq2SQL使用同步I / O,这可能是可扩展性的一大瓶颈。因为它使用了同步I / O窗口线程被阻止,请求最终会等待。这通常是怀疑,可能不是真的。以下是MSDN article同步I / O如何影响可伸缩性。

如果CPU出现问题,那么下一个问题是应用程序CPU绑定了吗?然后你可以使用上面提到的一个分析器。还要寻找GC perfmon计数器上花费的时间,这是另一个常见的嫌疑人吗?