مصرف 100 درصد یک CPU در MikroTik CHR روی VPS؛ علت چیست و چگونه آن را برطرف کنیم؟

آیا مصرف 100 درصد یک CPU در MikroTik CHR طبیعی است؟

پاسخ کوتاه این است: گاهی بله و گاهی کاملاً غیرطبیعی است.

اگر VPS شما فقط یک vCPU داشته باشد و ترافیک سنگینی از آن عبور کند، رسیدن CPU به 100 درصد می‌تواند نشانه این باشد که ظرفیت پردازشی همان یک هسته تکمیل شده است. اما اگر VPS شما مثلاً 4 یا 8 vCPU دارد و فقط یک CPU روی 100 درصد قرار گرفته، در حالی که سایر هسته‌ها تقریباً بیکار هستند، موضوع کمی متفاوت است.

در این وضعیت ممکن است یک کار مشخص در RouterOS روی یک هسته متمرکز شده باشد. بنابراین نباید فقط به عدد CPU در پنل VPS نگاه کنید؛ ابتدا باید داخل خود MikroTik بررسی کنیم که مصرف مربوط به کدام پردازش است.

اولین کاری که باید انجام دهید: پیدا کردن عامل مصرف CPU

مهم‌ترین ابزار برای شروع عیب‌یابی، دستور Profiler است. MikroTik توضیح می‌دهد که ابزار Profiler میزان مصرف CPU را برای پردازش‌های مختلف RouterOS نشان می‌دهد و در سیستم‌های چند هسته‌ای امکان مشاهده مصرف هر Core نیز وجود دارد.

/tool profile

اگر می‌خواهید وضعیت هسته‌ها را جداگانه ببینید:

/tool profile cpu=all

و برای مشاهده مجموع مصرف:

/tool profile cpu=total

در خروجی ممکن است نام‌هایی مانند ethernet، firewall، management، bridging، kvm، wireguard یا پردازش‌های دیگر را ببینید.

همین خروجی معمولاً مهم‌ترین سرنخ برای ادامه عیب‌یابی است. مستندات MikroTik نیز Profiler را دقیقاً برای شناسایی پردازشی که بیشترین منابع CPU را مصرف می‌کند معرفی کرده است.

مصرف CPU در بخش Resource را چگونه بررسی کنیم؟

دستور زیر اطلاعات CPU را به تفکیک Core نمایش می‌دهد:

/system resource cpu print

در این قسمت علاوه بر Load می‌توانید مقدار IRQ و Disk را نیز مشاهده کنید. این موضوع در یک CHR روی VPS اهمیت دارد، زیرا اگر بخش زیادی از CPU صرف پردازش Interruptهای شبکه شود، ممکن است مشکل شما بیشتر به مسیر شبکه مجازی مربوط باشد تا Firewall.

مستندات RouterOS برای CPU همین بخش را برای نمایش مصرف هر CPU و همچنین IRQ معرفی می‌کند.

دلیل اول: ترافیک زیاد یا Packet Rate بالا

یکی از ساده‌ترین دلایل مصرف بالای CPU در MikroTik CHR، عبور ترافیک زیاد از VPS است. اما فقط مقدار Mbps مهم نیست؛ تعداد Packet در ثانیه یا PPS نیز اهمیت بسیار زیادی دارد.

برای مثال ممکن است یک VPS فقط 300Mbps ترافیک داشته باشد، اما اگر این ترافیک از تعداد بسیار زیادی Packet کوچک تشکیل شده باشد، پردازش هر Packet می‌تواند CPU بیشتری نسبت به تعداد کمتری Packet بزرگ مصرف کند.

این مسئله در سرویس‌هایی مانند VPN، NAT، Port Forwarding، حملات اسکن، WireGuard، تونل‌ها و بعضی سناریوهای DDoS بیشتر دیده می‌شود.

چگونه بفهمیم ترافیک عامل CPU است؟

می‌توانید از Torch استفاده کنید:

/tool torch

Torch برای مشاهده جریان ترافیک روی Interface طراحی شده و می‌تواند Source، Destination، Port، Protocol، VLAN و نرخ RX/TX را نشان دهد.

