FutureForgeFutureForge

خدمات FutureForge

  • طراحی و ساخت محصولاز شناخت نیاز تا انتشار محصول، یک مسیر روشن پیش رو دارید.
  • توسعه فول‌استکوب‌اپلیکیشن، API و داده را هماهنگ و یکپارچه توسعه دهید.
  • ممیزی مهندسیپیش از هزینه‌ی بیشتر، از وضعیت واقعی محصول‌تان باخبر شوید.
  • مشاوره معماریپیش از یک تصمیم فنی پرهزینه، گزینه‌ها را درست بسنجید.
  • زیرساخت و استقرارمحصول را با خیال راحت منتشر کنید و پایدار نگه دارید.
  • هوش مصنوعی در محصولهوش مصنوعی را فقط جایی به کار می‌گیریم که مسئله‌ای را حل کند.
نمونه‌کارهایادداشت‌هاقیمت‌گذاریدرباره ما
شروع گفتگو
  1. خانه
  2. /یادداشت‌ها
  3. /یادداشت‌ها
FutureForge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

خدمات

طراحی سایت با وردپرستوسعه اختصاصیمهندسی محصولزیرساخت و استقرارمشاوره معماریهوش مصنوعی در محصول

راهنمای انتخاب

یادداشت‌هاقیمت‌گذاریتخمین هزینه پروژهمقایسه روش‌هانمونه‌کارهادرباره ماتماس

ارتباط

hello@futureforge.ir

ایده‌ای برای ساخت دارید؟

نیازتان را مطرح کنید تا درباره مسیر توسعه و قدم بعدی صحبت کنیم.

شروع گفتگو

© 2026 FutureForge. همه حقوق محفوظ است.

حریم خصوصیشرایط استفاده
خانهنمونه‌کارشروعتماس
عملیات و استقرار

ps و top و htop: دیدن و پایش فرایندها در لینوکس

سا
سهیل ابراهیم‌پور
·۲۹ شهریور ۱۴۰۵·7 دقیقه مطالعه
ps top htop لینوکسprocess monitoringps auxtophtopCPU usagememory usagePID
htop روی لپ‌تاپ با استیکی ps top htop

تفاوت ps، top و htop برای دیدن CPU، حافظه و درخت فرایند؛ فرمان‌های واقعی و اشتباه‌های رایج پایش در سرور لینوکس.

وقتی سرور کند می‌شود، دیسک پر نیست و شبکه هم سالم به نظر می‌رسد، اولین سؤال عملی این است: کدام فرایند CPU یا حافظه را گرفته؟ بدون دیدن فهرست فرایندها (process) فقط حدس می‌زنید. سه ابزار کلاسیک این کار را انجام می‌دهند: ps برای عکس لحظه‌ای، top برای نمای زندهٔ متنی، و htop برای نمای تعاملی‌تر روی ترمینال.

این مقاله ادامهٔ مستقیم مفهوم فرایند در لینوکس است. فرض می‌کنیم می‌دانید PID چیست و چرا هر برنامهٔ در حال اجرا حداقل یک فرایند دارد؛ اینجا تمرکز روی خواندن خروجی ابزارها، انتخاب ستون‌های مفید، و دانستن محدودیت هر ابزار است — نه حفظ کردن همهٔ پرچم‌ها.

مقایسه سه‌ستونه ps top htop روی وایت‌برد

پاسخ کوتاه

از ps وقتی می‌خواهید یک عکس از وضعیت فعلی بگیرید یا خروجی را به لوله و اسکریپت بدهید. از top وقتی روی SSH هستید و می‌خواهید بدون نصب بستهٔ اضافه، مصرف لحظه‌ای CPU و حافظه را ببینید. از htop وقتی ترمینال اجازه می‌دهد و می‌خواهید با کیبورد فرایند را فیلتر، مرتب، یا (با احتیاط) بکشید. هیچ‌کدام جایگزین مانیتورینگ بلندمدت (متریک و هشدار) نیستند؛ ابزار تشخیص در لحظهٔ حادثه‌اند.

