Czy można uruchamiać perfmon na serwerach produkcyjnych? I dlaczego?

A może perfmon powinien być ograniczony do serwera Dev / QA z testami obciążenia symulującymi aktywność produkcyjną?

Chciałbym uruchomić perfmon przez dwa dni ( jak sugeruje mistrz Sql Server Brent Ozar ), aby uzyskać ogólny obraz wydajności bazy danych mojej aplikacji internetowej.

SQL Server i większość innych produktów generują liczniki przez cały czas, bez względu na to, czy są detektory, czy nie (ignorując opcję uruchamiania -x). Śledzenie licznika jest całkowicie przezroczyste w monitorowanej aplikacji. Istnieje obszar pamięci współużytkowanej, w którym zapisywana jest aplikacja monitorowana i z którego sesje monitorowania odczytują surowe wartości w określonym przedziale czasu. Tak więc jedynym kosztem związanym z monitorowaniem jest koszt procesu monitorowania i koszt zapisu próbkowanych wartości na dysk. Wybór przyzwoitego interwału zbierania (zwykle wybieram 15 sekund) i umiarkowanej liczby liczników (50-100) i zapisywanie w formacie pliku binarnego zwykle nie ma wpływu na monitorowany system.

Ale odradzam używanie Perfmon (jak w perfmon.exe). Zamiast tego zapoznaj się z logman.exe, zobacz Opis narzędzi Logman.exe, Relog.exe i Typeperf.exe . W ten sposób nie wiążesz sesji kolekcji z sesją. Logman, jako narzędzie wiersza poleceń, może być używany w skryptach i zaplanowanych zadaniach do uruchamiania i zatrzymywania sesji kolekcjonowania.

Nie ma nic złego w uruchamianiu perfmon na pudełkach produkcyjnych. Jest to stosunkowo niski klucz i może zebrać dla Ciebie wiele dobrych informacji. Jak dokładnie symulowałbyś obciążenia produkcyjne, gdybyś nie uruchomił analizy na serwerze produkcyjnym? Od Brenta Ozara we własnym linku:

Pozwól Perfmonowi działać przez dzień lub dwa, aby zebrać dobry poziom bazowy aktywności serwera. Monitorowanie programu SQL Server nie jest zbyt inwazyjne, a szczegółowe wyniki się opłacą. Im więcej danych mamy, tym lepszą pracę możemy wykonać przy analizie wyników Perfmon.

Uruchomiłem perfmon na wielu produkcyjnych pudełkach Exchange bez żadnych niepożądanych efektów.

Od tamtej pory raz słuchałem Clinta Huffmana , który napisał PAL jako narzędzie do analizy dzienników Perfmon, raz na podcast. Na wszystkich naszych serwerach aplikacji produkcyjnych skonfigurowałem tak zwany rejestrator lotów. Ta praktyka przydała się do diagnozowania problemów i monitorowania trendów.

Poniżej znajduje się skrypt, którego używam do skonfigurowania automatycznie uruchamiającego się programu Perfmon Collector z czyszczeniem dziennika. W razie potrzeby można go podać liczniki wydajności z listą plików do zebrania (jeden na linię) lub plik XML progu PAL. Lubię używać plików 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

Robimy to dość często. Jest również niezbędny do ustalenia poziomu odniesienia w prawdziwym środowisku, abyś mógł później porównać, jeśli pojawią się problemy lub będziesz musiał przeprowadzić badanie zdolności.

Polecam jednak nie schodzić poniżej 10 sekund. Jeśli zbierasz wiele obiektów / liczników, a interwał jest zbyt częsty, może to wpłynąć na operacje.

Microsoft ma Kreatora PerfMon, który skonfiguruje zadanie dla Ciebie.

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

W idealnym świecie, w którym serwer produkcyjny dokładnie odzwierciedla to, co robi serwer deweloperów, a także jest dokładną kopią serwera deweloperów, perfmon nigdy nie powinien być wymagany na serwerze produkcyjnym, ponieważ wyniki byłyby takie same jak na serwerze deweloperskim. Oczywiście taka mityczna sytuacja nigdy się nie zdarza, dlatego musimy uruchamiać perfmon na serwerach produkcyjnych i nie ma w tym absolutnie nic złego. Między innymi możemy potrzebować użyć perfmon i innych narzędzi, aby dowiedzieć się, dlaczego serwer produkcyjny nie zachowuje się tak samo jak serwer deweloperów.

Dlaczego perfmon? Mam na myśli, że najnowsze wersje serwera SQL mają własną metodę wykonywania tego, w tym budowanie (centralnej) hurtowni danych liczników wydajności, które mogą być następnie sprawdzane i raportowane. Prowadzenie perfmon nie ma sensu.

Jak zawsze jestem zdumiony wszystkimi postami ludzi, którzy oczywiście nigdy nie czytają dokumentacji;)

http://www.simple-talk.com/sql/learn-sql-server/sql-server-2008-performance-data-collector/ to dobry początek. IMHO, które powinno działać na prawie każdym serwerze SQL używanym do celów produkcyjnych.

Nie ma nic złego w uruchamianiu Perfmona, jak wielu sugerowało, ale zamiast tego uruchomiłbym Profiler, z tymi samymi zastrzeżeniami, nie przechwytuj zbyt często, po prostu przechwytuj długie zapytania, tj. Czas trwania> x sekund lub procesor> xx lub czyta> xxxx; bardzo mały wpływ, a szybko zobaczysz zapytania, które najbardziej skorzystałyby na strojeniu.