آموزش مانیتورینگ سرور MTA در لینوکس

وقتی سرور MTA دچار لگ، تأخیر، افزایش Ping، کندی Resourceها یا Crash می‌شود، اولین کار نباید ارتقای فوری VPS باشد. ابتدا باید مشخص کنیم کدام بخش از سرور واقعاً تحت فشار است: CPU، RAM، دیسک، شبکه، دیتابیس یا خود Resourceهای MTA.

لینوکس ابزارهای دقیقی برای مشاهده مصرف منابع دارد و MTA نیز PerformanceBrowser داخلی برای بررسی عملکرد Threadهای مختلف سرور ارائه می‌کند.

در این آموزش مصرف CPU و RAM، فضای دیسک، Load Average، Process سرور MTA، پورت‌ها، شبکه، Logها و عملکرد Resourceها را مرحله‌به‌مرحله بررسی می‌کنیم.

برای مانیتورینگ سرور MTA چه چیزهایی را بررسی کنیم؟

مصرف CPU کل VPS
مصرف CPU Process سرور MTA
RAM و Swap
Load Average
فضای آزاد دیسک
مصرف I/O دیسک
ترافیک و اتصال‌های شبکه
پورت‌های MTA
وضعیت Service در systemd
Logهای MTA و systemd
مصرف CPU Threadهای داخلی MTA
Resourceهای سنگین یا مشکل‌دار

بررسی سریع وضعیت سرور با top

اولین ابزار ساده برای مشاهده وضعیت زنده سیستم:

top

در بالای صفحه اطلاعاتی مانند Load Average، مصرف CPU، مقدار RAM و Swap نمایش داده می‌شود و پایین صفحه Processهای فعال دیده می‌شوند.

برای خروج از top کلید Q را بزنید.

پیدا کردن Process سرور MTA

ps aux | grep mta-server

در نسخه 64 بیتی معمولاً Process با نام mta-server64 دیده می‌شود.

برای مشاهده مرتب مصرف CPU و RAM:

ps -C mta-server64 \
-o pid,ppid,%cpu,%mem,rss,vsz,etime,cmd

مقادیر مهم:

ستون	معنی
%CPU	مصرف پردازنده Process
%MEM	درصد RAM مصرف‌شده
RSS	حافظه واقعی در RAM
VSZ	فضای حافظه مجازی Process
ETIME	مدت زمان اجرای Process
PID	شناسه Process

بررسی RAM با free

free -h

دستور free میزان حافظه فیزیکی و Swap استفاده‌شده و آزاد سیستم را نمایش می‌دهد. اطلاعات آن از /proc/meminfo خوانده می‌شود. :contentReference[oaicite:1]{index=1}

در خروجی بیشتر به ستون available توجه کنید؛ زیرا بخشی از RAM لینوکس برای Cache استفاده می‌شود و صرفاً پایین بودن مقدار free به معنی کمبود حافظه نیست.

مشاهده RAM به‌صورت زنده

watch -n 2 free -h

این دستور هر دو ثانیه اطلاعات حافظه را بروزرسانی می‌کند.

Swap چیست و چرا مهم است؟

Swap بخشی از فضای ذخیره‌سازی است که در شرایط کمبود RAM می‌تواند برای نگهداری صفحات حافظه استفاده شود.

اگر یک VPS دائماً مقدار زیادی Swap مصرف می‌کند، ممکن است RAM برای بار واقعی پروژه کافی نباشد یا یک Process مصرف حافظه غیرعادی داشته باشد.

برای بررسی:

free -h

بررسی Load Average

uptime

در انتهای خروجی سه مقدار Load Average دیده می‌شود که میانگین بار سیستم را در بازه‌های زمانی کوتاه، متوسط و بلندتر نشان می‌دهند.

برای تفسیر Load باید تعداد CPUهای در دسترس VPS را نیز بدانید:

nproc

Load بالا به‌تنهایی ثابت نمی‌کند MTA مشکل CPU دارد؛ Processهای دیگر و I/O نیز باید بررسی شوند.

بررسی وضعیت CPU و حافظه با vmstat

vmstat اطلاعات مربوط به Processها، حافظه، Paging، I/O و CPU را گزارش می‌کند. :contentReference[oaicite:2]{index=2}

vmstat 2

این دستور هر دو ثانیه یک نمونه جدید نمایش می‌دهد.

برای پنج نمونه:

vmstat 2 5

ستون‌های مهم شامل runnable processها، Swap، I/O و درصدهای CPU هستند.