اگر در زمان بالا رفتن CPU مشاهده کردید که یک Interface حجم بسیار زیادی Packet دریافت یا ارسال می‌کند، باید بررسی کنید که این ترافیک واقعی و مورد انتظار است یا خیر.

دلیل دوم: Firewall و تعداد زیاد Ruleها

Firewall یکی از قسمت‌هایی است که می‌تواند CPU را به‌شدت درگیر کند؛ مخصوصاً زمانی که تعداد Ruleها زیاد باشد یا Ruleهایی استفاده شوند که نیاز به بررسی‌های سنگین روی Packet دارند.

هر Packet ممکن است مجبور شود از چندین مرحله پردازشی عبور کند. اگر Ruleها به‌صورت نامناسب مرتب شده باشند یا تعداد زیادی Matcher پیچیده استفاده شده باشد، CPU بیشتری مصرف می‌شود.

در یک CHR که وظیفه NAT، Routing، VPN و Filtering را هم‌زمان انجام می‌دهد، اثر این موضوع بیشتر می‌شود.

Layer7 می‌تواند CPU را بسیار بیشتر درگیر کند

استفاده از Layer7 در Firewall باید با دقت انجام شود. خود مستندات MikroTik اشاره می‌کند که تعداد زیاد Connectionها در کنار Layer7 می‌تواند مصرف CPU و Memory را افزایش دهد.

بنابراین اگر در Firewall خود از Ruleهایی مانند موارد زیر استفاده کرده‌اید، آنها را بررسی کنید:

• Layer7 Protocol
• Connection Rate
• Connection Bytes
• Packet Mark
• Connection Mark
• Matcherهای متعدد روی تعداد زیادی Connection
• Ruleهای پیچیده Mangle

قرار نیست تمام این قابلیت‌ها بد باشند؛ مشکل زمانی ایجاد می‌شود که بدون نیاز واقعی روی حجم بسیار زیادی از ترافیک اجرا شوند.

دلیل سوم: Connection Tracking

Connection Tracking یکی از بخش‌های مهم RouterOS است و NAT و بسیاری از قابلیت‌های Stateful Firewall به آن وابسته هستند.

اگر CHR تعداد بسیار زیادی Connection هم‌زمان داشته باشد، CPU و Memory بیشتری برای مدیریت آنها مصرف می‌شود. این موضوع به‌خصوص در سرورهای VPN، NAT Gateway، Proxy و VPSهایی که تعداد زیادی کاربر دارند اهمیت دارد.

MikroTik توضیح می‌دهد که Connection Tracking وضعیت Connectionها را نگهداری می‌کند و قابلیت‌هایی مانند NAT و برخی Matcherهای Firewall به آن وابسته‌اند. همچنین استفاده درست از FastTrack می‌تواند مسیر پردازش برخی Connectionها را سبک‌تر کند.

تعداد Connectionها را بررسی کنید

/ip firewall connection print count-only

اگر عدد Connectionها بسیار زیاد است، باید مشخص شود که این تعداد برای سرویس شما طبیعی است یا خیر.

برای مثال اگر یک MikroTik CHR شخصی دارید و ناگهان تعداد Connectionها از چند صد مورد به ده‌ها هزار مورد رسیده، احتمال دارد یک سرویس، اسکنر، حمله یا تنظیم اشتباه باعث ایجاد Connectionهای زیاد شده باشد.

دلیل چهارم: FastTrack غیرفعال است یا اصلاً نمی‌تواند استفاده شود

در بعضی سناریوهای IPv4، FastTrack می‌تواند مسیر پردازش Established/Related را سبک‌تر کند. اما FastTrack یک گزینه جادویی برای همه شبکه‌ها نیست.

طبق مستندات MikroTik، FastTrack برخی مسیرهای پردازشی مانند Firewall، Connection Tracking، Simple Queue و بعضی قابلیت‌های دیگر را برای Connectionهای FastTracked دور می‌زند. به همین دلیل باید قبل از فعال‌سازی آن بررسی کنید که با طراحی شبکه شما تداخل نداشته باشد.

برای مشاهده Ruleهای FastTrack:

/ip firewall filter print

