Ist es in Ordnung, perfmon auf Produktionsservern auszuführen? Und warum?

Oder sollte perfmon auf einen Dev / QA-Server mit Auslastungstests beschränkt sein, die die Produktionsaktivität simulieren?

Ich möchte perfmon zwei Tage lang ausführen ( wie es SQL Server-Meister Brent Ozar vorschlägt ), um einen Überblick über die Datenbankleistung meiner Webanwendung zu erhalten.

SQL Server und die meisten anderen Produkte generieren die Leistungsindikatoren ständig, unabhängig davon, ob Listener vorhanden sind oder nicht (ignorieren Sie die Startoption -x). Die Zählerrückverfolgung ist für die zu überwachende Anwendung vollständig transparent. Es gibt einen gemeinsam genutzten Speicherbereich, in den die überwachte Anwendung schreibt und aus dem Überwachungssitzungen die Rohwerte in dem angegebenen Intervall lesen. Die einzigen Kosten, die mit der Überwachung verbunden sind, sind die Kosten des Überwachungsprozesses und die Kosten für das Schreiben der abgetasteten Werte auf die Festplatte. Wenn Sie ein angemessenes Erfassungsintervall (normalerweise 15 Sekunden) und eine moderate Anzahl von Zählern (50-100) auswählen und in ein Binärdateiformat schreiben, hat dies normalerweise keine Auswirkungen auf das überwachte System.

Aber ich würde gegen die Verwendung von Perfmon empfehlen (wie in perfmon.exe). Machen Sie sich stattdessen mit logman.exe vertraut (siehe Beschreibung der Tools Logman.exe, Relog.exe und Typeperf.exe) . Auf diese Weise binden Sie die Erfassungssitzung nicht an Ihre Sitzung. Logman ist ein Befehlszeilentool und kann in Skripts und geplanten Jobs zum Starten und Beenden von Erfassungssitzungen verwendet werden.

Es ist nichts falsch daran, Perfmon auf Produktionsboxen laufen zu lassen. Es ist relativ zurückhaltend und kann viele gute Informationen für Sie sammeln. Und wie würden Sie Produktionslasten genau simulieren, wenn Sie keine Analyse auf dem Produktionsserver durchführen würden? Von Brent Ozar in Ihrem eigenen Link:

Lassen Sie Perfmon ein oder zwei Tage laufen, um einen guten Überblick über die Serveraktivität zu erhalten. Es ist nicht so invasiv auf dem zu überwachenden SQL Server, und die detaillierten Ergebnisse werden sich auszahlen. Je mehr Daten wir haben, desto besser können wir die Perfmon-Ergebnisse analysieren.

Ich habe perfmon auf einer Reihe von Produktions-Exchange-Boxen ohne nachteilige Auswirkungen ausgeführt.

Seitdem habe ich Clint Huffman , der PAL, ein Dienstprogramm zum Analysieren von Perfmon-Protokollen, einmal in einem Podcast geschrieben hat, zugehört. Ich habe auf allen unseren Produktionsanwendungsservern den so genannten Flight Recorder eingerichtet. Diese Vorgehensweise ist sehr praktisch, um Probleme zu diagnostizieren und Trends zu überwachen.

Unten ist das Skript aufgeführt, mit dem ich einen automatisch startenden Perfmon Collector mit Protokolllöschung einrichte. Auf Wunsch kann eine Datei mit zu sammelnden Leistungsindikatoren (einer pro Zeile) oder eine PAL-Schwellenwert-XML-Datei eingespeist werden. Ich benutze gerne die PAL-Threshold-Dateien.

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

Wir machen das ziemlich oft. Dies ist auch für die Erstellung einer Baseline in der realen Umgebung von entscheidender Bedeutung, damit Sie später vergleichen können, ob es Probleme gibt oder ob Sie eine Kapazitätsstudie durchführen müssen.

Ich empfehle jedoch, ein Intervall von 10 Sekunden nicht zu unterschreiten. Wenn Sie viele Objekte / Zähler sammeln und das Intervall zu häufig ist, kann sich dies auf den Betrieb auswirken.

Microsoft verfügt über einen PerfMon-Assistenten, der die Aufgabe für Sie einrichtet.

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

In einer idealen Welt, in der ein Produktionsserver genau das spiegelt, was ein Entwicklungsserver tut, und auch ein genaues Duplikat des Entwicklungsservers ist, sollte perfmon auf dem Produktionsserver niemals erforderlich sein, da die Ergebnisse mit denen auf dem Entwicklungsserver identisch wären. Natürlich passiert diese mythische Situation nie, daher müssen wir perfmon auf Produktionsservern ausführen, und daran ist absolut nichts auszusetzen. Unter anderem müssen wir möglicherweise perfmon und andere Tools verwenden, um zu erfahren, warum sich der Produktionsserver nicht wie der Entwicklungsserver verhält.

Warum perfmonieren? Ich meine, neuere Versionen von SQL Server haben ihre eigene Methode, dies zu tun, einschließlich des Aufbaus eines (zentralen) Data Warehouse mit Leistungsindikatoren, die dann abgefragt und abgeglichen werden können. Es macht keinen Sinn, dort perfmon zu laufen.

Ich bin wie immer erstaunt über alle Beiträge von Leuten, die die Dokumentation offensichtlich nie gelesen haben;)

http://www.simple-talk.com/sql/learn-sql-server/sql-server-2008-performance-data-collector/ ist ein guter Anfang. IMHO sollte das auf fast jedem SQL-Server funktionieren, der für Produktionszwecke verwendet wird.

Nichts ist falsch daran, Perfmon auszuführen, wie von vielen vorgeschlagen, aber ich würde stattdessen Profiler ausführen oder zusätzlich mit den gleichen Einschränkungen nicht zu oft erfassen, sondern nur lange laufende Abfragen erfassen, dh Dauer> x Sekunden oder CPU> xx , oder lautet> xxxx; Sehr geringe Auswirkung, und Sie werden schnell die Abfragen sehen, die am meisten von der Optimierung profitieren würden.