راهنمای جامع پایش منابع سرور: CPU، رم، دیسک و شبکه

«سرور کند است» احتمالاً رایج‌ترین جمله‌ای است که یک مدیر شبکه می‌شنود، و مبهم‌ترینش. کند یعنی CPU پر است؟ رم کم است و سیستم مدام از دیسک صفحه می‌خواند؟ دیسک زیر بار I/O خفه شده؟ شبکه اشباع است؟ یا اصلاً سرور سالم است و مشکل در پایگاه داده یا اپلیکیشن است؟ بدون داده، جواب این سؤال حدس است، و حدس معمولاً به خرید رم بیشتر ختم می‌شود، که گاهی کمک می‌کند و اغلب نه.

این راهنما دربارهٔ پایش چهار منبع اصلی سرور است: برای هر کدام، کدام سنجه‌ها واقعاً معنا دارند، کدام گمراه‌کننده‌اند، چه مقداری نگران‌کننده است، و وقتی مشکلی هست چطور عاملش را پیدا کنیم. دستورها برای ویندوز (PowerShell 5.1) و لینوکس هر دو آمده‌اند. جزئیات خاص هر سیستم‌عامل را در راهنمای پایش ویندوز سرور و راهنمای پایش سرور لینوکس آورده‌ام.

چارچوب: مصرف، اشباع و خطا

بهترین چارچوب ساده‌ای که برای بررسی منابع می‌شناسم، روش USE از برندن گرگ است. برای هر منبع سه سؤال بپرسید:

• Utilization (مصرف): چه درصدی از زمان یا ظرفیت منبع مشغول است؟
• Saturation (اشباع): چقدر کار منتظر این منبع است؟ صف چقدر طولانی است؟
• Errors (خطا): آیا منبع خطا می‌دهد؟

نکتهٔ مهم این چارچوب، سؤال دوم است. مصرف ۱۰۰٪ به‌تنهایی مشکل نیست؛ مشکل وقتی است که کار منتظر می‌ماند. CPUی که ۱۰۰٪ مشغول است و صفش خالی است، دارد با تمام ظرفیت کار می‌کند و هیچ‌کس منتظر نیست. CPUی که ۸۰٪ مشغول است ولی بیست نخ منتظرش‌اند، کاربران را کند می‌کند.

CPU

CPU ساده‌ترین منبع برای اندازه‌گیری و راحت‌ترین برای بد فهمیدن است. چند نکته که بارها دیده‌ام نادیده گرفته می‌شوند:

میانگین کل، هسته‌های تک را پنهان می‌کند. روی سروری با ۱۶ هسته، پروسسی که فقط یک نخ دارد و آن را کامل اشغال کرده، مصرف کل را حدود ۶٪ نشان می‌دهد؛ در حالی که همان پروسس با تمام توان کار می‌کند و کند است. اگر اپلیکیشنی کند است ولی CPU کل پایین، مصرف هر هسته را ببینید.

زمان کرنل در برابر کاربر. اگر بخش بزرگی از مصرف CPU در حالت کرنل (Privileged Time در ویندوز، sy در لینوکس) است، مشکل معمولاً در درایور، فیلتر آنتی‌ویروس، یا تعداد بسیار زیاد عملیات I/O کوچک است، نه در اپلیکیشن.

steal time روی ماشین مجازی. ستون st در top لینوکس یعنی زمانی که ماشین می‌خواست CPU داشته باشد ولی hypervisor آن را به ماشین دیگری داد. در ویندوز مهمان معادل مستقیمی نیست و باید از سمت میزبان (مثلاً CPU Ready در VMware) نگاه کرد. ماشین مجازی‌ای که CPU داخلش ۵۰٪ است ولی کند است، شاید روی میزبانی شلوغ است.

# Windows: top CPU consumers right now (CPU column is cumulative seconds; sample twice to compare)
Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, Id, CPU, WorkingSet64

# Windows: per-process CPU % over a sample
Get-Counter '\Process(*)\% Processor Time' -SampleInterval 2 -MaxSamples 1 |
  Select-Object -ExpandProperty CounterSamples |
  Where-Object { $_.InstanceName -notin '_total','idle' } |
  Sort-Object CookedValue -Descending | Select-Object -First 10 InstanceName, CookedValue

# Linux
top -b -n 1 -o %CPU | head -n 20
mpstat -P ALL 2 3        # per-core usage (sysstat)
pidstat -u 2 3           # per-process CPU over time

توجه کنید % Processor Time هر پروسس در ویندوز بر اساس یک هسته است؛ پروسسی که چهار هسته را کامل گرفته ۴۰۰٪ نشان داده می‌شود. برای مقایسه با کل، بر تعداد هسته‌ها تقسیم کنید.