بررسی فضای دیسک

df -h

df میزان فضای استفاده‌شده و آزاد فایل‌سیستم‌ها را نمایش می‌دهد. :contentReference[oaicite:3]{index=3}

پارتیشنی که MTA، Logها، Backupها یا MySQL روی آن قرار دارد نباید به فضای کاملاً پر نزدیک شود.

پیدا کردن پوشه‌های حجیم MTA

du -sh \
/home/mta/multitheftauto_linux_x64/*

برای بررسی پوشه deathmatch:

du -sh \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/*

معمولاً Resourceها، Logها و Backupهای رهاشده از بخش‌هایی هستند که باید بررسی شوند.

بررسی حجم Log سرور MTA

du -sh \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/logs

برای مشاهده فایل‌های بزرگ‌تر:

ls -lhS \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/logs

بررسی وضعیت Service سرور MTA

اگر سرور با systemd اجرا می‌شود:

sudo systemctl status mtaserver

برای مشاهده PID اصلی:

systemctl show \
-p MainPID \
--value \
mtaserver

برای مشاهده وضعیت Active:

systemctl is-active mtaserver

مشاهده Logهای systemd

journalctl برای نمایش Logهای ثبت‌شده توسط systemd-journald استفاده می‌شود و با گزینه -u می‌توان خروجی یک Service مشخص را فیلتر کرد. :contentReference[oaicite:4]{index=4}

sudo journalctl \
-u mtaserver.service \
-n 100 \
--no-pager

مشاهده زنده:

sudo journalctl \
-u mtaserver.service \
-f

بررسی Log داخلی MTA

tail -f \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/logs/server.log

برای مشاهده 200 خط آخر:

tail -n 200 \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/logs/server.log

جست‌وجوی Error و Warning در Log

grep -Ei \
'error|warning|failed|crash' \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/logs/server.log

وجود Warning الزاماً به معنی خرابی سرور نیست؛ پیام باید همراه با Resource و شرایط وقوع آن بررسی شود.

بررسی پورت‌های MTA با ss

ابزار ss برای مشاهده Socketها و وضعیت اتصال‌های شبکه در لینوکس استفاده می‌شود. :contentReference[oaicite:5]{index=5}

برای پورت‌های پیش‌فرض MTA:

sudo ss -lntup | \
grep -E '22003|22005|22126'

در تنظیم پیش‌فرض باید پورت بازی UDP، پورت HTTP TCP و پورت ASE UDP قابل مشاهده باشند.

بررسی UDP پورت اصلی MTA

sudo ss -lunp | grep 22003

بررسی پورت HTTP

sudo ss -ltnp | grep 22005

اگر از پورت‌های سفارشی استفاده می‌کنید، شماره‌های واقعی mtaserver.conf را جایگزین کنید.

استفاده از openports داخل MTA

در Console سرور دستور زیر را اجرا کنید:

openports

اگر سرور Listen می‌کند اما openports مشکل نشان می‌دهد، Firewall سیستم‌عامل، Firewall دیتاسنتر یا تنظیمات شبکه را بررسی کنید.

PerformanceBrowser در MTA چیست؟

MTA یک Resource داخلی با نام PerformanceBrowser دارد که برای بررسی جزئی عملکرد سرور طراحی شده است.

در بخش Server Info می‌توان مصرف CPU Threadهای مختلف را مشاهده کرد:

Logic Thread
Sync Thread
RakNet Thread
Database Thread

طبق مستندات MTA، Logic Thread اجرای Lua و منطق اسکریپت‌ها را انجام می‌دهد، Sync Thread مسئول بخش Sync است، RakNet Thread ترافیک شبکه را پردازش می‌کند و DB Thread فعالیت دیتابیس را بر عهده دارد. :contentReference[oaicite:6]{index=6}

فعال‌کردن PerformanceBrowser

در Console سرور ابتدا Resource را اجرا کنید:

start performancebrowser

اگر Resource پیدا نشد، بسته Resourceهای رسمی MTA و نصب صحیح آن را بررسی کنید.

Logic Thread CPU بالا یعنی چه؟

Logic Thread بخش Lua و منطق Resourceها را اجرا می‌کند. اگر این Thread مرتب نزدیک سقف مصرف یک هسته باشد، احتمالاً باید Resourceهای Server-side و Eventهای پرتکرار بررسی شوند.

Loopهای بسیار بزرگ
Timerهای بسیار کوتاه
onClientRender یا Eventهای مشابه با کار Server سنگین
محاسبات تکراری برای تعداد زیاد بازیکن
کوئری‌های نامناسب
Resourceهای قدیمی یا بهینه‌نشده

چرا CPU کل پایین است ولی MTA لگ دارد؟

یکی از نکات مهم این است که مصرف کل CPU میان چند Core تقسیم می‌شود. ممکن است کل VPS فقط بخشی از توان CPU را مصرف کند اما یک Thread مهم MTA یک Core را تقریباً کامل اشغال کرده باشد.

PerformanceBrowser مصرف Threadهای اصلی MTA را جداگانه نشان می‌دهد و برای چنین شرایطی از مشاهده درصد کلی CPU مفیدتر است. :contentReference[oaicite:7]{index=7}

Sync Thread بالا

مصرف بالای Sync می‌تواند با تعداد بازیکنان، Elementهای Sync شده، خودروها، Pedها و حجم اطلاعاتی که باید میان سرور و Clientها هماهنگ شود ارتباط داشته باشد.

تعداد Elementهای فعال را بررسی کنید.
Elementهای بدون استفاده را حذف کنید.
Resourceهایی که تعداد زیادی Object یا Vehicle ایجاد می‌کنند بررسی شوند.
محدوده Stream و ساختار گیم‌مود بررسی شود.

RakNet Thread بالا

RakNet Thread مربوط به ارسال و دریافت Packetهای شبکه است.

تعداد بازیکنان آنلاین را بررسی کنید.
Eventهای شبکه بسیار پرتکرار را پیدا کنید.
داده‌های بزرگ و غیرضروری ارسالی به Client را کاهش دهید.
مشکلات شبکه VPS را بررسی کنید.
Resourceهایی که Eventهای زیاد Trigger می‌کنند بررسی شوند.

DB Thread بالا

اگر DB Thread مصرف زیادی دارد، کوئری‌ها و طراحی دیتابیس باید بررسی شوند.

کوئری‌های پرتکرار
SELECT بدون Index مناسب
کوئری داخل Loop
دریافت ستون‌های غیرضروری
دیتابیس راه دور با Latency زیاد
استفاده نامناسب از dbQuery و dbPoll

برای بررسی دیتابیس، مقاله آموزش اتصال سرور MTA به MySQL و رفع خطاهای دیتابیس را مطالعه کنید.

فعال‌کردن Log دیتابیس MTA

debugdb 2

سپس فایل زیر را بررسی کنید:

mods/deathmatch/logs/db.log

سطح کامل Debug را فقط هنگام عیب‌یابی فعال نگه دارید تا Log بی‌دلیل بزرگ نشود.

بررسی مصرف Resourceها

وقتی Logic Thread بالا است، Resourceهای فعال را یکی‌یکی بررسی کنید و دنبال Resourceهایی باشید که بعد از Start شدن مصرف CPU را به‌طور قابل توجه افزایش می‌دهند.

برای تست در محیط آزمایشی می‌توان یک Resource مشکوک را موقتاً Stop کرد:

stop resource-name

سپس تغییر مصرف CPU و وضعیت Server را بررسی کنید.

Resource اصلی گیم‌مود را وسط فعالیت سرور Production بدون بررسی متوقف نکنید. آزمایش‌های عیب‌یابی بهتر است در محیط تست یا زمان Maintenance انجام شوند.

بررسی مصرف منابع قبل و بعد از Start یک Resource

CPU و RAM فعلی را ثبت کنید.
PerformanceBrowser را باز کنید.
Resource موردنظر را Start کنید.
چند دقیقه صبر کنید.
Logic Thread و RAM را دوباره بررسی کنید.
با ورود چند Client واقعی رفتار Server را آزمایش کنید.

Memory Leak در Resource چیست؟

اگر مصرف RAM سرور به‌مرور افزایش پیدا می‌کند و پس از پایان فعالیت‌های معمول کاهش نمی‌یابد، باید Resourceها و داده‌هایی که دائماً ایجاد می‌شوند بررسی شوند.

Tableهای Lua که پاک نمی‌شوند
Elementهای ایجادشده و Destroy نشده
Timerهای تکراری غیرضروری
Handlerهای متعدد
Cacheهای بدون محدودیت
ذخیره داده‌های حجیم در حافظه

ثبت دوره‌ای مصرف MTA با ps

برای گرفتن یک Snapshot:

ps -C mta-server64 \
-o pid,%cpu,%mem,rss,etime,cmd

برای مشاهده مداوم هر پنج ثانیه:

watch -n 5 \
"ps -C mta-server64 -o pid,%cpu,%mem,rss,etime,cmd"

بررسی تعداد CPUهای VPS

lscpu

برای فقط تعداد CPUهای قابل استفاده:

nproc

در انتخاب VPS برای MTA فقط تعداد Core مهم نیست؛ قدرت تک‌هسته‌ای CPU نیز برای Threadهای اصلی اهمیت زیادی دارد.

بررسی Network Interfaceها

ip -s link

در خروجی می‌توانید تعداد Byteها، Packetها، Errorها و Dropهای Interfaceها را مشاهده کنید.

افزایش مداوم RX یا TX Drop و Error می‌تواند نشانه‌ای برای بررسی شبکه، Driver، VPS Host یا فشار Packet باشد.

بررسی اتصال‌های شبکه با ss

sudo ss -s

برای مشاهده Socketهای UDP:

sudo ss -uan

بررسی Ping از خود VPS

برای بررسی ابتدایی اتصال اینترنت VPS می‌توان یک مقصد پایدار را Ping کرد:

ping -c 20 1.1.1.1

به Average Latency و Packet Loss توجه کنید. صفر بودن Packet Loss در این آزمایش تضمین نمی‌کند مسیر تمام بازیکنان مناسب است، اما برای تشخیص مشکلات عمومی شبکه مفید است.

بررسی DNS

getent hosts linux.multitheftauto.com

اگر Resource یا سرویس‌های جانبی سرور به Domainهای خارجی متصل می‌شوند، مشکل DNS نیز می‌تواند باعث Timeout شود.

زمانی که CPU بالا می‌رود چه کار کنیم؟

با top Process پرمصرف را پیدا کنید.
بررسی کنید مصرف مربوط به MTA است یا Process دیگری.
PerformanceBrowser را باز کنید.
Logic، Sync، RakNet و DB Thread را مقایسه کنید.
Resourceهای جدید یا تغییرکرده را بررسی کنید.
Logهای سرور را بخوانید.
تعداد Player و Elementها را با زمان مشکل مقایسه کنید.
در صورت DB بالا، Queryها را بررسی کنید.

زمانی که RAM بالا می‌رود چه کار کنیم؟

free -h را بررسی کنید.
RSS Process MTA را مشاهده کنید.
Swap را بررسی کنید.
مصرف را در چند ساعت مقایسه کنید.
Resourceهای تازه نصب‌شده را بررسی کنید.
حجم Cacheهای گیم‌مود را کنترل کنید.
پس از Restart مقدار RAM را با قبل مقایسه کنید.

زمانی که دیسک پر می‌شود چه کار کنیم؟

df -h را اجرا کنید.
پوشه Backup را بررسی کنید.
Logهای MTA را بررسی کنید.
db.log را در صورت فعال بودن debugdb بررسی کنید.
بکاپ‌های قدیمی را طبق Retention حذف کنید.
Logهای systemd را از نظر حجم بررسی کنید.

برای مشاهده فضای مصرف‌شده Journal:

journalctl --disk-usage

journalctl امکان نمایش میزان فضای مصرف‌شده فایل‌های Journal را دارد. :contentReference[oaicite:8]{index=8}

مقایسه وضعیت Server در زمان عادی و زمان لگ

بهترین روش عیب‌یابی این است که اعداد را فقط در زمان مشکل مشاهده نکنید. ابتدا وضعیت عادی سرور را ثبت کنید.

شاخص	حالت عادی	زمان لگ
تعداد Player	ثبت شود	ثبت شود
CPU MTA	ثبت شود	ثبت شود
RAM MTA	ثبت شود	ثبت شود
Logic CPU	ثبت شود	ثبت شود
Sync CPU	ثبت شود	ثبت شود
RakNet CPU	ثبت شود	ثبت شود
DB CPU	ثبت شود	ثبت شود
Load Average	ثبت شود	ثبت شود
Swap	ثبت شود	ثبت شود

با این مقایسه راحت‌تر مشخص می‌شود چه شاخصی هم‌زمان با شروع مشکل تغییر کرده است.

اشتباهات رایج در مانیتورینگ MTA

نگاه کردن فقط به درصد کلی CPU
توجه نکردن به Threadهای داخلی MTA
فرض اینکه RAM Cache شده حتماً مشکل است
بررسی نکردن Swap
نادیده گرفتن دیسک پر
فعال نگه داشتن debugdb 2 برای مدت طولانی
ارتقای VPS بدون پیدا کردن Resource مشکل‌دار
تست فقط زمانی که هیچ بازیکنی آنلاین نیست
بررسی نکردن Logها
مقایسه نکردن حالت عادی و زمان لگ

چک‌لیست مانیتورینگ سرور MTA

Process MTA فعال است.
CPU Process بررسی شده است.
RAM و RSS بررسی شده‌اند.
Swap بررسی شده است.
Load Average بررسی شده است.
فضای دیسک بررسی شده است.
حجم Logها بررسی شده است.
پورت‌های MTA در حال Listen هستند.
Journal سرویس بررسی شده است.
server.log بررسی شده است.
PerformanceBrowser اجرا شده است.
Logic Thread بررسی شده است.
Sync Thread بررسی شده است.
RakNet Thread بررسی شده است.
DB Thread بررسی شده است.
Resourceهای مشکوک بررسی شده‌اند.
وضعیت شبکه بررسی شده است.
اعداد حالت عادی ثبت شده‌اند.

ترتیب سریع عیب‌یابی لگ سرور

top را اجرا کنید.
free -h را بررسی کنید.
df -h را بررسی کنید.
وضعیت mtaserver را ببینید.
server.log و Journal را بررسی کنید.
PerformanceBrowser را باز کنید.
Thread پرمصرف را پیدا کنید.
Resourceهای مرتبط را بررسی کنید.
درصورت DB بالا، Queryها را بررسی کنید.
درصورت RakNet بالا، Network Eventها را بررسی کنید.
درصورت Sync بالا، Elementها و Player Count را بررسی کنید.
بعد از هر تغییر دوباره اندازه‌گیری کنید.

جمع‌بندی

برای مانیتورینگ صحیح سرور MTA نباید فقط به یک عدد مانند CPU یا Ping نگاه کرد. CPU، RAM، Swap، Load، دیسک، شبکه، Logها و Threadهای داخلی MTA باید در کنار یکدیگر بررسی شوند.

ابزارهایی مانند top، ps، free، vmstat، df، ss و journalctl وضعیت سیستم‌عامل را نشان می‌دهند و PerformanceBrowser اطلاعات دقیق‌تری از Logic، Sync، RakNet و DB Thread داخل MTA ارائه می‌کند.

برای بررسی تخصصی مشکلات لگ نیز مقاله علت لگ سرور MTA و روش‌های رفع آن را مطالعه کنید.

برای انتخاب سخت‌افزار مناسب، راهنمای VPS مناسب سرور MTA چه مشخصاتی باید داشته باشد؟ را ببینید.

برای مدیریت خودکار Process سرور نیز مقاله آموزش اجرای خودکار سرور MTA با systemd را بررسی کنید.

برای بررسی تخصصی مصرف منابع و بهینه‌سازی پروژه می‌توانید از خدمات پشتیبانی فنی گیم‌سرور و راه‌اندازی و کانفیگ سرور MTA استفاده کنید.

پرسش‌های متداول

چگونه مصرف CPU سرور MTA را بررسی کنیم؟

در لینوکس از top یا ps برای مشاهده Process استفاده کنید و داخل MTA نیز PerformanceBrowser را برای بررسی CPU Threadهای Logic، Sync، RakNet و DB باز کنید.

چگونه مصرف RAM سرور MTA را ببینیم؟

برای وضعیت کل سیستم از free -h و برای Process MTA از ps با ستون‌های %MEM و RSS استفاده کنید.

چرا CPU VPS پایین است اما سرور لگ دارد؟

ممکن است یک Thread مهم MTA به سقف یک Core رسیده باشد، درحالی‌که میانگین CPU کل VPS پایین‌تر دیده می‌شود. PerformanceBrowser را بررسی کنید.

چگونه بفهمیم دیتابیس باعث لگ شده است؟

DB Thread را در PerformanceBrowser بررسی کنید و در زمان عیب‌یابی debugdb را فعال کنید تا Queryها و خطاهای دیتابیس مشخص شوند.

چگونه فضای دیسک VPS را بررسی کنیم؟

دستور df -h میزان فضای مصرف‌شده و آزاد فایل‌سیستم‌ها را نمایش می‌دهد.

چگونه Log سرویس MTA را مشاهده کنیم؟

اگر MTA با systemd اجرا می‌شود، از journalctl -u mtaserver.service استفاده کنید. Log داخلی MTA نیز در mods/deathmatch/logs/server.log قرار دارد.