اگر FastTrack را فعال کرده‌اید ولی Queue، Mangle، Routing Mark یا قابلیت‌های دیگری دارید که نیاز به مشاهده و پردازش Packet دارند، کورکورانه Ruleهای FastTrack را اضافه نکنید.

دلیل پنجم: Mangle و Policy Routing

در بسیاری از MikroTik VPSها از Mangle برای Mark Connection، Mark Packet، Policy Routing، تقسیم ترافیک و مدیریت چند مسیر استفاده می‌شود.

اگر تعداد Ruleهای Mangle زیاد باشد و آنها روی تمام Packetها اجرا شوند، CPU می‌تواند به‌شدت افزایش پیدا کند.

برای بررسی:

/ip firewall mangle print stats

به Counterهای Ruleها دقت کنید. Ruleهایی که میلیون‌ها Packet را Match کرده‌اند، کاندید خوبی برای بررسی هستند.

دلیل ششم: Queue و مدیریت پهنای باند

Queue یکی دیگر از موارد مهم در مصرف CPU است. اگر روی MikroTik CHR برای کاربران یا IPهای مختلف Simple Queue، Queue Tree یا الگوریتم‌های پیچیده QoS تنظیم کرده باشید، بخشی از Packet Processing به Queueها مربوط می‌شود.

در RouterOS نوع Queue و نحوه استفاده از Queue Tree می‌تواند روی مسیر پردازش ترافیک تأثیر بگذارد. مستندات MikroTik نیز درباره تأثیر Queueها و ساختار Queueهای نرم‌افزاری روی پردازش سیستم توضیح می‌دهد.

برای بررسی Queueها:

/queue simple print stats

و برای Queue Tree:

/queue tree print stats

اگر با حذف یا Disable موقت Queueها CPU به‌طور محسوسی کاهش یافت، احتمالاً باید ساختار QoS را بازطراحی کنید.

دلیل هفتم: Bridge و Forwarding در CHR

یکی از مواردی که گاهی نادیده گرفته می‌شود، Bridge است.

در یک RouterBoard فیزیکی ممکن است بعضی عملیات Layer2 توسط Switch Chip انجام شوند، اما در CHR روی VPS خبری از همان سخت‌افزار فیزیکی نیست. بنابراین بسته‌هایی که باید توسط CPU پردازش شوند می‌توانند بار بیشتری ایجاد کنند.

MikroTik در مستندات خود نشان می‌دهد که وقتی Hardware Offloading وجود نداشته باشد یا Forwarding مجبور به عبور از CPU شود، مصرف CPU می‌تواند افزایش پیدا کند.

در CHR بنابراین باید دقیقاً بدانید چرا از Bridge استفاده می‌کنید و چه ترافیکی از آن عبور می‌کند.

بررسی Bridge

/interface bridge print
/interface bridge port print

اگر CHR شما صرفاً Router/NAT/VPN است، ایجاد Bridgeهای غیرضروری می‌تواند طراحی را پیچیده‌تر کند.

دلیل هشتم: WireGuard و رمزنگاری ترافیک

اگر MikroTik CHR شما به‌عنوان WireGuard Server یا Client استفاده می‌شود، هنگام افزایش ترافیک VPN، CPU نیز می‌تواند افزایش پیدا کند.

این موضوع به‌خصوص در VPSهایی که یک vCPU دارند محسوس است. اگر تعداد زیادی Peer هم‌زمان فعال باشند یا حجم زیادی ترافیک رمزگذاری‌شده عبور کند، باید CPU را در زمان واقعی بررسی کنید.

برای بررسی Peerها:

/interface wireguard peers print detail

و Interfaceها:

/interface wireguard print detail

اگر CPU دقیقاً هم‌زمان با افزایش ترافیک WireGuard بالا می‌رود، احتمالاً باید ظرفیت CPU و ساختار شبکه را در کنار سایر عوامل بررسی کنید.

دلیل نهم: EoIP، GRE و Tunnel‌ها

Tunnel‌ها می‌توانند CPU بیشتری نسبت به یک Routing ساده مصرف کنند؛ مخصوصاً زمانی که ترافیک زیادی از داخل Tunnel عبور می‌کند یا چندین Tunnel هم‌زمان فعال هستند.

