Linux Süreç Yönetimi: Process Komutları Rehberi

Bir sunucu aniden yavaşladığında ya da bir uygulama yanıt vermez hâle geldiğinde, açılan ilk komut genelde top ya da ps olur. Linux'ta çalışan her şey bir süreçtir: açık bir tarayıcı sekmesi, arka planda dönen bir yedekleme scripti, kurulu bir SSH bağlantısı. Bir web sunucusunda beklenmedik bir yavaşlama yaşandığında, sorunun kaynağını dakikalar içinde bulmak genelde doğru komutu bilmekle o komutu doğru sırada çalıştırmak arasındaki farktır.

Süreçleri görmek, önceliklendirmek ve gerektiğinde doğru sinyalle sonlandırmak, sorun giderirken zaman kazandıran temel bir beceridir. Bu yazıda gerçek komutlarla süreç yönetimini ele alıyoruz; örnekler hem masaüstünde hem sunucu ortamında aynı şekilde çalışır.

Çalışan Süreçleri Nasıl Listelersiniz?

ps komutu çalışan süreçlerin o anki anlık görüntüsünü verir; en sık kullanılan hâli aux bayraklarıyla gelir:

ps aux
ps aux | grep nginx

Çıktıdaki sütunlar farklı bilgiler taşır. USER süreci başlatan hesabı, PID ise benzersiz süreç kimliğini gösterir. %CPU ve %MEM sütunları kaynak kullanımını, STAT sütunu ise sürecin durumunu verir (R çalışıyor, S uykuda, Z zombi, D kesintisiz disk beklemesi). VSZ ve RSS sütunları sürecin sanal bellek boyutunu ve gerçekte kullandığı fiziksel bellek miktarını KB cinsinden gösterir. Bir sürecin RSS değeri zamanla sürekli büyüyorsa bu genelde bellek sızıntısının ilk işaretidir.

Sürekli güncellenen canlı bir görünüm için top ya da onun daha okunaklı sürümü htop kullanılır:

top
htop

htop, CPU çekirdeklerini ve bellek kullanımını renkli çubuklarla gösterir. Fareyle süreç seçip doğrudan sinyal göndermeyi de mümkün kılar; çoğu dağıtımda ayrı kurulum gerektirir (sudo apt install htop). top içindeyken 1 tuşu her çekirdeği ayrı satırda gösterir, M tuşu listeyi bellek kullanımına göre sıralar, q tuşu çıkış yapar. Bu kısayolları bilmek, fareye ihtiyaç duymadan hızlı teşhis yapmayı sağlar.

Hangi sürecin hangisini başlattığını ağaç yapısında görmek için:

pstree -p

Bu komut, bir servisin kaç alt süreç (worker) doğurduğunu anlamak için kullanışlıdır; örneğin bir nginx ana süreci altında birden çok worker süreci görülür. pstree -p ahmet gibi kullanıcı adı vererek yalnızca o kullanıcının süreç ağacına bakmak, paylaşımlı bir sunucuda kimin ne çalıştırdığını hızlıca ayırt etmeyi sağlar. Süreçleri listeleyen ps komutunun tüm seçenekleri için ps kılavuz sayfasına bakabilirsiniz.

Süreç Durumları Ne Anlama Gelir?

ps çıktısındaki STAT sütunu, sürecin anlık durumunu tek harfle gösterir. Bu harfleri doğru okumak sorunu teşhis etmenin ilk adımıdır:

D durumu özellikle dikkat gerektirir. Bir süreç bu durumdayken kill -9 bile onu anında durduramaz, çünkü kernel disk işlemi bitmeden sinyali işlemez. Sunucu donmuş gibi göründüğünde ps aux | grep ' D ' komutuyla bu durumdaki süreçleri aramak, sorunun yavaş bir diskten mi yoksa bir NFS bağlantısından mı kaynaklandığını gösterebilir. Bu durumda çözüm genelde beklemektir. Disk yanıt verdiğinde süreç kendiliğinden bir sonraki duruma geçer; zorla sonlandırma seçeneği yoktur.