رم

رم بیشترین سوءتفاهم را دارد، چون هر دو سیستم‌عامل رم خالی را هدر می‌دانند و برای کش استفاده می‌کنند. در لینوکس، ستون available در free را ببینید نه free. در ویندوز، شمارندهٔ Available MBytes که رم Standby (کش) را هم شامل می‌شود معتبرتر از درصد «In use» در Task Manager است.

دو الگوی مهم در نمودار رم:

• پله‌ای و پایدار. مصرف بعد از ریبوت بالا می‌رود و در سطحی می‌ماند. این معمولاً طبیعی است؛ کش‌ها پر شده‌اند و سرویس‌ها به اندازهٔ کاری‌شان رسیده‌اند.
• شیب ثابت رو به بالا. مصرف روز به روز و بدون برگشت بالا می‌رود تا ریبوت یا ری‌استارت سرویس، و بعد دوباره همان شیب. این نشانهٔ کلاسیک نشت حافظه (memory leak) است. نمودار هفت‌روزه یا سی‌روزه آن را به‌روشنی نشان می‌دهد؛ نمودار یک‌ساعته هرگز.

# Windows: top memory consumers (private bytes is closer to "what this process really owns")
Get-Process | Sort-Object PrivateMemorySize64 -Descending |
  Select-Object -First 10 Name, Id, @{n='PrivateMB';e={[math]::Round($_.PrivateMemorySize64/1MB)}}

# Windows: page file usage
Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage

# Linux
free -m
ps -eo pid,comm,rss --sort=-rss | head -n 10
vmstat 5 5

دربارهٔ page file و swap: وجودشان مشکل نیست و استفادهٔ کمشان هم مشکل نیست. سیستم‌عامل صفحه‌هایی را که مدت‌ها استفاده نشده‌اند بیرون می‌برد تا رم برای کارهای فعال آزاد شود. مشکل وقتی است که نرخ خواندن و نوشتن صفحه بالا و پایدار باشد؛ یعنی سیستم مدام صفحه‌ای را بیرون می‌برد و دوباره لازمش دارد (thrashing). آن‌وقت همه‌چیز به سرعت دیسک کند می‌شود.

یک استثنای مهم: پایگاه داده‌ها. SQL Server به‌طور پیش‌فرض هرچه رم پیدا کند برای buffer pool می‌گیرد و درصد مصرف رم سرورش همیشه نزدیک ۹۵٪ است. این مشکل نیست، به شرطی که max server memory طوری تنظیم شده باشد که چند گیگابایت برای سیستم‌عامل بماند. هشدار رم با آستانهٔ معمولی روی سرور SQL، هشدار دائمی بی‌معنا می‌سازد؛ برای این سرورها قانون جدا تعریف کنید. پایش درونی خود SQL Server موضوع DBMug است.

دیسک: فضا و کارایی دو موضوع جدا هستند

فضا

پر شدن دیسک شاید رایج‌ترین علت قطعی‌های قابل‌پیشگیری باشد. سه توصیه:

• هر درایو و هر فایل‌سیستم را جدا پایش کنید. میانگین یا جمع، درایو پرشده را پنهان می‌کند.
• روند را ببینید، نه فقط مقدار. دیسکی که هفته‌ای ۱٪ پر می‌شود و دیسکی که ساعتی ۱٪، با یک درصد فعلی، دو وضعیت کاملاً متفاوت‌اند. نمودار سی یا نود روزه را نگاه کنید و با یک خط‌کش ساده تخمین بزنید کِی به ۱۰۰٪ می‌رسد.
• روی لینوکس inode را هم پایش کنید.

کارایی

دیسکی که جای خالی زیادی دارد ممکن است کندترین بخش سرور باشد. معتبرترین سنجهٔ کارایی دیسک، تأخیر است: هر عمل خواندن یا نوشتن به‌طور میانگین چقدر طول می‌کشد. IOPS و throughput (مگابایت بر ثانیه) می‌گویند دیسک چقدر کار می‌کند؛ تأخیر می‌گوید کاربر چقدر منتظر می‌ماند.

این اعداد تقریبی‌اند و برای شروع؛ مهم‌تر از عدد مطلق، مقایسه با حالت عادی همان سرور است. اگر تأخیر یک دیسک SAN همیشه ۳ میلی‌ثانیه بوده و امروز ۴۰ است، چیزی عوض شده، حتی اگر ۴۰ در جدولی «قابل قبول» باشد.

