Можно ли запускать perfmon на производственных серверах? И почему?

Или perfmon должен быть ограничен сервером Dev / QA с нагрузочными тестами, которые моделируют производственную деятельность?

Я хотел бы запустить perfmon в течение двух дней ( как советует мастер Sql Server Брент Озар ), чтобы получить общее представление о производительности базы данных моего веб-приложения.

SQL Server и большинство других продуктов генерируют счетчики постоянно, независимо от того, есть прослушиватели или нет (игнорируя параметр запуска -x). Счетчик отслеживания полностью прозрачен в контролируемом приложении. Существует область общей памяти, в которую записывает отслеживаемое приложение и из которой сеансы мониторинга считывают необработанные значения с заданным интервалом. Таким образом, единственные затраты, связанные с мониторингом, это стоимость процесса мониторинга и стоимость записи выборочных значений на диск. Выбор приемлемого интервала сбора (обычно я выбираю 15 секунд) и умеренного количества счетчиков (50-100) и запись в двоичный формат файла обычно не влияют на отслеживаемую систему.

Но я бы рекомендовал не использовать Perfmon (как в perfmon.exe). Вместо этого ознакомьтесь с logman.exe, см. Описание инструментов Logman.exe, Relog.exe и Typeperf.exe . Таким образом, вы не привязываете сеанс сбора к своему сеансу. Logman, являясь инструментом командной строки, может использоваться в сценариях и запланированных заданиях для запуска и остановки сеансов сбора.

Нет ничего плохого в запуске perfmon на производственных коробках. Это относительно сдержанный ключ, и он может собрать много полезной информации для вас. И как бы вы точно смоделировали производственные нагрузки, если бы не проводили какой-либо анализ на рабочем сервере? От Brent Ozar по вашей собственной ссылке:

Позвольте Perfmon работать в течение дня или двух, чтобы собрать хорошую основу деятельности сервера. Это не так уж инвазивно для отслеживаемого SQL Server, и подробные результаты окупятся. Чем больше у нас данных, тем лучше мы можем анализировать результаты Perfmon.

Я запустил perfmon на нескольких производственных коробках Exchange без каких-либо побочных эффектов.

С тех пор, как я слушал Клинта Хаффмана , который написал PAL утилиту для анализа журналов Perfmon, однажды на подкасте. Я настроил то, что я называю Flight Recorder, на всех наших производственных серверах приложений. Эта практика очень пригодилась для диагностики проблем и отслеживания тенденций.

Ниже приведен скрипт, который я использую для настройки автозапускаемого Perfmon Collector с очисткой журнала. При желании его можно передать в файл со списком счетчиков производительности для сбора (по одному на строку) или в файл PAL Threshold XML. Мне нравится использовать файлы PAL Threshold.

<#
Install-FlightRecorder.ps1
.SYNOPSIS
Installs or sets up the pieces necessary to create PerfMon Collector 
snapshots, one a minute, to a file located in C:\FlightRecorder.

.DESCRIPTION
Installs or sets up the pieces necessary to create PerfMon Collector 
snapshots, one a minute, to a file located in C:\FlightRecorder.

.PARAMETER Path
File listing performance counters to collect, one per line. 
Or a PAL Threshold XML file.

#>
[CmdletBinding()]
param (
    [string]$Path
)

#Requires -RunAsAdministrator
$ScriptDir = { Split-Path $MyInvocation.ScriptName –Parent }
$DeleteTempFile = $False

function Main {
    if (-not $Path) { $Path = DefaultFile $Path }
    if (-not (Test-Path $Path)) {
        Write-Warning "Path does not exist or is inaccessable: $Path"
        Exit 1
    }
    if ($Path -like '*.xml') { $Path = PALFile $Path }

    Install-FlightRecorder
    if ($Path.startswith($env:TEMP)) {Remove-Item $Path}
    Write-Verbose 'Installation Successful.'
}

function Install-FlightRecorder {
    Write-Verbose 'Setting up the Flight Recorder.'
    if (-not (Test-Path c:\FlightRecorder\)) {
        mkdir c:\FlightRecorder | out-null 
    }
    if ((LOGMAN query) -match 'FlightRecorder') {
        Write-Verbose 'Removing former FlightRecorder PerfMon Collector.'
        LOGMAN stop FlightRecorder | out-null
        LOGMAN delete FlightRecorder | Write-Verbose
    }
    Write-Verbose 'Creating FlightRecorder PerfMon Collector.'
    LOGMAN create counter FlightRecorder -o "C:\FlightRecorder\FlightRecorder_$env:computername" -cf $Path -v mmddhhmm -si 00:01:00 -f bin | Write-Verbose
    SCHTASKS /Create /TN FlightRecorder-Nightly /F /SC DAILY /ST 00:00 /RU SYSTEM /TR 'powershell.exe -command LOGMAN stop FlightRecorder; LOGMAN start FlightRecorder; dir c:\FlightRecorder\*.blg |?{ $_.LastWriteTime -lt (Get-Date).AddDays(-3)} | del' | Write-Verbose
    SCHTASKS /Create /TN FlightRecorder-Startup /F /SC ONSTART /RU SYSTEM /TR "LOGMAN start FlightRecorder" | Write-Verbose
    SCHTASKS /Run /TN FlightRecorder-Startup | Write-Verbose
}

