Назад | Перейти на главную страницу

Можно ли запускать perfmon на производственных серверах? И почему?

Или следует ограничить perfmon сервером Dev / QA с нагрузочными тестами, имитирующими производственную деятельность?

Я бы хотел запустить perfmon на два дня (как мастер Sql Server Брент Озар предлагает), чтобы получить общее представление о производительности базы данных моего веб-приложения.

SQL Server и большинство других продуктов постоянно генерируют счетчики, независимо от того, есть ли слушатели или нет (игнорируя параметр запуска -x). Отслеживание счетчика полностью прозрачно для отслеживаемого приложения. Существует область общей памяти, в которую отслеживаемое приложение записывает и из которой сеансы мониторинга считывают необработанные значения с заданным интервалом. Таким образом, единственная стоимость, связанная с мониторингом, - это стоимость процесса мониторинга и стоимость записи выборочных значений на диск. Выбор приличного интервала сбора данных (я обычно выбираю 15 секунд) и умеренного количества счетчиков (50–100), а также запись в двоичный формат файла обычно не влияет на наблюдаемую систему.

Но я бы не рекомендовал использовать Perfmon (как в perfmon.exe). Вместо этого ознакомьтесь с logman.exe, см. Описание инструментов Logman.exe, Relog.exe и Typeperf.exe. Таким образом, вы не привязываете сеанс сбора к вашему сеансу. Logman, являясь инструментом командной строки, может использоваться в сценариях и запланированных заданиях для запуска и остановки сеансов сбора данных.

Нет ничего плохого в том, чтобы запускать perfmon на производственных устройствах. Он относительно скромный и может собрать для вас много полезной информации. И как бы вы точно смоделировали производственные нагрузки, если бы не выполняли некоторый анализ на производственном сервере? От Брента Озара по вашей ссылке:

Дайте Perfmon поработать день или два, чтобы получить хорошее представление о работе сервера. Это не так агрессивно для отслеживаемого SQL Server, и подробные результаты окупятся. Чем больше у нас данных, тем лучше мы сможем проанализировать результаты Perfmon.

Я запустил perfmon на нескольких производственных ящиках Exchange без каких-либо побочных эффектов.

С тех пор как я слушал Клинт Хаффман, кто написал PAL утилита для анализа журналов Perfmon в подкасте один раз. Я установил то, что я называю Flight Recorder, на всех наших производственных серверах приложений. Эта практика очень пригодилась для диагностики проблем и отслеживания тенденций.

Ниже приведен сценарий, который я использую для настройки автозапуска Perfmon Collector с очисткой журнала. При желании его можно передать в файл со списком счетчиков производительности для сбора (по одному на строку) или XML-файл PAL Threshold. Мне нравится использовать файлы 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

Мы делаем это довольно часто. Это также важно для установления базового уровня в реальной среде, чтобы вы могли позже сравнить, если есть проблемы или вам нужно выполнить исследование емкости.

Однако я рекомендую не опускаться ниже 10-секундного интервала. Если вы собираете много объектов / счетчиков и интервал слишком частый, это может повлиять на работу.

У Microsoft есть мастер PerfMon Wizard, который настроит задачу за вас.

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

В идеальном мире, где производственный сервер точно отражает то, что делает сервер разработки, а также является точной копией сервера разработки, на производственном сервере никогда не должен требоваться perfmon, поскольку результаты будут такими же, как и на сервере разработки. Конечно, этой мифической ситуации никогда не бывает, поэтому нам нужно запустить perfmon на производственных серверах, и в этом нет абсолютно ничего плохого. Помимо прочего, нам может потребоваться использовать perfmon и другие инструменты, чтобы узнать, почему рабочий сервер не ведет себя так же, как сервер разработки.

Почему перфмон? Я имею в виду, что в последних версиях SQL-сервера есть свой собственный метод выполнения этого, включая создание (центрального) хранилища данных счетчиков производительности, которые затем можно запрашивать и сообщать. Там нет смысла запускать perfmon.

Меня, как всегда, удивляют все сообщения здесь людей, которые явно никогда не читали документацию;)

http://www.simple-talk.com/sql/learn-sql-server/sql-server-2008-performance-data-collector/ хорошее начало. IMHO, который должен работать почти на каждом сервере sql, который используется в производственных целях.

Нет ничего плохого в запуске Perfmon, как предлагали многие, но я бы запустил Profiler вместо этого или в дополнение, с теми же предостережениями, не захватывайте слишком много слишком часто, просто фиксируйте длинные запросы, то есть продолжительность> x секунд или cpu> xx , или читается как> xxxx; очень небольшое влияние, и вы быстро увидите запросы, для которых настройка будет наиболее полезной.