ps برای برش لحظه‌ای، top/htop برای نبض زنده — و هر سه بدون زمینهٔ «چه چیزی نرمال است برای این سرویس» فقط نویز تولید می‌کنند.

چرا سه ابزار مختلف؟

هر سه در نهایت از اطلاعات هسته دربارهٔ فرایندها می‌خوانند (در لینوکس معمولاً از طریق فایل‌سیستم /proc). تفاوت در رابط و الگوی استفاده است:

  • ps: یک بار اجرا می‌شود، خروجی ثابت می‌دهد، برای grep و اسکریپت عالی است.
  • top: صفحه را تازه می‌کند؛ مناسب جلسهٔ عیب‌یابی زنده روی سرور مینیمال.
  • htop: رابط رنگی، درخت فرایند، جستجو و فیلتر راحت‌تر؛ اغلب باید جدا نصب شود.

اگر فقط یک فرمان حفظ کنید: ابتدا `ps` برای یافتن PID مشکوک، سپس در صورت نیاز `top` یا `htop` برای دیدن روند مصرف در چند ثانیه.

ps: عکس لحظه‌ای

ps مخفف process status است. شکل‌های زیادی دارد چون سنت BSD و System V را همزمان پوشش می‌دهد. برای کار روزمرهٔ سرور، ترکیب‌های زیر کافی‌اند.

فهرست کامل با جزئیات رایج

bash

ps aux

خروجی معمولاً شامل USER، PID، %CPU، %MEM، VSZ، RSS، TTY، STAT، START، TIME و COMMAND است. USER مالک فرایند است؛ PID شناسه؛ %CPU و %MEM سهم تقریبی از منابع؛ RSS حافظهٔ مقیم تقریبی؛ STAT وضعیت کوتاه (مثلاً R در حال اجرا، S خواب وقفه، Z زامبی، D خواب غیرقابل‌وقفه).

درخت فرایند

bash

ps auxf

پرچم f درخت والد–فرزند را نشان می‌دهد. وقتی یک سرویس چند worker دارد یا اسکریپت فرزند spawn می‌کند، درخت سریع‌تر از لیست تخت می‌گوید کدام والد مقصر است.

فیلتر روی نام یا کاربر

bash

ps -u www-data -o pid,ppid,stat,%cpu,%mem,cmd ps -C nginx -o pid,stat,%cpu,%mem,args

گزینهٔ -o ستون‌ها را خودتان انتخاب می‌کنید تا نویز کم شود. برای اسکریپت‌ها، خروجی قابل‌پیش‌بینی مهم‌تر از زیبایی است.

یافتن PID برای یک الگو

bash

ps aux | grep '[n]ginx'

ترفند [n] باعث می‌شود خود خط grep در نتایج نیاید. جایگزین تمیزتر در بسیاری سیستم‌ها `pgrep -a nginx` است.

bash

pgrep -a nginx pgrep -u deploy -l

top: نبض زنده بدون وابستگی اضافه

با اجرای `top` صفحه‌ای می‌بینید که هر چند ثانیه تازه می‌شود: خلاصهٔ load average، تعداد فرایندها، و جدول مرتب‌شده (پیش‌فرض اغلب بر اساس CPU).

bash

top

کلیدهای مفید در جلسهٔ top (بدون Enter اضافی برای بیشتر آن‌ها):

  • P: مرتب‌سازی بر اساس CPU
  • M: مرتب‌سازی بر اساس حافظه
  • k: ارسال سیگنال به PID (معادل محتاطانهٔ kill؛ فقط اگر مطمئنید)
  • 1: نمایش CPU به‌ازای هر هسته
  • q: خروج

bash

top -p 1234,5678 top -u postgres

محدود کردن به PID یا کاربر، نویز را کم می‌کند وقتی روی ماشین شلوغ عیب‌یابی می‌کنید. گزینهٔ -b برای حالت دسته‌ای (batch) خروجی را یک‌بار چاپ می‌کند و برای لاگ‌برداری کوتاه مفید است:

bash

top -b -n 1 | head -n 20

htop: وقتی ترمینال اجازه می‌دهد

htop جایگزین تعاملی‌تر top است: نوارهای رنگی CPU/حافظه/swap، پیمایش با کلیدهای جهت، فیلتر با F4، درخت با F5، و جستجو. روی بسیاری از ابرتصویرها پیش‌فرض نیست:

bash

sudo apt update && sudo apt install -y htop # Debian/Ubuntu sudo dnf install -y htop # Fedora/RHEL-like

bash

htop

htop برای جلسهٔ دستی عالی است؛ برای اتوماسیون و CI معمولاً ps یا خواندن مستقیم /proc مناسب‌تر است چون خروجی پایدار و بدون TUI می‌خواهید.

جدول تصمیم سریع

نیازابزارچرا
یافتن PID برای اسکریپت/لولهps / pgrepخروجی یک‌بار، قابل پارس
دیدن جهش CPU در ۳۰ ثانیهtop یا htopتازه‌سازی زنده
درخت سرویس چندفرزندیps auxf یا htop (درخت)رابطهٔ والد–فرزند
سرور بدون بستهٔ اضافهps + topمعمولاً از قبل هست
مانیتورینگ هفته‌ای با هشدارنه این سهمتریک/Prometheus/مشابه

خواندن درست اعداد

%CPU در ps اغلب میانگین از شروع فرایند است؛ در top/htop معمولاً بازهٔ نمونه‌برداری جاری را نشان می‌دهد. پس فرایندی که یک‌بار spike داشته در ps ممکن است هنوز %CPU بالا نشان دهد یا برعکس. RSS حافظهٔ فیزیکی تقریبی است و جمع RSS همهٔ فرایندها به‌خاطر صفحات مشترک می‌تواند گمراه‌کننده باشد.

Load average در سربرگ top میانگین طول صف اجراست، نه «درصد CPU». روی ماشین ۸ هسته‌ای load حدود ۸ یعنی صف پر؛ تفسیر دقیق‌تر در مقالهٔ جداگانهٔ load average می‌آید.

گردش کار عیب‌یابی پیشنهادی

  1. ps aux --sort=-%cpu | head و همین برای %mem تا نامزدها را ببینید.
  2. اگر نامزد پایدار نیست، top یا htop را ۳۰–۶۰ ثانیه باز بگذارید.
  3. با درخت (ps auxf) ببینید آیا worker فرزند یک سرویس اصلی است.
  4. قبل از kill، بفهمید فرایند مال کدام واحد systemd یا کاربر است.
  5. اگر الگو تکراری است، متریک بلندمدت و سقف منابع (cgroup/limit) را بررسی کنید — نه فقط کشتن لحظه‌ای.

bash

ps aux --sort=-%cpu | head -n 15 ps aux --sort=-%mem | head -n 15

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

  • کشتن اولین PID با %CPU بالا بدون فهمیدن اینکه GC، بکاپ یا migrate عمدی است.
  • اتکا به یک نمونهٔ ps در لحظهٔ اوج کوتاه ترافیک.
  • جمع کردن %MEM همهٔ سطرها و نتیجه‌گیری «حافظه ۲۰۰٪ شده».
  • نصب htop روی production فقط برای یک بار دیدن؛ درحالی‌که top کافی بود.
  • فراموش کردن اینکه بدون دسترسی، فقط فرایندهای خودتان را می‌بینید.

چه زمانی کافی نیست؟

اگر هر روز یک نفر SSH می‌زند و top را نگاه می‌کند تا بفهمد سایت کند است، ابزار را اشتباه انتخاب کرده‌اید. ps/top/htop برای تشخیص تعاملی‌اند. برای روند، ظرفیت‌سنجی و هشدار به مانیتورینگ ساختاریافته نیاز دارید. همچنین برای دیدن اینکه کدام سوکت یا پورت به کدام PID وصل است، ابزارهایی مثل ss وارد می‌شوند — در مقالات پورت و شبکه.

