Há algum problema em executar o perfmon em servidores de produção? E porque?

27

Ou o perfmon deve ser limitado a um servidor de Dev / QA com testes de carga que simulem a atividade de produção?

Gostaria de executar o perfmon por dois dias ( como o mestre do Sql Server, Brent Ozar, sugere ) para obter uma idéia geral do desempenho do banco de dados do meu aplicativo da Web.

    
por Bill Paetzke 11.05.2010 / 22:53

7 respostas

26

O SQL Server e a maioria dos outros produtos geram os contadores o tempo todo, independentemente de haver ouvintes ou não (ignorando a opção de inicialização -x). O rastreamento de contador é completamente transparente no aplicativo que está sendo monitorado. Há uma região de memória compartilhada na qual o aplicativo monitorado grava e a partir da qual as sessões de monitoramento lêem os valores brutos no intervalo especificado. Portanto, o único custo associado ao monitoramento é o custo do processo de monitoramento e o custo de gravação dos valores amostrados no disco. Escolher um intervalo de coleta decente (eu geralmente escolho 15 segundos) e um número moderado de contadores (50-100), e escrever em um formato de arquivo binário geralmente não causa impacto no sistema monitorado.

Mas eu recomendaria contra o uso de Perfmon (como no perfmon.exe). Em vez disso, familiarize-se com o logman.exe, consulte Descrição das ferramentas Logman.exe, Relog.exe e Typeperf.exe . Dessa forma, você não vincula a sessão de coleta à sua sessão. O Logman, sendo uma ferramenta de linha de comando, pode ser usado em scripts e trabalhos agendados para iniciar e interromper as sessões de coleta.

    
por 12.05.2010 / 08:50
14

Não há nada errado em executar o perfmon em caixas de produção. É uma chave relativamente baixa e pode reunir muitas informações boas para você. E como você simularia com precisão as cargas de produção se não executasse alguma análise no servidor de produção? De Brent Ozar em seu próprio link:

Let Perfmon run for a day or two to gather a good baseline of the server’s activity. It’s not that invasive on the SQL Server being monitored, and the in-depth results will pay off. The more data we have, the better job we can do on analyzing the Perfmon results.

Eu executei perfmon em uma série de caixas de troca de produção sem efeitos adversos.

    
por 11.05.2010 / 23:01
6

Desde que eu escutei Clint Huffman , que escreveu PAL um utilitário para analisar registros de desempenho, em um podcast uma vez. Eu configurei o que chamo de Flight Recorder em todos os nossos servidores de aplicativos de produção. Essa prática é muito útil para diagnosticar problemas e monitorar tendências.

Abaixo está o script que eu uso para configurar um Perfmon Collector de inicialização automática, com limpeza de log. Se desejar, ele pode ser alimentado com um contêiner de desempenho de listagem de arquivos para coletar (um por linha) ou um arquivo XML de Limite PAL. Eu gosto de usar os arquivos 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
    
por 11.05.2010 / 23:43
3

Nós fazemos isso com bastante frequência. Também é essencial para estabelecer uma linha de base no ambiente real, para que você possa comparar mais tarde se houver problemas ou precisar realizar um estudo de capacidade.

Eu recomendo não ficar abaixo de um intervalo de 10 segundos. Se você estiver coletando muitos objetos / contadores e o intervalo for muito freqüente, isso poderá afetar as operações.

A Microsoft possui um Assistente do PerfMon que configurará a tarefa para você.

link

    
por 11.05.2010 / 23:15
2

Em um mundo ideal onde um servidor de produção espelha exatamente o que um servidor de desenvolvimento faz, e é também uma duplicata exata do servidor dev, o perfmon nunca deve ser requerido no servidor de produção porque os resultados seriam os mesmos que os do servidor de produção. servidor dev. É claro que essa situação mítica nunca acontece, então precisamos executar o perfmon em servidores de produção e não há absolutamente nada de errado com isso. Entre outras coisas, podemos precisar usar o perfmon e outras ferramentas para saber por que o servidor de produção não está se comportando da mesma forma que o servidor de desenvolvimento.

    
por 11.05.2010 / 23:43
2

Por que perfmon? Quero dizer, as versões recentes do SQL Server têm seu próprio método de fazer isso, incluindo a construção de um data warehouse (central) de contadores de desempenho que podem ser consultados e reportados. Não há sentido em executar o perfmon lá.

Eu sou, como sempre, espantado com todos os posts aqui de pessoas que obviamente nunca leram a documentação;)

link é um bom começar. IMHO que deve funcionar em quase todos os servidores SQL que é usado para fins de produção.

    
por 12.05.2010 / 09:04
1

Nada de errado com a execução do Perfmon, como muitos sugeriram, mas eu executaria o Profiler ou, além disso, com as mesmas advertências, não capture muito com muita freqüência, apenas capture consultas longas, ou seja, duração > x segundos ou cpu > xx ou lê > xxxx; muito pouco impacto, e você verá rapidamente as consultas que mais se beneficiariam do ajuste.

    
por 12.05.2010 / 02:39