MikroTik Yavaş mı? CPU %100 ve Performans Teşhisi

Kısa cevap: “MikroTik yavaş” şikayetinin teşhisi tahminle değil iki araçla konur: Profile (CPU’yu ne yiyor?) ve Torch (hattı kim dolduruyor?). Bu yazıda sahada kullandığım sırayla gidiyoruz; çoğu vaka beş kalemden birine çıkar.

Adım 1: Şikayeti ayrıştır

“Yavaş” üç farklı şey olabilir; teşhis yolu değişir:

1. Hız testi düşük → kapasite sorunu (CPU, hat, kablosuz)
2. Hız iyi ama gecikme/kopma var → doluluk, bufferbloat, kablosuz ortam, hat kalitesi
3. Belirli bir servis yavaş → DNS, MTU veya o servisin kendisi

/system resource print ile CPU’ya bakın: sürekli %90+ ise Adım 2’ye, düşükse Adım 4’e atlayın.

Adım 2: Profile ile suçluyu isimlendir

/tool profile duration=10s

Çıktı CPU’yu kalem kalem gösterir. Sahada en sık gördüğüm şişkinlikler ve anlamları:

Profile kalemi	Anlamı	Tipik kök neden
firewall	Paketler kural zincirinde yoruluyor	Fasttrack yok/deliniyor, kural tasarımı savruk
queuing	Kuyruk sistemi CPU’da	Çok sayıda simple queue, fasttrack’siz QoS
wireless	Kablosuz sürücü yükü	Router aynı anda yoğun AP’lik yapıyor
ppp, encrypting	PPPoE/VPN şifreleme	Donanım hızlandırması olmayan cihazda tünel yükü
dns	DNS sunucusu yoruluyor	Cihaz internete açık resolver olmuş (ciddi bulgu!)
unclassified/networking	Genel paket işleme	Küçük paket fırtınası, tarama/saldırı trafiği

dns kaleminin şişmesi özel dikkat ister: cihazınız internete açık DNS çözücü olarak keşfedilmiş olabilir; bu hem performans hem güvenlik sorunudur (servis sıkılaştırma rehberine bakın).

Adım 3: Fasttrack gerçekten çalışıyor mu?

Fasttrack, kurulu bağlantı paketlerini zincirlerin büyük kısmından kaçırarak yönlendirme maliyetini düşürür; varlığı ile yokluğu arasında aynı cihazda kat kat fark vardır.

/ip firewall filter print where action=fasttrack-connection
/ip firewall filter print stats where action=fasttrack-connection

Kontrol listesi:

• Kural var mı ve sayaçları artıyor mu? Varlığı yetmez; üstündeki bir kural trafiği yakalayıp fasttrack’e düşürmüyor olabilir (sıralama!).
• Mangle/queue kullanıyorsanız bilinçli kapatılmış olabilir; o zaman CPU maliyeti QoS’un bedelidir ve queue tasarımı ile dengelenir.
• Kanıt: hız testi sırasında /tool profile çıktısında firewall kaleminin makul kalması.

Adım 4: CPU değilse Torch ile hatta bak

/tool torch interface=ether1 src-address=0.0.0.0/0 dst-address=0.0.0.0/0

Torch, hattı o anda kimin doldurduğunu IP/port bazında gösterir. Bir istemcinin bulut yedeklemesi, güncelleme fırtınası veya sızmış bir cihazın taşma trafiği; “internet yavaş” vakalarının en sıradan ama en çok atlanan cevabıdır. Kalıcı görünürlük için bu işi Zabbix ile izlemeye bağlamak gerekir.

Fiziksel katmanı da aynı adımda kapatın:

/interface ethernet print stats
/interface ethernet monitor ether1 once

rx-fcs-error, rx-align-error artıyorsa veya port 100M-half’a düşmüşse sorun yazılımda değil kabloda/portta demektir.

Adım 5: Kablosuz yükü ve şifreleme

• Router’ınız aynı zamanda yoğun bir ortamda AP’lik yapıyorsa wireless kalemi CPU’yu yer; kalabalık ortamda yayını ayrı AP’lere (CAPsMAN veya UniFi hibrit) taşımak router’ı rahatlatır.
• PPPoE ve VPN şifrelemesi, donanım hızlandırması olmayan modellerde pahalıdır. Çok tünelli yapılarda encrypting kalemi şişiyorsa çözüm ya tünel sayısını konsolide etmek ya da hızlandırmalı bir modele geçmektir.

Kalıcı çözüm sırası

1. Fasttrack’i doğrula ve kural sırasını düzelt (established/related kabulü en üste)
2. Kuralları address-list’lerle sadeleştir; kullanılmayan servisleri kapat
3. Hattı dolduran istemciyi bul, gerekiyorsa kuyrukla sınırla
4. Kablosuz yükünü ayır, fiziksel katmanı temizle
5. Bunlardan sonra hâlâ dardaysanız cihaz gerçekten küçük demektir; büyütmeden önce trafiğinizi bilerek model seçin

Teşhisi birlikte koymak veya filonuzda kalıcı performans standardı kurmak isterseniz MikroTik destek hizmetime ulaşabilirsiniz.