در سناریوهایی مانند اتصال دو شعبه با EoIP یا استفاده از GRE برای انتقال شبکه، باید CPU را هنگام عبور واقعی ترافیک بررسی کنید.

برای بررسی EoIP:

/interface eoip print detail

و برای GRE:

/interface gre print detail

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

دلیل دهم: کارت شبکه مجازی نامناسب در VPS

این مورد برای MikroTik CHR بسیار مهم است.

CHR برای اجرا روی Hypervisorهای مختلف طراحی شده و MikroTik برای محیط‌هایی مانند VMware، KVM/QEMU و Hyper-V رابط‌های شبکه مجازی مشخصی را مستند کرده است.

برای مثال در KVM/QEMU استفاده از Virtio و در VMware استفاده از VMXNET3 می‌تواند نسبت به رابط‌های شبیه‌سازی‌شده قدیمی مانند E1000 مناسب‌تر باشد. MikroTik همچنین اعلام کرده که FastPath در RouterOS v7 برای درایورهای vmxnet3 و virtio-net پشتیبانی می‌شود.

مستندات رسمی CHR نیز برای KVM/QEMU رابط Virtio و برای ESXi رابط VMXNET3 را ذکر می‌کند و توصیه می‌کند زمانی که رابط Synthetic مناسب وجود دارد، از E1000 استفاده نشود.

دلیل یازدهم: IRQ و پردازش شبکه روی یک Core

گاهی CPU به دلیل خود Firewall بالا نرفته است؛ بلکه بخش زیادی از CPU صرف Interruptهای شبکه می‌شود.

در این شرایط ممکن است یک Core دائماً بالا باشد و سایر Coreها مصرف بسیار کمتری داشته باشند.

ابتدا بررسی کنید:

/system resource cpu print

سپس:

/system resource irq print

اگر در Profiler نیز پردازش ethernet یا موارد مرتبط با شبکه سهم زیادی از CPU دارند، باید کارت شبکه مجازی، تعداد Queueها، نوع Hypervisor و وضعیت CPU تخصیص‌یافته به VM بررسی شود.

دلیل دوازدهم: VPS فقط یک vCPU دارد

یکی از ساده‌ترین علت‌ها این است که VPS واقعاً فقط یک CPU در اختیار CHR قرار داده است.

در این حالت وقتی RouterOS کاری دارد که نمی‌تواند آن را به شکل مؤثر بین چند Core تقسیم کند، همان یک CPU می‌تواند به 100 درصد برسد.

این موضوع مخصوصاً برای سرویس‌های زیر مهم است:

• VPN Server
• WireGuard Gateway
• NAT Gateway
• روتر پرترافیک
• Firewall سنگین
• Policy Routing
• Queue و QoS
• تعداد زیاد Connection
• Tunnel‌های متعدد

بنابراین قبل از افزایش منابع، تعداد CPU واقعی VM را بررسی کنید:

/system resource print

اگر فقط یک CPU دارید و همان CPU دائماً 100 درصد است، افزایش به 2 یا 4 vCPU می‌تواند در بعضی سناریوها منطقی باشد؛ اما اگر یک پردازش خاص روی یک Core قفل شده باشد، افزایش تعداد Core لزوماً آن پردازش را سریع‌تر نمی‌کند.

دلیل سیزدهم: CPU Steal یا مشکل از خود VPS Provider

یکی از نکات مهم این است که همیشه مشکل از MikroTik نیست.

در محیط VPS، CPU فیزیکی بین چند VM تقسیم می‌شود. اگر Provider منابع CPU را بیش از حد Overcommit کرده باشد یا VM شما تحت فشار Host قرار گرفته باشد، ممکن است عملکرد واقعی CPU پایین‌تر از چیزی باشد که در ظاهر می‌بینید.

بنابراین اگر تنظیمات MikroTik سالم است اما در ساعات خاصی عملکرد کاهش پیدا می‌کند، بهتر است وضعیت Host و CPU Allocation را از Provider پیگیری کنید.

دلیل چهاردهم: Sniffer، Torch و ابزارهای مانیتورینگ

گاهی خود ابزار عیب‌یابی باعث افزایش بار می‌شود.