Zombi süreçler tehlikeli değildir ama birikirse PID tablosunu doldurabilir. Kaynağı genelde üst sürecin wait() çağrısını doğru yapmamasıdır; tek çözüm üst süreci yeniden başlatmaktır. ps aux | awk '$8=="Z"' komutu sistemdeki tüm zombi süreçleri tek satırda listeler. Bir uygulama sunucusunda bu sayı sürekli artıyorsa, uygulama kodundaki bir hata alt süreçleri düzgün temizlemiyor demektir.

Bir Süreci Sonlandırmak: kill Doğru Kullanımı

kill komutu isminin aksine her zaman "öldürmez"; varsayılan olarak nazik bir sinyal gönderir:

kill 4521
kill -15 4521
kill -9 4521

Bayraksız kill aslında SIGTERM (15) gönderir. Bu, sürece "kapanmaya hazırlan, dosyalarını kaydet" diyen kibar bir istektir; program bu sinyali yakalayıp temiz bir kapanış yapabilir. kill -9 ise SIGKILL gönderir. Kernel süreci anında durdurur ve programın hiçbir temizlik yapmasına izin vermez; açık dosya tanıtıcıları ya da yarım kalan disk yazmaları bu yüzden -9 sonrası bozulmaya daha açıktır. Bir veritabanı sürecini -9 ile sonlandırmak, yarım kalan bir yazma işlemi yüzünden veri dosyasını bozabilir. Bu nedenle PostgreSQL veya MySQL gibi servislerde önce her zaman SIGTERM denenmelidir.

Doğru sıra genelde şöyledir: önce SIGTERM gönderin, birkaç saniye bekleyin, hâlâ çalışıyorsa SIGKILL'e geçin:

kill 4521
sleep 5
kill -9 4521

Süreci isimle sonlandırmak isterseniz PID aramaya gerek kalmaz:

pkill -f "python manage.py runserver"
killall firefox

pkill -f, komut satırının tamamında eşleşme arar. Bu yüzden aynı adı taşıyan farklı scriptleri ayırt etmek için kullanışlıdır. killall ise tam süreç adıyla eşleşen tüm örnekleri kapatır; dikkatli kullanılmalıdır, çünkü aynı isimde birden fazla kullanıcıya ait süreç varsa hepsini etkiler.

pkill ve killall ikisi de varsayılan olarak SIGTERM gönderir. -9 bayrağıyla pkill -9 -f runserver gibi kullanmak zorlayıcı bir sonlandırma yapar. Paylaşımlı bir sunucuda killall kullanmadan önce pgrep -l isim ile hangi süreçlerin etkileneceğini görmek, yanlışlıkla başka bir kullanıcının işini kapatmayı önler.

İş Kontrolü: Arka Plana Alma ve Geri Getirme

Uzun süren bir komutu terminali kilitlemeden çalıştırmak için komutun sonuna & eklenir:

tar -czf yedek.tar.gz /var/www &
jobs

jobs komutu, o oturumdaki arka plan işlerini numaralı biçimde listeler. Bir işi ön plana almak için fg, arka planda devam ettirmek için bg kullanılır:

fg %1
bg %1

Ctrl+Z bir süreci sonlandırmaz, yalnızca duraklatır (T durumuna sokar). bg komutu, o duraklatılmış süreci arka planda çalışmaya devam ettirir. %1 ifadesindeki sayı, jobs çıktısındaki iş numarasına karşılık gelir; birden fazla arka plan işi varsa jobs -l her birinin PID'ini de gösterir.

Terminal oturumu kapatıldığında arka plan işleri de genelde SIGHUP sinyali alıp sonlanır. Bundan kaçınmak için nohup ya da disown kullanılır:

nohup ./uzun-script.sh &
disown -h %1

nohup, SIGHUP sinyalini yok sayar ve çıktıyı nohup.out dosyasına yönlendirir; SSH bağlantısı koptuğunda script çalışmaya devam eder. Gerçek üretim ortamlarında uzun süren görevler için nohup yerine tmux ya da screen gibi oturum yöneticileri, ya da doğrudan systemd servis birimi tercih edilir. Bunun nedeni, bu araçların yeniden başlatma ve log yönetimini de üstlenmesidir.

