Süreçleri İzleme (ps, top ve htop)

Sunucunuz bir sabah beklenmedik biçimde ağırlaşır; site açılışları uzar, panel yavaşlar, hatta SSH oturumu bile takılır takılır gelir. İlk refleks çoğu zaman sunucuyu yeniden başlatmaktır, oysa bu yalnızca sorunu erteler. Gerçek çözüm, o an sunucuda tam olarak neyin çalıştığını görmek ve kaynakları asıl kimin tükettiğini bulmaktan geçer. Linux'ta çalışan her program bir süreç (process) olarak yaşar ve her sürecin bir kimlik numarası (PID), bir sahibi, bir CPU payı ve bir bellek ayak izi vardır. Bu bilgileri okumayı öğrendiğinizde, sunucu davranışı bir sırdan çıkıp okunabilir bir tabloya dönüşür.

Bu rehberde süreç izlemenin üç temel aracını gerçek örneklerle ele alacağız: her yerde hazır bulunan ve tek seferlik anlık görüntü için ideal olan ps; sistemi canlı ve sürekli izleyen klasik top; ve top'un renkli, etkileşimli, çok daha okunabilir halefi htop. Amacımız komutları ezberletmek değil; çıktının hangi sütununun ne anlattığını kavratıp, "sistemi yavaşlatan işlem hangisi?" sorusuna dakikalar içinde net bir PID ile yanıt verebilmenizi sağlamak. Temel terminal kullanımına henüz alışık değilseniz önce temel Linux komutları yazımıza göz atmanız, buradaki örnekleri daha rahat takip etmenizi sağlar.

Süreç Nedir ve Neden İzlenir?#

Bir süreç, çalışmakta olan bir programın hafızadaki canlı örneğidir. Aynı programı iki kez açtığınızda iki ayrı süreç oluşur; her birinin kendi PID'si, kendi bellek alanı ve kendi durumu vardır. Web sunucunuz (Nginx, Apache), veritabanınız (MySQL, PostgreSQL), PHP-FPM işçileri, arka plan işleri ve hatta bağlandığınız SSH oturumu — hepsi birer süreçtir. Sunucu performansı dediğimiz şey, aslında bu süreçlerin sınırlı CPU ve bellek kaynağını nasıl paylaştığının toplamıdır.

Süreçleri izlemek şu somut durumlarda hayat kurtarır: bir eklenti ya da kötü yazılmış bir sorgu CPU'yu %100'e çivilediğinde, bellek sızıntısı yapan bir uygulama RAM'i yavaş yavaş tükettiğinde, beklenmedik bir işlem (örneğin madencilik yazılımı bulaşmış bir betik) kaynak çaldığında ya da bir servisin gerçekten ayakta olup olmadığını doğrulamak istediğinizde. Her sürecin ayrıca bir durumu vardır; en sık göreceğiniz durum kodları şunlardır:

Bu kodları özellikle ps ve top çıktısında sık göreceksiniz. Bol miktarda D durumundaki süreç genellikle CPU değil disk sorununa; kalıcı Z yığılması ise ebeveyn süreçteki bir hataya işaret eder.

ps ile Anlık Süreç Görüntüsü#

ps (process status), o anki süreçlerin donmuş bir fotoğrafını verir; canlı yenilenmez ama betiklerde, log almada ve hızlı sorgularda paha biçilmezdir. İki farklı geleneği olduğu için iki popüler kullanımı vardır. BSD tarzı ps aux ve UNIX tarzı ps -ef. İkisi de tüm süreçleri listeler, sütunları biraz farklıdır.

# Tüm süreçleri BSD tarzıyla listele
ps aux

# Tüm süreçleri UNIX tarzıyla, tam komut yoluyla listele
ps -ef

ps aux çıktısının bir satırı tipik olarak şöyle görünür:

USER   PID  %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
mysql  842  12.4  8.1 1284560 331204 ?   Ssl  09:12   4:37 /usr/sbin/mysqld
www-data 991 3.2  1.4  248112  58204 ?   S    09:12   0:11 php-fpm: pool www

