چرا Windows Server کند شده؟ عیب‌یابی CPU، RAM، Disk و Network با Performance Monitor

جواب کوتاه: اگر Windows Server کند شده است، قبل از Restart یا افزایش منابع مشخص کنید گلوگاه واقعاً CPU، RAM، Disk یا Network است. برای این کار یک Baseline بگیرید، Counterهای مرتبط را در Performance Monitor ثبت کنید و داده‌های بازه‌ای را که کندی رخ داده با وضعیت عادی مقایسه کنید. یک جهش چندثانیه‌ای به‌تنهایی دلیل مشکل نیست.

سناریو و پیش‌نیاز

این روش برای حالتی مناسب است که RDP، فایل‌سرور، IIS، دیتابیس یا سرویس‌های دیگر روی Windows Server گاهی یا دائماً کند می‌شوند. زمان تقریبی بروز کندی را یادداشت کنید و قبل از هر تغییر، وضعیت فعلی را ثبت کنید. اگر سرور Production است، تغییر سرویس‌ها، Driverها یا تنظیمات منابع را فقط در Maintenance Window انجام دهید.

مرحله ۱: یک Snapshot سریع بگیرید

ابتدا از PowerShell وضعیت کلی را ببینید:

Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name,Id,CPU,WorkingSet
Get-Counter 'Processor(_Total)\% Processor Time'
Get-Counter 'Memory\Available MBytes'
Get-Counter 'PhysicalDisk(_Total)\Avg. Disk sec/Transfer'
Get-Counter 'Network Interface(*)\Bytes Total/sec'

Snapshot برای پیدا کردن سرنخ مفید است، اما برای کندی‌های مقطعی کافی نیست. برای نتیجه قابل اتکا باید Counterها را در طول زمان ثبت کنید.

مرحله ۲: Performance Monitor را برای Baseline آماده کنید

در Run دستور perfmon را اجرا کنید. از مسیر Performance Monitor می‌توانید Counterها را زنده ببینید. برای مشکل‌های مقطعی بهتر است از Data Collector Sets استفاده کنید تا داده در زمان بروز کندی ثبت شود.

Counterهای پایه:

• Processor(_Total)\% Processor Time
• System\Processor Queue Length
• Memory\Available MBytes
• Memory\Pages/sec
• PhysicalDisk(*)\Avg. Disk sec/Read و Avg. Disk sec/Write
• PhysicalDisk(*)\Current Disk Queue Length
• Network Interface(*)\Bytes Total/sec
• Network Interface(*)\Output Queue Length

Counterها را در کنار رفتار واقعی سرویس تحلیل کنید؛ یک عدد ثابت برای همه سخت‌افزارها و Workloadها معیار قطعی نیست.

مرحله ۳: عیب‌یابی CPU

اگر CPU در زمان کندی برای مدت معناداری بالا می‌ماند، Process مصرف‌کننده را پیدا کنید:

Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 Name,Id,CPU,Threads,WorkingSet
typeperf "Processor(_Total)\% Processor Time" "System\Processor Queue Length" -si 5 -sc 12

مصرف CPU را با Queue Length و Process مربوطه کنار هم ببینید. CPU بالا می‌تواند ناشی از Application، Antivirus scan، Windows Update، Backup، Compression یا Workload واقعی باشد. قبل از Kill کردن Process، وابستگی آن به سرویس‌های Production را بررسی کنید.

مرحله ۴: عیب‌یابی RAM و Paging

کم بودن RAM فقط با درصد Memory Usage تشخیص داده نمی‌شود. Available MBytes، Paging و Working Set پردازش‌ها را هم بررسی کنید:

Get-Counter 'Memory\Available MBytes','Memory\Pages/sec','Paging File(_Total)\% Usage'
Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 15 Name,Id,@{N='WorkingSetMB';E={[math]::Round($_.WorkingSet64/1MB,1)}},@{N='PrivateMB';E={[math]::Round($_.PrivateMemorySize64/1MB,1)}}

اگر Available Memory مرتب افت می‌کند و هم‌زمان Paging و مصرف یک Process رشد می‌کند، Memory leak یا کمبود واقعی RAM را بررسی کنید. صرفاً بزرگ‌تر کردن Pagefile علت اصلی را رفع نمی‌کند.

مرحله ۵: عیب‌یابی Disk و Storage Latency

Disk Usage صددرصد در Task Manager به‌تنهایی کافی نیست. Latency خواندن/نوشتن و Queue را ثبت کنید:

typeperf "PhysicalDisk(_Total)\Avg. Disk sec/Read" "PhysicalDisk(_Total)\Avg. Disk sec/Write" "PhysicalDisk(_Total)\Current Disk Queue Length" -si 5 -sc 12
Get-Counter 'LogicalDisk(*)\% Free Space'

اگر Latency دقیقاً هنگام کندی بالا می‌رود، منبع I/O را بررسی کنید: Backup، Antivirus، Logهای حجیم، دیتابیس، Storage مجازی، RAID/SAN یا Host. آستانه‌های عمومی را حکم قطعی ندانید؛ Baseline همان Storage و مشخصات سازنده مهم‌تر است.

مرحله ۶: عیب‌یابی Network

برای تشخیص اینکه کندی واقعاً شبکه‌ای است، Throughput، Error/Discard و وضعیت TCP را کنار هم ببینید:

Get-NetAdapter | Select-Object Name,Status,LinkSpeed
Get-NetAdapterStatistics | Format-Table Name,ReceivedBytes,SentBytes,ReceivedPacketErrors,OutboundPacketErrors -Auto
Get-Counter 'Network Interface(*)\Bytes Total/sec','Network Interface(*)\Packets Received Errors','Network Interface(*)\Packets Outbound Errors'
Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending | Select-Object Count,Name