برای مثال اگر Packet Sniffer را فعال کرده باشید و حجم زیادی از Packetها را Capture کنید، طبیعی است که پردازش اضافه ایجاد شود.

MikroTik نیز Packet Sniffer را ابزاری برای Capture و تحلیل Packetها معرفی می‌کند و در مستندات به قابلیت‌های مختلف Filtering آن اشاره شده است.

پس اگر هنگام بررسی CPU از Sniffer، Torch یا ابزارهای تست استفاده می‌کنید، ابتدا تست را متوقف کنید و ببینید CPU به حالت عادی برمی‌گردد یا خیر.

/tool sniffer stop

دلیل پانزدهم: Traffic Generator یا تست سرعت

اگر اخیراً Bandwidth Test یا Traffic Generator اجرا کرده‌اید، حتماً بررسی کنید که تست هنوز فعال نباشد.

Traffic Generator برای تولید Packet و ارزیابی Performance شبکه طراحی شده و می‌تواند حجم زیادی Packet ایجاد کند؛ بنابراین هنگام اجرای آن بالا رفتن CPU کاملاً قابل انتظار است.

دلیل شانزدهم: Layer2 Loop یا Broadcast غیرعادی

اگر CHR در یک شبکه Layer2 پیچیده قرار دارد، Loop یا Broadcast Storm نیز می‌تواند CPU را به‌شدت بالا ببرد.

این مورد را مخصوصاً در سناریوهای زیر بررسی کنید:

• Bridge
• EoIP
• VXLAN
• VLAN
• چند Bridge متصل به هم
• اتصال Tunnel به Bridge
• انتقال Broadcast بین چند سایت

اگر CPU ناگهان بدون افزایش محسوس مصرف اینترنت بالا رفته است، Broadcast یا Multicast غیرعادی را نیز بررسی کنید.

چگونه بفهمیم مشکل از Ethernet است یا Firewall؟

بهترین روش این است که چند تست کنترل‌شده انجام دهید.

مرحله اول: Profiler

/tool profile cpu=all

اگر ethernet بالاست، به سمت Network Adapter و Packet Rate بروید.

اگر firewall یا پردازش‌های مرتبط با Firewall بالاست، Ruleهای Firewall و Mangle را بررسی کنید.

اگر bridging بالاست، Bridge و Layer2 را بررسی کنید.

اگر پردازش مرتبط با VPN/Tunnel بالاست، Tunnel‌ها را بررسی کنید.

مرحله دوم: بررسی Interfaceها

/interface print stats

مرحله سوم: بررسی Firewall

/ip firewall filter print stats
/ip firewall nat print stats
/ip firewall mangle print stats

مرحله چهارم: بررسی Connectionها

/ip firewall connection print count-only

مرحله پنجم: بررسی Queue

/queue simple print stats
/queue tree print stats

اگر CPU بعد از اضافه شدن ترافیک بالا می‌رود چه کنیم؟

در این حالت باید مشخص کنید آیا مشکل «کمبود CPU واقعی» است یا «پردازش غیرضروری».

آیا افزایش vCPU مشکل را حل می‌کند؟

نه همیشه.

افزایش vCPU زمانی مفید است که واقعاً بار کاری شما قابلیت استفاده از چند Core را داشته باشد یا مجموع پردازش‌های CHR از ظرفیت CPU فعلی بیشتر شده باشد.

اما اگر یک پردازش خاص فقط یک Core را تا 100 درصد مصرف کند، اضافه کردن CPU ممکن است تغییر چشمگیری ایجاد نکند.

به همین دلیل ترتیب درست این است:

1. Profiler را اجرا کنید.
2. مشخص کنید کدام پردازش CPU را مصرف می‌کند.
3. ترافیک و Packet Rate را بررسی کنید.
4. Firewall و Mangle را بررسی کنید.
5. Connection Tracking را بررسی کنید.
6. Queueها را بررسی کنید.
7. Network Adapter مجازی را بررسی کنید.
8. در نهایت درباره افزایش vCPU تصمیم بگیرید.

تنظیمات Network Adapter در KVM؛ Virtio یا E1000؟

اگر CHR شما روی KVM/QEMU قرار دارد، نوع کارت شبکه مجازی را بررسی کنید.