Sütunların anlamı şöyledir. USER sürecin sahibi, PID benzersiz süreç numarası (işi durdururken bunu kullanacaksınız), %CPU ve %MEM o anki CPU ve RAM yüzdesi, VSZ sürecin talep ettiği toplam sanal bellek, RSS ise gerçekte fiziksel RAM'de tuttuğu boyut (kilobayt). Bellek darboğazlarını incelerken VSZ değil RSS'e bakın; gerçek RAM tüketimi RSS'tir. STAT yukarıdaki durum kodudur, TIME sürecin başından beri harcadığı toplam CPU zamanı, COMMAND ise onu başlatan komuttur.

ps tek başına sıralama yapmaz, ama çıktısını sort ile eşleyerek en oburları hemen bulabilirsiniz:

# CPU'yu en çok tüketen ilk 10 süreç
ps aux --sort=-%cpu | head -n 11

# Belleği (RSS) en çok tüketen ilk 10 süreç
ps aux --sort=-%mem | head -n 11

# Yalnızca belirli bir uygulamanın süreçlerini bul
ps -ef | grep nginx

İlk satır başlık olduğu için head -n 11 yazıp gerçekte 10 süreç görüyoruz. Belirli bir servisi ararken grep çok pratiktir; sonuçlarda grep'in kendisini görmemek için ps aux | grep [n]ginx gibi köşeli parantez numarası da kullanılabilir. Süreç ağacını, yani hangi sürecin hangisini doğurduğunu görmek isterseniz:

# Süreçleri ebeveyn-çocuk ağacı olarak göster
ps -ef --forest

# Sadece süreç isim ağacı (kompakt)
pstree -p

Ağaç görünümü özellikle PHP-FPM veya bir web sunucusunun işçi süreçlerinde işe yarar: ana (master) sürecin altında onlarca işçi (worker) süreci sıralanır ve sorunun tek bir işçide mi yoksa ana süreçte mi olduğunu ayırt edebilirsiniz.

top ile Canlı İzleme#

ps bir fotoğrafsa, top canlı yayındır. Terminale top yazıp Enter'a bastığınızda ekran her birkaç saniyede bir kendini yeniler ve o anki en yoğun süreçleri üstte gösterir. Çıkmak için q tuşuna basmanız yeterlidir. Çıktı iki bölümden oluşur: üstteki özet paneli ve alttaki süreç tablosu.

Özet panelinin ilk satırındaki en kritik değer load average'dır (yük ortalaması):

top - 14:32:07 up 12 days,  3:41,  2 users,  load average: 0.42, 0.75, 1.10

Buradaki üç sayı sırasıyla son 1, 5 ve 15 dakikanın ortalama sistem yükünü gösterir. Yorumlamanın altın kuralı şudur: bu sayıları sunucunuzun CPU çekirdek sayısıyla kıyaslayın. nproc komutuyla çekirdek sayınızı öğrenirsiniz. 4 çekirdekli bir sunucuda yük ortalaması 4.0 ise CPU tam kapasite ama henüz "tıkanmamış" demektir; 8.0 ise iş kuyruğu birikmiş, sistem boğuluyordur. Üç sayının yönü de bilgi verir: 1 dakikalık değer 15 dakikalıktan büyükse yük artıyor, tersi ise geçiyor demektir.

Özet panelinin diğer satırları da önemlidir:

%Cpu(s):  8.3 us,  2.1 sy,  0.0 ni, 88.9 id,  0.5 wa,  0.0 hi,  0.2 si
MiB Mem : 3936.0 total,  412.5 free,  2110.8 used,  1412.7 buff/cache
MiB Swap: 2048.0 total,  1620.3 free,   427.7 used.  1502.1 avail Mem

CPU satırında us kullanıcı programlarının, sy çekirdeğin (sistem), id boşta (idle) geçen oranı, wa ise disk beklemesini (I/O wait) gösterir. Yüksek wa neredeyse her zaman disk darboğazına işaret eder ve bunu CPU sorunu sanmak sık yapılan bir hatadır. Bellek satırında dikkat edilecek nokta buff/cache'in "dolu" sayılmamasıdır; Linux boş RAM'i disk önbelleği olarak kullanır ve gerektiğinde anında boşaltır, bu yüzden gerçek serbest bellek için avail Mem değerine bakın. Swap satırındaki used sürekli artıyorsa RAM yetmiyordur ve sunucu diske "taşıyor" demektir; bu ciddi bir yavaşlama nedenidir.

