¿Está bien ejecutar perfmon en servidores de producción? ¿Y por qué?

¿O debería limitarse a un servidor Dev / QA con pruebas de carga que simulan la actividad de producción?

Me gustaría ejecutar perfmon durante dos días ( como sugiere el maestro del servidor SQL Brent Ozar ) para tener una idea general del rendimiento de la base de datos de mi aplicación web.

SQL Server, y la mayoría de los otros productos, generan los contadores todo el tiempo, sin importar si hay oyentes o no (ignorando la opción de inicio -x). El seguimiento del contador es completamente transparente en la aplicación que se está monitoreando. Hay una región de memoria compartida en la que escribe la aplicación monitoreada y desde la cual las sesiones de monitoreo leen los valores sin procesar en el intervalo especificado. Entonces, el único costo asociado con el monitoreo es el costo del proceso de monitoreo y el costo de escribir los valores muestreados en el disco. Elegir un intervalo de recolección decente (generalmente elijo 15 segundos) y un número moderado de contadores (50-100), y escribir en un formato de archivo binario generalmente no deja ningún impacto en el sistema monitoreado.

Pero recomendaría no usar Perfmon (como en perfmon.exe). En lugar de familiarizarse con logman.exe, consulte Descripción de las herramientas Logman.exe, Relog.exe y Typeperf.exe . De esta manera, no vincula la sesión de recopilación a su sesión. Logman, al ser una herramienta de línea de comandos, se puede utilizar en scripts y trabajos programados para iniciar y detener sesiones de recopilación.

No hay nada de malo en ejecutar perfmon en cajas de producción. Es relativamente bajo y puede reunir mucha información buena para usted. ¿Y cómo simularía con precisión las cargas de producción si no ejecutara algún análisis en el servidor de producción? Desde Brent Ozar en tu propio enlace:

Deje que Perfmon se ejecute durante un día o dos para recopilar una buena línea de base de la actividad del servidor. No es tan invasivo en el servidor SQL que se está monitoreando, y los resultados detallados darán sus frutos. Cuantos más datos tengamos, mejor trabajo podremos hacer para analizar los resultados de Perfmon.

He ejecutado perfmon en varias cajas de Exchange de producción sin efectos adversos.

Desde que escuché a Clint Huffman , quien le escribió a PAL una utilidad para analizar Perfmon Logs, en un podcast una vez. He configurado lo que llamo Flight Recorder en todos nuestros servidores de aplicaciones de producción. Esta práctica ha sido muy útil para diagnosticar problemas y monitorear tendencias.

A continuación se muestra el script que utilizo para configurar un Perfmon Collector de inicio automático, con depuración de registros. Si lo desea, se puede alimentar un archivo que enumera contadores de rendimiento para recopilar (uno por línea) o un archivo XML de umbral PAL. Me gusta usar los archivos de umbral 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 hacemos con bastante frecuencia. También es esencial para establecer una línea de base en el entorno real, para que pueda comparar más adelante si hay problemas o si necesita realizar un estudio de capacidad.

Sin embargo, recomiendo no ir por debajo de un intervalo de 10 segundos. Si está recolectando muchos objetos / contadores y el intervalo es demasiado frecuente, puede afectar las operaciones.

Microsoft tiene un Asistente de PerfMon que configurará la tarea por usted.

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

En un mundo ideal donde un servidor de producción refleja exactamente lo que hace un servidor de desarrollo, y también es un duplicado exacto del servidor de desarrollo, nunca se debe requerir perfmon en el servidor de producción porque los resultados serían los mismos que los del servidor de desarrollo. Por supuesto, esa situación mítica nunca sucede, por lo que necesitamos ejecutar perfmon en servidores de producción y no hay absolutamente nada de malo en eso. Entre otras cosas, es posible que necesitemos usar perfmon y otras herramientas para saber por qué el servidor de producción no se comporta igual que el servidor de desarrollo.

¿Por qué perfmon? Quiero decir, las versiones recientes del servidor SQL tienen su propio método para hacerlo, incluida la construcción de un almacén de datos (central) de contadores de rendimiento que luego se pueden consultar y reportar. No tiene sentido ejecutar Perfmon allí.

Estoy, como siempre, asombrado por todas las publicaciones aquí de personas que obviamente nunca leen la documentación;)

http://www.simple-talk.com/sql/learn-sql-server/sql-server-2008-performance-data-collector/ es un buen comienzo. En mi humilde opinión, que debería funcionar en casi todos los servidores sql que se utilizan con fines de producción.

No hay nada de malo en ejecutar Perfmon como muchos han sugerido, pero en su lugar ejecutaría Profiler o, además, con las mismas advertencias, no capture demasiado con demasiada frecuencia, solo capture consultas de ejecución prolongada, es decir, duración> x segundos o cpu> xx o lee> xxxx; muy poco impacto, y verá rápidamente las consultas que más se beneficiarían de la optimización.