Советы по ведению журнала производительности

Question

Я занимаюсь разработкой пары приложений службы сбора больших данных ASP.Net/Windows, использующей Microsoft SQL Server 2005 через LINQ2Sql. Производительность - это всегда проблема.

В настоящее время приложение разделено на несколько больших обрабатывающих частей, каждая из которых регистрирует продолжительность своей работы. Это не подробно и не помогает нам ни с чем. Было бы неплохо иметь несколько таблиц базы данных, которые содержат статистику, которую само приложение собирало по собственному поведению.

Какие советы по ведению журнала и структурам данных вы порекомендуете для выявления частей, вызывающих проблемы с производительностью?

Edit: В основном я ищу части приложения, которые могут нанести вред всей системе при чрезмерном использовании. Есть пики в течение дня, когда некоторые части приложения находятся под большой нагрузкой. Некоторая расширенная регистрация поможет мне выделить детали, которые требуют большего внимания и оптимизации.

Answer 1

Не используйте ведение журнала для этого, вместо этого используйте счетчики производительности. Влияние времени выполнения счетчиков производительности незначительно, и вы можете просто включить их всегда. Для сбора и мониторинга производительности вы можете использовать существующую инфраструктуру счетчиков производительности ( perfmon.exe , logman.exe , relog.exe и т. Д.).

Я лично использую XML и XSLT для генерации счетчиков . Затем я могу украсить весь мой код с помощью функций отслеживания счетчиков производительности, средней продолжительности вызова, количества выполнений, скорости выполнения в секунду и т. Д. И т. Д. Хороший выбор счетчиков обеспечит мгновенную, точную и эффективную картину намного быстрее, чем может сделать запись. В то время как ведение журнала может дать более глубокое понимание определенных путей событий (т. Е. Порядка событий, которые приводят к определенному состоянию), ведение журнала редко может быть «всегда включено», поскольку влияние на производительность является значительным не только для производительности, но, что наиболее важно, для параллелизма, поскольку большинство существующая инфраструктура ведения журналов добавляет конкуренции.

Answer 2

Когда я сталкиваюсь с такими проблемами, я стараюсь не добавлять лишнюю головную боль, вручную добавляя логирование / трассировку и синхронизацию в само приложение. Если все, что вам нужно, это настроить приложение, тогда я предлагаю получить профилировщик, который покажет вам, какие области кода являются проблемой. Я рекомендую Red-Gate's Ant's Profiler .

Теперь, если вы хотите собирать статистику для целей мониторинга или отслеживания тенденций, профилировщик не является подходящим инструментом. Я успешно использовал PerformanceCounters, который позволяет многим сторонним инструментам извлекать информацию о производительности из приложения.

Итак, что вы пытаетесь решить, проблемы с производительностью или монитор, чтобы убедиться, что вы обнаружите проблему с производительностью, прежде чем она станет серьезной?

EDIT

Исходя из вашего комментария, я бы посмотрел на использование мониторов производительности вокруг критически важных участков кода, указав время, необходимое для завершения операции. Затем вы можете использовать встроенные инструменты мониторинга производительности или любое количество сторонних инструментов для мониторинга и отслеживания статистики.

Answer 3

SQL Server отслеживает некоторые вещи для вас, поэтому попробуйте выполнить некоторые из этих запросов в вашей системе:

Wayback Machine: обнаружение скрытых данных для оптимизации производительности приложения

вот пример по ссылке:

--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;

ссылка содержит много запросов, в том числе: дорогостоящие отсутствующие индексы, логически фрагментированные индексы, идентификация наиболее часто выполняемых запросов и т. Д.

Answer 4

Хотя я (пока) не пробовал это для себя, возможно, стоит взглянуть на Гибралтар , который можно использовать с PostSharp для добавления декларативной регистрации производительности в ваш код.

Answer 5

Это не работа для регистрации. Это работа для профилировщика.

Попробуйте один из них:

• JetBrains 'dotTrace - http://www.jetbrains.com/profiler/index.html
• Red-Gate ANTS - http://www.red -gate.com / products / ants_profiler / index.htm
• AQTime автоматического QA - http://www.automatedqa.com/products/aqtime/index.asp

Answer 6

Я бы начал, диагностируя, какова реальная причина проблемы перфорации? Это процессор, память, диск или IO. Это можно определить по нескольким счетчикам пермонов.

Например, Linq2SQL использует Sync I / O, который может стать большим узким местом для масштабируемости. Поскольку он использует синхронизацию потоков ввода-вывода Windows Sync, блокируются и запросы в конечном итоге ожидают. Это обычное подозрение и может не быть правдой. Вот статья MSDN о том, как синхронный ввод-вывод может повлиять на масштабируемость.

Если проблема с ЦП, то следующий вопрос - связан ли ЦП приложения? Тогда вы можете использовать один из профилировщиков, как указано выше. Также поищите время, проведенное на счетчике GC perfmon, который является еще одним обычным подозреваемым?