tmux new -s yedekleme komutuyla isimlendirilmiş bir oturum açıp içinde uzun süren işi başlatmak, bağlantı koptuğunda tmux attach -t yedekleme ile kaldığınız yerden devam etmenizi sağlar. Bu, tek seferlik scriptler için nohup'tan daha esnek bir çözümdür.

Süreç Önceliğini Ayarlamak: nice ve renice

Aynı anda birden çok yoğun görev çalıştığında, hangisinin işlemciyi öncelikli kullanacağı nice değeriyle belirlenir. Değer -20 (en yüksek öncelik) ile 19 (en düşük öncelik) arasında değişir:

nice -n 10 ./agir-islem.sh
sudo renice -n -5 -p 4521

Yeni başlatılan bir süreç için nice, çalışan bir sürecin önceliğini değiştirmek için ise renice kullanılır. Negatif değerler yalnızca root tarafından atanabilir; düşük bir nice değeri o sürece diğerlerinden daha fazla işlemci zamanı ayırır ve kötüye kullanılırsa sistemin geri kalanını aç bırakabilir. Arka planda çalışması gereken ama sistemi yavaşlatmaması gereken bir yedekleme scripti için pozitif bir nice değeri (örneğin 10-15) mantıklı bir varsayılandır. Çalışan bir sürecin mevcut nice değerini görmek için ps -o pid,ni,comm -p 4521 komutu kullanılır; bu komut NI sütununda o değeri gösterir ve varsayılan değer genelde 0'dır.

I/O önceliğini ayrı ayarlamak için ionice kullanılır; bu komut, özellikle disk yoğun işlemlerde CPU önceliğinden bağımsız çalışır:

ionice -c 3 rsync -a /data /yedek

-c 3 bayrağı "idle" sınıfını seçer. Bu sınıftaki G/Ç işlemleri yalnızca disk boştayken gerçekleşir; böylece büyük bir rsync işlemi diğer uygulamaların disk erişimini boğmaz. -c 2 -n 0 kombinasyonu ise "best-effort" sınıfında en yüksek önceliği verir. Bu, veritabanı yedekleme gibi zamanında bitmesi gereken ama sistemi kilitlememesi gereken işler için idle ile normal öncelik arasında bir denge kurar.

Sistem Genelinde Kaynak Kullanımını İzlemek

Tek bir sürece değil, sistemin genel yüküne bakmak istediğinizde uptime çıktısındaki "load average" değerleri hızlı bir özet sunar:

uptime

Üç sayı sırasıyla son 1, 5 ve 15 dakikalık ortalama yükü gösterir. Bu sayı çekirdek sayısını aşıyorsa sistem kuyruklama yapıyor demektir. 4 çekirdekli bir sunucuda load average 8 ise, işlemci kapasitesinin iki katı kadar iş kuyrukta bekliyor demektir. Kaç çekirdek olduğunu görmek için nproc komutu tek satırda cevap verir; bu sayıyı bilmeden load average yorumlamak anlamsızdır, çünkü 2 değeri tek çekirdekli bir sistemde kritikken 32 çekirdekli bir sunucuda önemsizdir.

Hangi sürecin en çok bellek ya da CPU tükettiğini sıralamak için:

ps aux --sort=-%mem | head -10
ps aux --sort=-%cpu | head -10

Bu iki komut, "sunucu neden yavaş" sorusuna genelde ilk dakikada cevap verir. head -10 yerine head -5 kullanmak hızlı bir göz atış için genelde yeterlidir; tüm listeye ihtiyaç duymadan en büyük tüketiciyi görürsünüz.

Bellek sızıntısı yapan bir süreç zamanla %MEM sütununda sürekli tırmanır. Bunu erken yakalamak, sistemin tamamen kilitlenmesini beklemekten çok daha ucuza gelir. Düzenli olarak ps aux --sort=-%mem | head çıktısına göz atmayı bir alışkanlık hâline getirmek, kullanıcılar şikayet etmeden önce çoğu performans sorununu fark etmenizi sağlar.

Yazan Celil Uyanikoglu

Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.