Alttaki süreç tablosunda %CPU, %MEM, RES (RSS ile aynı, fiziksel bellek), VIRT (sanal bellek, ps'teki VSZ karşılığı) ve S (durum) sütunları yer alır. top içinde birkaç kısayol hayatınızı kolaylaştırır:

Kaynak tüketen süreci bulmanın en hızlı yolu genellikle top açıp M ya da P tuşuna basmaktır: obur süreç anında en üste zıplar ve PID'sini oradan okursunuz.

htop: Renkli ve Etkileşimli Alternatif#

top her sistemde vardır ama arayüzü spartadır. htop, aynı işi çok daha okunabilir, renkli ve fareyle bile kullanılabilen bir arayüzle yapar. Çoğu minimal sunucu kurulumunda önceden yüklü gelmez, o yüzden önce kurmanız gerekebilir:

# Ubuntu / Debian
sudo apt update && sudo apt install -y htop

# AlmaLinux / Rocky / CentOS Stream
sudo dnf install -y htop

# Eski CentOS 7
sudo yum install -y epel-release && sudo yum install -y htop

Kurduktan sonra sadece htop yazın. Üstte her CPU çekirdeği için ayrı renkli çubuklar, bellek ve swap göstergeleri; altta ise süreç listesi belirir. htop'un top'a göre en büyük avantajları: PID'yi elle ezberlemeden ok tuşlarıyla bir sürecin üzerine gelip işlem yapabilmeniz, süreç ağacını tek tuşla açabilmeniz ve alt satırdaki fonksiyon tuşu menüsüyle hiçbir kısayolu ezberlemeden çalışabilmenizdir. En sık kullanılan kısayollar şunlardır:

Bir örnek senaryo: sunucu yavaş, hemen htop açıyorsunuz. Üstteki CPU çubuklarından biri kıpkırmızı ve %100. F6 ile listeyi PERCENT_CPU'ya göre sıralıyor, en üstteki php sürecine ok tuşuyla geliyor, F5 ile ağacı açıp bunun hangi web sitesinin FPM havuzundan geldiğini görüyorsunuz. Suçlu artık belli. htop'un bir başka güzelliği, seçili sürecin çalıştığı komutun tam satırını altta göstermesidir; böylece "bu python süreci hangi betiği çalıştırıyor?" sorusuna anında yanıt alırsınız.

top ile htop arasında pratik farkı özetlersek:

Kısacası hızlı bir kontrol ve her sunucuda garantili çalışması için top, günlük konforlu izleme için htop tercih edilir. İkisini de bilmek en sağlıklısıdır; çünkü yeni kurulmuş bir sunucuda htop henüz yokken top imdadınıza yetişir.

Sistemi Yavaşlatan İşlemi Bulmak ve PID'yi Yakalamak#

Şimdi tüm bu bilgiyi bir teşhis akışında birleştirelim. Sunucunuz yavaşladığında adım adım şunu izleyin. Önce yük tipini belirleyin: sorun CPU mu, bellek mi, disk mi? top ya da htop açıp özet paneline bakın. Yük yüksek ve %Cpu satırındaki us/sy yüksekse CPU darboğazı; wa yüksekse disk darboğazı; swap kullanımı artıyorsa bellek darboğazıdır.

CPU sorunu için en obur süreci bulmak birkaç saniye sürer:

# Tek satırda CPU'yu en çok yiyen 5 süreç ve PID'leri
ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%cpu | head -n 6

Çıktının ilk sütunu PID'dir; aradığınız numara odur. Bellek sorunu içinse aynı sorguyu --sort=-%mem ile çalıştırıp RES/%MEM'e bakarsınız. Disk (I/O) sorununda top'taki %CPU yerine, hangi sürecin disk beklettiğine bakmak gerekir; bunun için iotop aracı idealdir (kurulmamışsa apt install iotop), ya da ps çıktısında bol D durumundaki süreçleri arayabilirsiniz.

Suçlu PID'yi bulduktan sonra iki yolunuz var. Sürecin ne olduğunu doğrulamak için:

# PID 4821'in tam komut satırını ve çalışma dizinini gör
ps -p 4821 -o pid,user,%cpu,%mem,etime,args
ls -l /proc/4821/cwd

Eğer bu gerçekten kontrolden çıkmış, güvenli biçimde durdurulabilir bir süreçse, önce nazik yolu deneyin. Kill sinyalleri sürece "kendini toparla ve kapan" ya da "hemen öl" der:

# Nazik durdurma (süreç kendini temiz kapatır) - önce bunu deneyin
kill 4821

# İnatçıysa zorla sonlandırma (son çare)
kill -9 4821

# İsimle tüm eşleşen süreçleri durdur
pkill -f "eski-betik.py"

kill varsayılan olarak TERM (nazik) sinyali gönderir; süreç kendini kapatma şansı bulur, açık dosyaları düzgün kaydeder. Yanıt vermeyen bir süreçte son çare olarak kill -9 (KILL) kullanılır ama bu süreci hiç uyarmadan öldürdüğü için veri kaybı riski taşır; alışkanlık haline getirmeyin. Önemli bir uyarı: bir servisi (örneğin MySQL veya Nginx) süreç olarak kill ile öldürmek yerine, her zaman düzgün yolu tercih edin ve systemctl restart mysql gibi servis yöneticisi üzerinden yeniden başlatın; aksi halde servis yarım durumda kalabilir. Servisleri sağlıklı biçimde durdurup başlatma konusunu systemd servis yönetimi yazımızda ayrıntılı ele aldık.

Son bir ipucu: yüksek kaynak kullanan sürecin PID'sini bulduğunuzda hemen öldürmek yerine bir dakika etime (çalışma süresi) ve deseni gözleyin. Kısa süreli bir yedekleme ya da güncelleme işi doğal olarak CPU'yu geçici yükseltebilir; asıl sorun, dakikalarca %100'de sabit kalan ve iş yükünüzle açıklanamayan süreçtir.

Kaynak Sürekli Yetmiyorsa: Kalıcı Çözümler#

İzleme araçları size "şu an ne oluyor" sorusunun yanıtını verir, ama bazen yanıt basittir: sunucunuz mevcut iş yükü için gerçekten yetersizdir. Eğer top ve htop'ta yük ortalaması sürekli çekirdek sayınızın üzerinde geziyor, swap kalıcı olarak doluysa ve tek bir "suçlu" süreç değil topluca tüm süreçler kaynak için yarışıyorsa, sorun bir eklenti değil kapasitedir.

Böyle durumlarda birkaç yaklaşım vardır. Yazılım tarafında; gereksiz servisleri kapatabilir, PHP-FPM işçi sayısını RAM'inize göre ayarlayabilir, veritabanı sorgularını optimize edebilir ve önbellekleme (cache) ekleyerek CPU yükünü düşürebilirsiniz. WordPress gibi popüler uygulamalarda kaynak sorunlarının önemli bölümü kötü yazılmış eklentilerden kaynaklanır; düzenli bakım bu yükü ciddi biçimde azaltır. Bu tür bir bakımı kendiniz üstlenmek istemezseniz WordPress bakım hizmetimiz devreye girer. Donanım tarafında ise en temiz çözüm daha güçlü bir plana geçmektir; paylaşımlı bir hosting paketinden kaynaklarınızın size ayrıldığı bir sanal sunucuya ya da yüksek performanslı bir VDS sunucuya yükselmek çoğu darboğazı kökten çözer.

İşin yönetim yükünü hiç taşımak istemiyorsanız, süreç izleme dahil tüm sistem sağlığını sizin adınıza takip ettiğimiz sunucu yönetimi hizmetimizle sunucunuzu uzman ellere bırakabilirsiniz. Kaynak planlaması yaparken doğru boyutu seçmek için mevcut kullanımınızı bir süre top/htop ile gözlemlemek, tahmin yürütmekten her zaman daha isabetlidir.

Sıkça Sorulan Sorular#

ps aux ile ps -ef arasındaki fark nedir?#

İkisi de sistemdeki tüm süreçleri listeler ama farklı geleneklerden gelir ve sütunları biraz değişir. ps aux BSD tarzıdır ve %CPU ile %MEM yüzdelerini net gösterdiği için kaynak analizinde daha pratiktir; ps -ef ise UNIX tarzıdır ve ebeveyn süreç numarası (PPID) ile tam komut yolunu göstermede daha güçlüdür. Günlük kullanımda hangisine alışırsanız onu tercih edebilirsiniz; kaynak avında ps aux --sort çoğu kişinin favorisidir.

top çıktısındaki load average tam olarak neyi ölçer?#

Load average, sisteminizde çalışan ya da CPU sırasında bekleyen ortalama süreç sayısını son 1, 5 ve 15 dakika için gösterir. Bu sayıyı tek başına değil, sunucunuzun çekirdek sayısıyla kıyaslayarak yorumlamalısınız. nproc ile öğrendiğiniz çekirdek sayınıza eşit bir yük tam kapasiteyi, üzerindeki bir yük ise iş kuyruğunun biriktiğini ve gecikme yaşandığını anlatır. Örneğin 2 çekirdekli bir sunucuda 4.0'lık bir yük ciddi bir tıkanma işaretidir.

htop kurulu değil, kaldırmadan kurabilir miyim?#

Evet, htop bağımsız bir araçtır ve mevcut top'u kaldırmaz ya da bozmaz; ikisi de sistemde yan yana durabilir. Ubuntu veya Debian'da sudo apt install htop, AlmaLinux veya Rocky'de sudo dnf install htop komutu yeterlidir. Kurulum sonrası htop'u tercih etseniz bile top yerinde kalır, dolayısıyla yeni bir sunucuda htop henüz yokken top'a güvenle geçebilirsiniz.

Bir süreci kill ile öldürmek güvenli mi?#

Sıradan kill komutu sürece nazik bir kapanma sinyali (TERM) gönderir ve süreç açık dosyalarını düzgün kaydedip kapanma şansı bulur, bu yüzden çoğu durumda güvenlidir. Riskli olan kill -9 yani KILL sinyalidir; süreci hiç uyarmadan anında öldürür ve kaydedilmemiş veri kaybına yol açabilir, o yüzden yalnızca yanıt vermeyen süreçlerde son çare olarak kullanın. MySQL, Nginx gibi servisleri ise kill yerine systemctl restart ile yeniden başlatmak en doğrusudur.

Yüksek CPU mu yoksa yüksek disk kullanımı mı olduğunu nasıl ayırt ederim?#

Bunu top ya da htop'un özet panelindeki CPU satırından ayırt edersiniz. %Cpu satırında us (kullanıcı) ve sy (sistem) değerleri yüksekse sorun gerçek CPU yüküdür; buna karşılık wa (I/O wait) değeri yüksekse süreçler diskin yanıtını bekliyordur ve darboğaz disktedir. Disk sorununu doğrulamak için iotop aracıyla hangi sürecin en çok disk okuyup yazdığına bakabilir, ps çıktısında da D durumundaki süreçlerin çokluğunu bir ipucu olarak değerlendirebilirsiniz.

RES ve VIRT sütunları arasındaki fark nedir, hangisine bakmalıyım?#

VIRT (ps'teki VSZ) bir sürecin işletim sisteminden talep ettiği toplam sanal bellek alanıdır ve genelde gerçekte kullanılandan çok daha büyüktür; paylaşımlı kütüphaneleri ve henüz kullanılmamış rezervasyonları da içerir. RES (ps'teki RSS) ise sürecin o an fiziksel RAM'de gerçekten tuttuğu boyuttur. Bellek tüketimini değerlendirirken neredeyse her zaman RES değerine bakmalısınız; VIRT'in yüksek olması tek başına bir sorun işareti değildir.

Kapanış#

Süreç izleme, sunucu yöneticiliğinin belki de en pratik becerisidir; çünkü "sunucu yavaş" gibi belirsiz bir şikâyeti, tek bir PID'ye ve somut bir eyleme indirger. ps ile anlık bir fotoğraf çeker, top ile canlı yükü izler, htop ile de tüm bunu renkli ve etkileşimli biçimde yaparsınız. Load average'ı çekirdek sayınızla kıyaslamayı, RES üzerinden gerçek bellek kullanımını okumayı ve --sort ile oburları anında öne çıkarmayı alışkanlık haline getirdiğinizde, çoğu performans sorununu daha büyümeden yakalarsınız.

Bu araçlarla sürekli kaynak sıkıntısı gördüğünüzde ise sorun izlemede değil kapasitededir. İhtiyacınıza uygun bir hosting paketi, kaynaklarınızın size ayrıldığı bir sanal sunucu ya da yüksek performanslı bir VDS için Clou.TR ürün sayfalarına göz atabilir; kurulumdan güncellemeye kadar tüm sistem sağlığını bize bırakmak isterseniz sunucu yönetimi hizmetimizle sunucunuzu uzman ellere teslim edebilirsiniz.