È corretto eseguire perfmon sui server di produzione? E perché?

O perfmon dovrebbe essere limitato a un server Dev / QA con test di carico che simulano l'attività di produzione?

Mi piacerebbe eseguire perfmon per due giorni ( come suggerisce il master Sql Server Brent Ozar ) per avere un'idea generale delle prestazioni del database della mia app Web.

SQL Server e la maggior parte degli altri prodotti generano continuamente i contatori, indipendentemente dal fatto che siano presenti listener o meno (ignorando l'opzione di avvio -x). La contro traccia è completamente trasparente sull'applicazione da monitorare. Esiste un'area di memoria condivisa su cui scrive l'applicazione monitorata e da cui le sessioni di monitoraggio leggono i valori non elaborati all'intervallo specificato. Pertanto, l'unico costo associato al monitoraggio è il costo del processo di monitoraggio e il costo per scrivere su disco i valori campionati. Scegliere un intervallo di raccolta decente (di solito scelgo 15 secondi) e un numero moderato di contatori (50-100) e la scrittura in un formato di file binario di solito non ha alcun impatto sul sistema monitorato.

Ma sconsiglio di usare Perfmon (come in perfmon.exe). Prendi invece confidenza con logman.exe, vedi la descrizione degli strumenti Logman.exe, Relog.exe e Typeperf.exe . In questo modo non legare la sessione di raccolta alla sessione. Logman, essendo uno strumento da riga di comando, può essere utilizzato negli script e nei processi pianificati per avviare e interrompere le sessioni di raccolta.

Non c'è niente di sbagliato nell'esecuzione di perfmon su scatole di produzione. È relativamente semplice e può raccogliere molte buone informazioni per te. E come simuleresti con precisione i carichi di produzione se non eseguissi qualche analisi sul server di produzione? Da Brent Ozar nel tuo link:

Lascia correre Perfmon per un giorno o due per raccogliere una buona base di attività del server. Non è così invasivo su SQL Server da monitorare e i risultati approfonditi daranno i loro frutti. Più dati abbiamo, migliore è il lavoro che possiamo fare sull'analisi dei risultati di Perfmon.

Ho eseguito perfmon su un numero di scatole di scambio di produzione senza effetti negativi.

Da quando ho ascoltato Clint Huffman , che ha scritto su PAL un'utilità per l'analisi dei registri di perfoni, una volta su un podcast. Ho installato quello che chiamo il registratore di volo su tutti i nostri server delle applicazioni di produzione. Questa pratica è stata molto utile per diagnosticare problemi e monitorare le tendenze.

Di seguito è riportato lo script che utilizzo per impostare un Perfmon Collector a avvio automatico, con eliminazione del registro. Se lo si desidera, può essere inviato un file che elenca i contatori delle prestazioni da raccogliere (uno per riga) o un file XML Soglia PAL. Mi piace usare i file Soglia PAL.

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

Lo facciamo abbastanza frequentemente. È anche essenziale per stabilire una linea di base nell'ambiente reale, quindi è possibile confrontare in seguito se ci sono problemi o è necessario eseguire uno studio della capacità.

Consiglio comunque di non scendere al di sotto di un intervallo di 10 secondi. Se si raccolgono molti oggetti / contatori e l'intervallo è troppo frequente, potrebbe influire sulle operazioni.

Microsoft ha una procedura guidata PerfMon che imposterà l'attività per te.

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

In un mondo ideale in cui un server di produzione rispecchia esattamente ciò che fa un server dev ed è anche un duplicato esatto del server dev, perfmon non dovrebbe mai essere richiesto sul server di produzione perché i risultati sarebbero gli stessi di quelli sul server dev. Ovviamente quella situazione mitica non si verifica mai, quindi abbiamo bisogno di eseguire perfmon sui server di produzione e non c'è assolutamente nulla di sbagliato in questo. Tra le altre cose, potremmo aver bisogno di usare perfmon e altri strumenti per capire perché il server di produzione non si comporta allo stesso modo del server di sviluppo.

Perché perfmon? Voglio dire, le versioni recenti di SQL Server hanno il loro metodo per farlo, inclusa la costruzione di un data warehouse (centrale) di contatori delle prestazioni che possono quindi essere interrogati e segnalati. Non ha senso eseguire il perfmon lì.

Sono, come sempre, stupito da tutti i post qui di persone che ovviamente non leggono mai la documentazione;)

http://www.simple-talk.com/sql/learn-sql-server/sql-server-2008-performance-data-collector/ è un buon inizio. IMHO che dovrebbe funzionare su quasi tutti i server sql utilizzati a scopi di produzione.

Nulla di sbagliato nell'esecuzione di Perfmon come molti hanno suggerito, ma vorrei eseguire Profiler invece o in aggiunta, con gli stessi avvertimenti, non catturare troppo spesso, semplicemente catturare query di lunga durata, cioè durata> x secondi o cpu> xx o legge> xxxx; molto poco impatto e vedrai rapidamente le query che trarrebbero maggior beneficio dall'ottimizzazione.