# Windows: latency (seconds) and queue per logical disk
Get-Counter '\LogicalDisk(*)\Avg. Disk sec/Read','\LogicalDisk(*)\Avg. Disk sec/Write',
            '\LogicalDisk(*)\Current Disk Queue Length' -SampleInterval 5 -MaxSamples 3

# Linux: r_await / w_await in ms, aqu-sz = average queue size
iostat -x 5 3
iotop -o           # which process is doing I/O (needs root)

تأخیر بالا همراه با صف بلند یعنی دیسک بیش از ظرفیتش کار دارد؛ پیدا کنید چه کسی (پروسسی که بیشترین I/O را دارد) و کِی (بکاپ، اسکن آنتی‌ویروس، جاب شبانه). تأخیر بالا با صف کوتاه بیشتر به مشکل مسیر ذخیره‌سازی اشاره دارد: کابل، کنترلر، شبکهٔ SAN، یا دیسکی در آرایه که در حال خراب شدن است. رویدادهای 153 و 129 در لاگ System ویندوز در این وضعیت سرنخ مهمی‌اند.

شبکه

پایش شبکهٔ سرور معمولاً به ترافیک ورودی و خروجی خلاصه می‌شود، که لازم است ولی کافی نیست. چهار چیز را ببینید:

• ترافیک نسبت به ظرفیت. کارت ۱ گیگابیتی که به‌طور پایدار ۹۰۰ مگابیت کار می‌کند، اشباع است. دقت کنید ترافیک معمولاً به بایت گزارش می‌شود و ظرفیت کارت به بیت؛ ۱۲۵ مگابایت بر ثانیه یعنی ۱ گیگابیت.
• خطا و دورریز. خطای دریافت روی کارت شبکه تقریباً همیشه مشکل فیزیکی یا درایور است: کابل، پورت سوییچ، تنظیم سرعت و duplex.
• تعداد اتصال‌های TCP. جهش ناگهانی ممکن است ترافیک واقعی، نشت اتصال در اپلیکیشن (اتصال‌هایی که بسته نمی‌شوند)، یا حمله باشد. تعداد زیاد اتصال در حالت TIME_WAIT یا CLOSE_WAIT نشانهٔ مشکل در اپلیکیشن است.
• الگوی ترافیک خروجی. سروری که شب‌ها ده‌ها گیگابایت داده به اینترنت می‌فرستد و نباید بفرستد، ممکن است در حال بیرون بردن داده پیش از حملهٔ باج‌افزار باشد.

# Windows
Get-NetAdapterStatistics | Select-Object Name, ReceivedBytes, SentBytes, ReceivedPacketErrors, OutboundPacketErrors
Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending | Select-Object Count, Name

# Linux
ip -s link
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn
sar -n DEV 5 3

آستانه‌های پیشنهادی

یادتان باشد هر آستانهٔ سنجه بدون شرط مدت، منبع هشدار کاذب است. منطق مدت، شدت و ساعت سکوت را مفصل در راهنمای هشدار در پایش سرور نوشته‌ام.

عیب‌یابی گام‌به‌گام وقتی سرور کند است

ترتیبی که خودم دنبال می‌کنم، از ارزان به گران:

1. کِی شروع شد؟ نمودار ۲۴ ساعته یا ۷ روزه را ببینید. شروع ناگهانی معمولاً تغییری پشتش دارد: آپدیت، نسخهٔ جدید اپلیکیشن، جاب تازه. شروع تدریجی بیشتر رشد بار یا نشت است.
2. کدام منبع؟ چهار نمودار CPU، رم، دیسک و شبکه را کنار هم بگذارید. معمولاً یکی آشکارا غیرعادی است.
3. اشباع یا فقط مصرف؟ صف و تأخیر را ببینید، نه فقط درصد.
4. چه کسی؟ پروسسی که بیشترین سهم را در آن منبع دارد.
5. چرا؟ لاگ همان پروسس و رویدادهای سیستم در همان بازهٔ زمانی.

گام اول را دست‌کم نگیرید. بیشترین زمانی که در عیب‌یابی هدر رفته دیده‌ام، صرف بررسی وضعیت «الان» سروری شده که مشکلش دیشب بود. بدون دادهٔ تاریخی، عیب‌یابی منابع تا حد زیادی حدس است.

دو سناریوی واقعی از نمودار تا علت