اگر فقط یک سرویس شبکه کند است، قبل از مقصر دانستن NIC، خود سرویس، DNS، Firewall و مسیر ارتباطی را جداگانه تست کنید. برای مشکلات مرتبط می‌توانید راهنمای عیب‌یابی DNS در Windows Server و رفع مشکل RDP در Windows Server را هم بررسی کنید.

مرحله ۷: ثبت Counterها با typeperf

برای گرفتن نمونه کوتاه بدون باز نگه داشتن PerfMon:

mkdir C:\PerfLogs\OneServer
typeperf "Processor(_Total)\% Processor Time" "Memory\Available MBytes" "PhysicalDisk(_Total)\Avg. Disk sec/Transfer" "Network Interface(*)\Bytes Total/sec" -si 5 -sc 120 -f CSV -o C:\PerfLogs\OneServer\baseline.csv

این نمونه هر ۵ ثانیه داده می‌گیرد. مدت نمونه‌برداری را متناسب با زمان رخ دادن مشکل تنظیم کنید.

مرحله ۸: Data Collector Set با logman

برای کندی‌هایی که باید در بازه طولانی‌تری شکار شوند، می‌توانید Collector بسازید:

logman create counter OneServer-Perf -o "C:\PerfLogs\OneServer\perf" -f bincirc -max 500 -si 00:00:05 -c "Processor(_Total)\% Processor Time" "Memory\Available MBytes" "PhysicalDisk(_Total)\Avg. Disk sec/Transfer" "Network Interface(*)\Bytes Total/sec"
logman start OneServer-Perf

بعد از بازتولید مشکل:

logman stop OneServer-Perf
logman query OneServer-Perf

فایل ثبت‌شده را در Performance Monitor باز کنید و زمان دقیق کندی را با Counterها تطبیق دهید.

چطور گلوگاه را از هم تفکیک کنیم؟

• CPU: مصرف پایدار CPU همراه با Process مشخص و Queue رو به رشد.
• RAM: افت Available Memory همراه با Paging یا رشد مداوم Working Set/Private Bytes.
• Disk: افزایش Latency و Queue هم‌زمان با I/O یک Workload.
• Network: Error/Discard، اشباع لینک یا مشکل یک مسیر/سرویس شبکه‌ای در همان بازه.

ممکن است گلوگاه زنجیره‌ای باشد؛ مثلاً کمبود RAM باعث Paging و در نتیجه افزایش I/O دیسک شود. بنابراین Counterها را جدا از هم تفسیر نکنید.

Verify؛ از کجا بفهمیم مشکل واقعاً رفع شده؟

پس از اصلاح علت، همان Workload و همان Counterها را دوباره در بازه مشابه ثبت کنید. معیار موفقیت فقط «حس سریع‌تر شدن» نیست؛ باید زمان پاسخ سرویس بهتر شود و Counter مرتبط نیز نسبت به Baseline مشکل‌دار به وضعیت طبیعی برگردد.

typeperf "Processor(_Total)\% Processor Time" "Memory\Available MBytes" "PhysicalDisk(_Total)\Avg. Disk sec/Transfer" -si 5 -sc 60

Event Viewer و لاگ خود Application را هم در همان Timestamp بررسی کنید.

Rollback و Recovery

خود PerfMon، typeperf و Data Collector Set ابزار مانیتورینگ هستند و تنظیم منابع سرور را تغییر نمی‌دهند. اگر Collector دیگر لازم نیست:

logman stop OneServer-Perf
logman delete OneServer-Perf

اگر در جریان عیب‌یابی تنظیم Application، Service، Driver، Antivirus exclusion یا منابع VM را تغییر داده‌اید، فقط همان تغییر را به مقدار ثبت‌شده قبل از تست برگردانید. از چند تغییر هم‌زمان خودداری کنید تا علت و اثر قابل تشخیص بماند.

خطاهای رایج در عیب‌یابی کندی Windows Server

• Restart کردن سرور قبل از جمع‌آوری Evidence و از دست دادن سرنخ‌ها.
• نتیجه‌گیری از یک Snapshot کوتاه Task Manager.
• افزایش RAM یا CPU بدون مشخص کردن Bottleneck.
• تفسیر یک Counter بدون مقایسه با Counterهای مرتبط و Baseline.
• نادیده گرفتن Host/Storage در ماشین مجازی.
• اجرای چند تغییر هم‌زمان و نامشخص شدن علت بهبود یا خرابی.

اگر فقط یک سرویس کند است چه کنیم؟

اگر کل سرور کند نیست، عیب‌یابی را روی همان سرویس متمرکز کنید. برای مثال کندی Share می‌تواند با SMB/Storage/Network مرتبط باشد، RDP می‌تواند مسیر شبکه یا Session را درگیر کند و DNS کند می‌تواند روی چند سرویس اثر زنجیره‌ای بگذارد. در این حالت راهنمای DHCP در Windows Server نیز برای مشکلات دریافت IP و شبکه Clientها مفید است.

جمع‌بندی

برای رفع کندی Windows Server ابتدا Evidence جمع کنید، سپس مشخص کنید فشار اصلی روی CPU، RAM، Disk یا Network است. Performance Monitor، typeperf و logman کمک می‌کنند کندی مقطعی را به داده قابل مقایسه تبدیل کنید. بعد از اصلاح علت، همان Counterها را دوباره اندازه بگیرید تا نتیجه واقعاً Verify شود. اگر مشکل از کمبود پایدار منابع زیرساخت است، مشخصات و منابع سرور مجازی وان‌سرور را متناسب با Workload بررسی کنید.

منابع رسمی

• Microsoft Learn: Troubleshoot performance problems in Windows
• Microsoft Learn: typeperf
• Microsoft Learn: logman