Est-il correct d'exécuter perfmon sur des serveurs de production? Et pourquoi?

Ou perfmon devrait-il être limité à un serveur Dev / QA avec des tests de charge qui simulent l'activité de production?

J'aimerais exécuter perfmon pendant deux jours ( comme le suggère Brent Ozar, maître du serveur SQL ), pour avoir une idée globale des performances de la base de données de mon application Web.

SQL Server et la plupart des autres produits génèrent des compteurs tout le temps, qu'il y ait ou non des écouteurs (en ignorant l'option de démarrage -x). Le traçage de compteur est complètement transparent sur l'application surveillée. Il existe une région de mémoire partagée sur laquelle l'application surveillée écrit et à partir de laquelle les sessions de surveillance lisent les valeurs brutes à l'intervalle spécifié. Ainsi, le seul coût associé à la surveillance est le coût du processus de surveillance et le coût d'écriture des valeurs échantillonnées sur le disque. Choisir un intervalle de collecte décent (je choisis généralement 15 secondes) et un nombre modéré de compteurs (50-100), et écrire dans un format de fichier binaire ne laisse généralement aucun impact sur le système surveillé.

Mais je déconseille d'utiliser Perfmon (comme dans perfmon.exe). Au lieu de cela, familiarisez-vous avec logman.exe, voir Description des outils Logman.exe, Relog.exe et Typeperf.exe . De cette façon, vous ne liez pas la session de collecte à votre session. Logman, étant un outil en ligne de commande, peut être utilisé dans des scripts et des travaux planifiés pour démarrer et arrêter des sessions de collecte.

Il n'y a rien de mal à exécuter perfmon sur des boîtes de production. Il est relativement discret et peut rassembler beaucoup de bonnes informations pour vous. Et comment simuleriez-vous avec précision les charges de production si vous n'exécutiez pas d'analyse sur le serveur de production? De Brent Ozar dans votre propre lien:

Laissez Perfmon fonctionner pendant un jour ou deux pour rassembler une bonne base de référence de l'activité du serveur. Ce n'est pas si invasif sur le serveur SQL surveillé, et les résultats détaillés seront payants. Plus nous avons de données, mieux nous pouvons faire l'analyse des résultats de Perfmon.

J'ai exécuté perfmon sur un certain nombre de boîtes d'échange de production sans effets indésirables.

Depuis que j'ai écouté Clint Huffman , qui a écrit PAL un utilitaire pour analyser les journaux Perfmon, sur un podcast une fois. J'ai configuré ce que j'appelle l'enregistreur de vol sur tous nos serveurs d'applications de production. Cette pratique s'est avérée très utile pour diagnostiquer les problèmes et surveiller les tendances.

Vous trouverez ci-dessous le script que j'utilise pour configurer un collecteur Perfmon à démarrage automatique, avec purge des journaux. Si vous le souhaitez, vous pouvez lui fournir un fichier répertoriant les compteurs de performances à collecter (un par ligne) ou un fichier XML PAL Threshold. J'aime utiliser les fichiers 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

Nous le faisons assez fréquemment. Il est également essentiel pour établir une base de référence dans l'environnement réel, afin que vous puissiez comparer plus tard s'il y a des problèmes ou si vous devez effectuer une étude de capacité.

Je recommande cependant de ne pas descendre en dessous d'un intervalle de 10 secondes. Si vous collectez de nombreux objets / compteurs et que l'intervalle est trop fréquent, cela peut avoir un impact sur les opérations.

Microsoft a un assistant PerfMon qui configurera la tâche pour vous.

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

Dans un monde idéal où un serveur de production reflète exactement ce qu'un serveur de développement fait et est également un duplicata exact du serveur de développement, perfmon ne devrait jamais être requis sur le serveur de production car les résultats seraient les mêmes que ceux du serveur de développement. Bien sûr, cette situation mythique ne se produit jamais, nous devons donc exécuter perfmon sur des serveurs de production et il n'y a absolument rien de mal à cela. Entre autres choses, nous devrons peut-être utiliser perfmon et d'autres outils pour savoir pourquoi le serveur de production ne se comporte pas de la même manière que le serveur de développement.

Pourquoi perfmon? Je veux dire, les versions récentes de SQL Server ont leur propre méthode pour ce faire, y compris la construction d'un entrepôt de données (central) de compteurs de performances qui peuvent ensuite être interrogés et signalés. Il n'y a aucun sens à y exécuter perfmon.

Je suis, comme toujours, étonné par tous les messages ici de personnes qui n'ont évidemment jamais lu la documentation;)

http://www.simple-talk.com/sql/learn-sql-server/sql-server-2008-performance-data-collector/ est un bon début. IMHO qui devrait fonctionner sur presque tous les serveurs SQL utilisés à des fins de production.

Rien de mal à exécuter Perfmon comme beaucoup l'ont suggéré, mais j'exécuterais plutôt le profileur ou en plus, avec les mêmes mises en garde, ne capturez pas trop souvent, capturez simplement les requêtes longues, c.-à-d. Durée> x secondes ou cpu> xx ou lit> xxxx; très peu d'impact, et vous verrez rapidement les requêtes qui bénéficieraient le plus de l'optimisation.