سناریوی اول: کندی هر روز ساعت ده صبح. کاربران یک اپلیکیشن داخلی هر روز حدود ساعت ده از کندی شکایت می‌کردند. CPU و رم سرور اپلیکیشن در آن ساعت عادی بود. نمودار تأخیر دیسک سرور پایگاه داده اما هر روز از ساعت ۹:۴۵ تا ۱۰:۳۰ از حدود ۲ میلی‌ثانیه به بیش از ۵۰ می‌رسید. پیدا کردن عامل ده دقیقه طول کشید: اسکن کامل زمان‌بندی‌شدهٔ آنتی‌ویروس که کسی روی «روزانه ساعت ۹:۴۵» گذاشته بود و پوشهٔ فایل‌های پایگاه داده را هم استثنا نکرده بود. نه رم بیشتر لازم بود، نه دیسک سریع‌تر؛ فقط جابه‌جایی زمان اسکن و اضافه کردن استثناهای درست.

سناریوی دوم: سرویسی که هر دو هفته از کار می‌افتاد. یک سرویس ویندوزی هر ده تا چهارده روز یک بار با خطای کمبود حافظه متوقف می‌شد و ری‌استارت مشکل را تا دفعهٔ بعد حل می‌کرد. نمودار یک‌روزه رم چیز غیرعادی‌ای نشان نمی‌داد. نمودار سی‌روزه اما یک دندان‌اره‌ای کامل بود: شیب ثابت بالا رونده از هر ری‌استارت تا لحظهٔ از کار افتادن. نشت حافظه در خود سرویس بود و باید به تیم توسعه گزارش می‌شد؛ تا اصلاح آن، یک ری‌استارت هفتگی برنامه‌ریزی‌شده در ساعت خلوت جلوی قطعی را گرفت. درس هر دو سناریو یکی است: نمودار در بازهٔ زمانی درست، علت را تقریباً خودش نشان می‌دهد.

برنامه‌ریزی ظرفیت: از واکنش به پیش‌بینی

دادهٔ پایش منابع فقط برای حادثه نیست. همین نمودارها، اگر چند ماه نگه داشته شوند، به سؤال‌هایی جواب می‌دهند که بودجهٔ سال بعد را تعیین می‌کنند:

• کدام سرورها با روند فعلی، در شش ماه آینده دیسک کم می‌آورند؟
• کدام سرورها منابع زیادی دارند که هرگز استفاده نمی‌شوند؟ ماشین مجازی‌ای که ۱۶ هسته دارد و هرگز از ۱۰٪ بالاتر نرفته، می‌تواند کوچک شود و منابعش به ماشین دیگری برسد.
• بار در کدام ساعت‌ها و روزها اوج می‌گیرد؟ آیا جاب‌های سنگین را می‌شود به ساعت‌های خلوت برد؟
• رشد مصرف رم و CPU با رشد کاربران یا داده متناسب است یا سریع‌تر؟ اگر سریع‌تر، جایی ناکارآمدی هست.

برای این کار، نمودار بلندمدت لازم است: دادهٔ خام چند روزه کافی نیست. سامانه‌هایی که میانگین ساعتی را تا بیش از یک سال نگه می‌دارند، امکان مقایسهٔ امسال با پارسال را می‌دهند. اگر از ابزاری استفاده می‌کنید که فقط چند روز نگه می‌دارد، دست‌کم ماهانه خلاصه‌ای از بیشینه و میانگین هر سرور را جایی ثبت کنید.

اشتباه‌های رایج

در ServerMug سنجه‌های منابع (CPU، load، رم، swap یا page file، فضا و inode هر درایو، خواندن و نوشتن دیسک، ترافیک و خطای هر کارت شبکه، اتصال‌های TCP) هر ۱۵ ثانیه خوانده می‌شوند و نمودارها از یک ساعت تا ۹۰ روز در صفحهٔ هر سرور در دسترس‌اند؛ چیدمان این نمودارها را در نمای کلی، صفحهٔ سرور و نمودارها توضیح داده‌ایم. ولی هر ابزاری که دارید، ارزش داده‌های منابع در کنار هم دیدنشان و در طول زمان دیدنشان است. یک عدد لحظه‌ای تقریباً هیچ‌وقت داستان کامل را نمی‌گوید.

منابع و مطالعهٔ بیشتر

• روش USE از برندن گرگ — چارچوب مصرف، اشباع و خطا با فهرست سنجه‌ها برای لینوکس و سیستم‌عامل‌های دیگر.
• راهنمای تنظیم کارایی ویندوز سرور — راهنمای رسمی مایکروسافت برای زیرسیستم‌های CPU، حافظه، ذخیره‌سازی و شبکه.
• مستندات کرنل لینوکس دربارهٔ /proc — معنای دقیق فیلدهای meminfo، stat و diskstats که ابزارهای پایش از آن‌ها می‌خوانند.
• Performance Monitor در ویندوز سرور — ابزار رسمی دیدن و ثبت شمارنده‌های کارایی.