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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

• dotTrace JetBrains' - http://www.jetbrains.com/profiler/index.html
• Red-Gate ANTS - http://www.red-gate.com/products/ants_profiler/index.htm
• Automated QA в AQtime - http://www.automatedqa.com/products/aqtime/index.asp

Answer 3

В то время как у меня нет (пока) попробовал это для себя, может быть стоит посмотреть на Gibraltar, который может использоваться с PostSharp, чтобы поставить декларативную производительность l ogging в ваш код.

Answer 4

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

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; 

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

Answer 5

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

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

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

EDIT

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

Answer 6

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

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

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