در حالت معمول، اگر Provider امکان استفاده از Virtio را فراهم کرده باشد، استفاده از Virtio Network گزینه مهمی برای بررسی است. MikroTik در مستندات CHR، Virtio را برای QEMU/KVM پشتیبانی می‌کند و در RouterOS v7 نیز FastPath برای virtio-net پشتیبانی شده است.

اگر به جای Virtio از E1000 استفاده شده، مخصوصاً در VPS پرترافیک، ارزش دارد از Provider بپرسید آیا امکان تغییر به Virtio وجود دارد یا خیر.

در VMware چه چیزی را بررسی کنیم؟

اگر CHR روی VMware ESXi قرار دارد، VMXNET3 یکی از موارد مهم برای بررسی است.

MikroTik برای CHR روی ESXi پشتیبانی از VMXNET3 را مستند کرده و RouterOS v7 برای VMXNET3 قابلیت FastPath دارد.

بنابراین اگر یک CHR روی ESXi با E1000 اجرا می‌شود و CPU یا Packet Processing بالایی دارد، بررسی VMXNET3 می‌تواند یکی از مراحل منطقی عیب‌یابی باشد.

چرا بعد از آپدیت RouterOS ممکن است مصرف CPU تغییر کند؟

گاهی پس از Upgrade به نسخه جدید RouterOS رفتار Performance تغییر می‌کند. این الزاماً به معنی Bug نیست؛ تغییرات Kernel، Driver، قابلیت‌های جدید یا تغییر مسیر پردازش می‌تواند روی مصرف منابع تأثیر داشته باشد.

خود مستندات MikroTik درباره مهاجرت به RouterOS v7 اشاره می‌کند که Kernel جدید باعث تغییرات Performance شده و بعضی وظایف ممکن است به CPU و RAM بیشتری نیاز داشته باشند.

بنابراین اگر CPU قبل از Upgrade حدود 20 درصد بوده و بلافاصله بعد از Upgrade به شکل غیرعادی بالا رفته، بهتر است Version، Profiler و Configuration را با وضعیت قبل مقایسه کنید.

آیا Unclassified در Profiler خطرناک است؟

اگر در Profiler با مصرف بالای unclassified مواجه شدید، نباید فوراً نتیجه بگیرید که سخت‌افزار مشکل دارد.

MikroTik برای چنین شرایطی توصیه می‌کند RouterOS را به نسخه جدید ارتقا دهید، وضعیت را پس از Reboot بررسی کنید و اگر مصرف همچنان باقی بود، اطلاعات لازم برای بررسی Support تهیه شود.

در چنین شرایطی بهتر است ابتدا Version دقیق RouterOS و خروجی Profiler را ثبت کنید و سپس اقدام کنید.

یک تست ساده برای پیدا کردن عامل CPU

فرض کنید CPU شما 100 درصد است. این مراحل را انجام دهید:

/system resource cpu print
/tool profile cpu=all
/ip firewall filter print stats
/ip firewall nat print stats
/ip firewall mangle print stats
/ip firewall connection print count-only
/interface print stats
/queue simple print stats
/queue tree print stats

این خروجی‌ها را در یک بازه زمانی که CPU واقعاً بالا است ذخیره کنید. سپس به جای حدس زدن، می‌توانید بر اساس شواهد تصمیم بگیرید.

اگر CPU فقط در ساعات خاصی 100 درصد می‌شود چه؟

این الگو معمولاً نشان می‌دهد یک Event یا Traffic Pattern مشخص در آن ساعت اتفاق می‌افتد.

موارد زیر را بررسی کنید:

• افزایش تعداد کاربران VPN
• Backup
• اسکن‌های شبکه
• افزایش ترافیک
• دانلود یا Upload سنگین
• فعال شدن Jobهای زمان‌بندی‌شده
• مانیتورینگ
• Traffic Flow
• تغییر Routing
• افزایش Connectionها
• حملات یا Port Scan

آیا DDoS می‌تواند CPU MikroTik CHR را 100 درصد کند؟

بله، مخصوصاً اگر حجم بالایی از Packetهای کوچک یا تعداد زیادی Connection جدید وارد Router شود و این ترافیک قبل از Drop شدن مجبور باشد از مراحل مختلف پردازش عبور کند.