خلاصه

ps برای برش و اسکریپت، top برای نبض روی سرور مینیمال، htop برای کار تعاملی راحت‌تر. اعداد را در بافت نمونه‌برداری و حافظهٔ مشترک بخوانید، درخت را برای سرویس‌های چندفرایندی جدی بگیرید، و قبل از ارسال سیگنال بدانید چه چیزی را می‌کشید. قدم بعدی منطقی: مقالهٔ کشتن امن فرایندها و سپس systemd برای فهم مالک بلندمدت همان PID.

سوالات متداول

آیا htop همیشه بهتر از top است؟

برای انسان پشت ترمینال اغلب بله؛ برای سرور قفل‌شده، اسکریپت، یا محیطی که اجازهٔ نصب ندارد، top و ps کافی و گاهی تنها گزینهٔ معقول‌اند.

چرا PID در ps هست ولی در top نیست؟

معمولاً فرایند خیلی کوتاه‌عمر بوده، فیلتر کاربر/PID فعال است، یا تازه‌سازی top هنوز آن را در بازه نشان نداده. دوباره ps بگیرید.

VSZ و RSS چه فرقی دارند؟

VSZ فضای آدرس مجازی را نشان می‌دهد؛ RSS تقریبی از صفحات مقیم در RAM است. برای فشار حافظهٔ واقعی، RSS (با احتیاط اشتراک) مفیدتر از VSZ است.

منابع و مراجع

  • ps(1) — procps-ng manual: https://man7.org/linux/man-pages/man1/ps.1.html
  • top(1) — procps-ng manual: https://man7.org/linux/man-pages/man1/top.1.html
  • htop — project documentation: https://htop.dev/
  • proc(5) — /proc filesystem: https://man7.org/linux/man-pages/man5/proc.5.html

نویسنده

سا

سهیل ابراهیم‌پور بنیان‌گذار FutureForge است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.

یادداشت‌های مرتبط

یادداشت‌های مرتبط

دسته‌بندی‌ها

خدمات مرتبط

از یادداشت تا پروژه

اگر با مسئله‌ای شبیه این روبه‌رو هستید، درباره‌ی شرایط پروژه‌تان با هم صحبت کنیم.

برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟

از مسئله و محدودیت‌هایتان بگویید؛ اگر بتوانیم همراهی‌تان کنیم، برای گفت‌وگو هماهنگ می‌کنیم.

سهیل ابراهیم‌پور
یادداشت‌ها
امنیت n8n: اعتبارنامه، وب‌هوک و SSRF
نصب n8n روی سرور با Docker Compose
n8n چیست و چگونه کار می‌کند؟
امنیت فروشگاه اینترنتی: سایت، درگاه و فرایند عملیاتی
بازیابی سرور لینوکس بعد از خرابی دیسک یا استقرار اشتباه

عملیات و استقرار

امنیت n8n: اعتبارنامه، وب‌هوک و SSRF

۹ آبان ۱۴۰۵

عملیات و استقرار

نصب n8n روی سرور با Docker Compose

۸ آبان ۱۴۰۵

عملیات و استقرار

n8n چیست و چگونه کار می‌کند؟

۸ آبان ۱۴۰۵

عملیات و استقرار

امنیت فروشگاه اینترنتی: سایت، درگاه و فرایند عملیاتی

۶ آبان ۱۴۰۵

عملیات و استقرار

بازیابی سرور لینوکس بعد از خرابی دیسک یا استقرار اشتباه

۲ آبان ۱۴۰۵
همه یادداشت‌ها315
معماری نرم‌افزار31
واژه‌نامه37
عملیات و استقرار94
مهندسی محصول122
راهنمای وب31
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
شروع گفتگو
ابزارهای رایگان
شروع گفتگو