function DefaultFile {
    Write-Warning 'Counter or PAL file not specified, using default configuration.'
    $DeleteTempFile = $True
    $Path = [System.IO.Path]::GetTempFileName()
    Set-Content -Encoding ASCII $Path @'
\LogicalDisk(*)\Avg. Disk sec/Read
\LogicalDisk(*)\Avg. Disk sec/Write
\LogicalDisk(*)\Disk Transfers/sec
\LogicalDisk(C:)\Free Megabytes
\Memory\% Committed Bytes In Use
\Memory\Available MBytes
\Memory\Committed Bytes
\Memory\Free System Page Table Entries
\Memory\Pages Input/sec
\Memory\Pages/sec
\Memory\Pool Nonpaged Bytes
\Memory\Pool Paged Bytes
\Memory\System Cache Resident Bytes
\Network Interface(*)\Bytes Total/sec
\Network Interface(*)\Output Queue Length
\Paging File(*)\% Usage
\Paging File(*)\% Usage Peak
\PhysicalDisk(*)\Avg. Disk sec/Read
\PhysicalDisk(*)\Avg. Disk sec/Write
\Process(_Total)\Handle Count
\Process(_Total)\Private Bytes
\Process(_Total)\Thread Count
\Process(_Total)\Working Set
\Processor(*)\% Interrupt Time
\Processor(*)\% Privileged Time
\Processor(*)\% Processor Time
\System\Context Switches/sec
\System\Processor Queue Length
'@
    $Path
}

function PalFile {
    $DeleteTempFile = $True
    $InputPath = $Path
    $Path = [System.IO.Path]::GetTempFileName()
    $filesRead = @()
    Read-PalFile $InputPath | Select -Unique | sort | Set-Content -Encoding ASCII $Path
    $Path
}

$script:filesRead =@()
function Read-PalFile ([string]$path) {
    if (-not (Test-Path $path)) {
        Write-Warning "PAL Threshold file not found: $path"
        return
    }
    if ($script:filesRead -contains $path) {return}
    $script:filesRead += @($path)
    Write-Verbose "Reading PAL Threshold file: $path"
    $xml = [XML](Get-Content $path)
    $xml.SelectNodes('//DATASOURCE[@TYPE="CounterLog"]') | select -expand EXPRESSIONPATH
    $xml.SelectNodes('//INHERITANCE/@FILEPATH') | select -expand '#text' | where {$_ } | ForEach {
        $newpath = Join-Path (Split-Path -parent $path) $_
        Write-Debug "Inheritance file: $newpath"
        Read-PalFile $newpath
    }
}

. Main

Мы делаем это довольно часто. Это также важно для установления базовой линии в реальной среде, поэтому вы сможете сравнить ее позже, если возникнут проблемы или вам необходимо провести исследование потенциала.

Я рекомендую не опускаться ниже 10-секундного интервала. Если вы собираете много объектов / счетчиков и интервал слишком велик, это может повлиять на операции.

Microsoft имеет PerfMon Wizard, который установит задачу для вас.

http://www.microsoft.com/downloads/details.aspx?FamilyID=31FCCD98-C3A1-4644-9622-FAA046D69214&displaylang=en

В идеальном мире, где рабочий сервер точно отражает то, что делает сервер dev, а также является точной копией сервера dev, на рабочем сервере никогда не требуется perfmon, поскольку результаты будут такими же, как на сервере dev. Конечно, такой мифической ситуации не бывает, поэтому нам нужно запустить perfmon на производственных серверах, и в этом нет абсолютно ничего плохого. Помимо прочего, нам может понадобиться использовать perfmon и другие инструменты, чтобы узнать, почему рабочий сервер не работает так же, как сервер dev.

Почему перфмон? Я имею в виду, что в последних версиях SQL-сервера есть свой собственный метод, включающий создание (центрального) хранилища данных счетчиков производительности, которые затем можно запрашивать и сопоставлять. Там нет никакого смысла в запуске perfmon там.

Я, как всегда, удивлен всеми сообщениями здесь людей, которые явно никогда не читают документацию;)

http://www.simple-talk.com/sql/learn-sql-server/sql-server-2008-performance-data-collector/ - хорошее начало. ИМХО, это должно работать почти на каждом сервере sql, который используется в производственных целях.

Нет ничего плохого в запуске Perfmon, как предлагали многие, но я бы запустил Profiler вместо этого или дополнительно, с теми же предостережениями, не слишком часто перехватывал, просто захватывал долго выполняющиеся запросы, т.е. длительность> x секунд или cpu> xx или читает> хххх; очень небольшое влияние, и вы быстро увидите запросы, которые больше всего выиграют от настройки.