یکی از ابزارهایی که در چنین شرایطی اهمیت پیدا می‌کند RAW Firewall است. MikroTik توضیح می‌دهد که RAW می‌تواند بعضی Packetها را قبل از Connection Tracking Drop کند یا در شرایط مناسب آنها را از Connection Tracking عبور دهد؛ این موضوع می‌تواند بار CPU را کاهش دهد.

اما Ruleهای RAW را نباید بدون شناخت ترافیک کپی و اجرا کرد. یک Rule اشتباه می‌تواند باعث قطع سرویس‌های قانونی شود.

چگونه CPU MikroTik CHR را بدون خراب کردن شبکه پایین بیاوریم؟

• ابتدا Profiler را اجرا کنید.
• مصرف هر Core را جداگانه بررسی کنید.
• Packet Rate و Throughput را بررسی کنید.
• Firewall Ruleهای سنگین را پیدا کنید.
• Layer7 را فقط در صورت نیاز استفاده کنید.
• Mangle Ruleهای غیرضروری را حذف یا بهینه کنید.
• Connectionهای غیرعادی را بررسی کنید.
• Queueهای غیرضروری را بررسی کنید.
• Bridge و Tunnelهای غیرضروری را حذف کنید.
• نوع Network Adapter مجازی را بررسی کنید.
• در KVM در صورت امکان Virtio را بررسی کنید.
• در VMware در صورت امکان VMXNET3 را بررسی کنید.
• Sniffer و Traffic Generator را بعد از تست متوقف کنید.
• در صورت نیاز منابع CPU را افزایش دهید.
• اگر مشکل با منابع بیشتر حل نشد، Host و Provider را بررسی کنید.

اشتباهاتی که نباید هنگام CPU 100 درصد انجام دهید

۱. ریستارت فوری بدون بررسی

Restart ممکن است موقتاً CPU را پایین بیاورد، اما علت را مشخص نمی‌کند. ممکن است چند ساعت بعد دوباره همان مشکل تکرار شود.

۲. افزایش CPU بدون بررسی Profiler

اگر مشکل Layer7، Loop، Packet Storm یا Rule اشتباه باشد، خرید vCPU بیشتر راه‌حل واقعی نیست.

۳. حذف Firewall برای تست و فراموش کردن بازگردانی آن

این کار می‌تواند VPS را در معرض دسترسی ناخواسته قرار دهد. اگر برای تست Ruleی را موقتاً تغییر می‌دهید، دقیقاً ثبت کنید چه چیزی تغییر کرده است.

۴. فعال کردن FastTrack بدون بررسی Configuration

FastTrack می‌تواند مسیر پردازش را تغییر دهد و روی Queue، Mangle، IPsec و بعضی قابلیت‌های دیگر اثر بگذارد.

۵. تغییر Network Adapter بدون Backup

در VPS ریموت، تغییر کارت شبکه مجازی می‌تواند باعث از دست رفتن دسترسی شود. همیشه Console یا KVM اضطراری Provider را در اختیار داشته باشید.

یک چک‌لیست سریع برای عیب‌یابی CPU 100 درصد در CHR

جمع‌بندی؛ چرا یک CPU در MikroTik CHR به 100 درصد می‌رسد؟

سؤالات متداول درباره CPU 100 درصد MikroTik CHR

/tool profile cpu=all

کلام آخر

مصرف 100 درصد یک CPU در MikroTik CHR روی VPS یک علامت است، نه یک تشخیص قطعی. ممکن است علت اصلی از ترافیک، Packet Rate، Firewall، Mangle، Connection Tracking، Queue، WireGuard، Tunnel، Bridge، Network Adapter یا حتی زیرساخت VPS باشد.

اگر فقط یک نکته از این مقاله را به خاطر می‌سپارید، این باشد: قبل از افزایش منابع VPS، عامل مصرف CPU را پیدا کنید. دستور /tool profile cpu=all معمولاً بهترین نقطه شروع است. سپس با بررسی Interfaceها، Firewall، Connectionها، Queueها و ساختار مجازی‌سازی می‌توان علت را دقیق‌تر مشخص کرد.