Linux’ta İşlem Yönetimi: ps, top ve kill Kullanımı

Linux işlem yönetimi; çalışan süreçleri görmek, kaynak tüketimini ölçmek ve gerektiğinde güvenli biçimde durdurmaktır. ps anlık ayrıntı verir, top canlı izleme sağlar, kill ise PID'ye sinyal gönderir. Doğru sıra önce işlemi tanımlamak, sonra SIGTERM denemek ve yalnızca zorunluysa SIGKILL kullanmaktır.

Linux işlem yönetimi neden yeniden başlatmadan önce gelir?

Bir VPS yavaşladığında, web sunucusu yanıt vermediğinde veya yük ortalaması yükseldiğinde ilk iş sistemi yeniden başlatmak değildir. Önce hangi işlemlerin çalıştığı, ne kadar CPU ve bellek kullandığı, hangi kullanıcıya ait olduğu ve hangi ebeveynden doğduğu incelenir. Linux işlem yönetimi, bu gözlemi güvenli bir müdahaleye dönüştürür.

ps anlık ve ayrıntılı görünüm verir, top canlı izleme sağlar, kill ise kontrollü sinyal gönderir. Üç komut birlikte değerlendirildiğinde bir işlemi bulup kaynak kullanımını anlamak ve gerektiğinde nazikçe sonlandırmak mümkün olur.

İlk kural – İşlemi sonlandırmadan önce PID, kullanıcı, tam komut satırı ve ebeveyn süreci doğrulanmalıdır.

ps ile çalışan işlemler nasıl listelenir?

ps, çalıştırıldığı andaki işlemlerin görüntüsünü verir. Seçenek kullanılmadığında çoğu Linux dağıtımında yalnızca mevcut terminalle ilişkili işlemler gösterilir:

ps

  PID TTY          TIME CMD
 8421 pts/0    00:00:00 bash
 9134 pts/0    00:00:00 ps

PID işlem kimliğidir. TTY terminali, TIME işlemin kullandığı toplam CPU süresini, CMD ise komut adını gösterir. Sunucudaki tüm kullanıcı işlemlerini görmek için sık kullanılan iki biçim şunlardır:

ps aux
ps -ef

ps aux BSD tarzı seçenekleri kullanır ve CPU ile bellek yüzdelerini öne çıkarır. ps -ef ise tam komut satırını, ebeveyn PID’sini ve başlangıç zamanını daha düzenli gösterir. Seçenekleri karıştırırken dikkat edin: ps aux ile ps -aux aynı yazım biçimi değildir.

Belirli bir işlemi aramak

Çıktı uzunsa grep ile filtreleme yapılabilir; ancak grep komutunun kendisi de listede görünebilir:

ps aux | grep '[n]ginx'
pgrep -a nginx
pidof nginx

pgrep -a işlem adını ve komut satırını birlikte verir. Tek bir servisin PID’sini bulmak için pidof daha kısa olabilir. Ayrıntılı incelemede gerekli sütunları açıkça istemek daha güvenlidir:

ps -eo pid,ppid,user,%cpu,%mem,stat,lstart,cmd --sort=-%cpu | head -n 15

Buradaki ppid ebeveyn işlemi, stat mevcut durumu, lstart başlangıç zamanını gösterir. --sort=-%cpu en yüksek CPU tüketen işlemleri üste taşır. Bellek tüketimine göre sıralama için --sort=-%mem kullanılabilir.

Uygulama – Sorun araştırırken önce ps -eo pid,ppid,user,%cpu,%mem,stat,cmd --sort=-%cpu | head -n 15 ile en yüksek CPU kullanan işlemleri görüntüleyin.

top ile canlı kaynak kullanımı nasıl izlenir?

top, işlem listesini belirli aralıklarla yeniler ve CPU, bellek, yük ortalaması ile çalışan süreçleri tek ekranda gösterir:

top

Üst bölümdeki load average değerleri son 1, 5 ve 15 dakikadaki çalıştırılabilir veya bekleyen iş yükünü temsil eder. Bu değer CPU çekirdeği sayısıyla birlikte yorumlanmalıdır. 8 vCPU’lu bir sistemde 2,0 yük tek başına alarm anlamına gelmez; 1 vCPU’lu bir sistemde aynı değer daha belirgin baskıya işaret edebilir.

top içinde bazı tuşlar görünümü doğrudan değiştirir:

• P – CPU kullanımına göre sırala.
• M – bellek kullanımına göre sırala.
• 1 – işlemci çekirdeklerini ayrı ayrı göster.
• c – kısa işlem adı ile tam komut satırı arasında geçiş yap.
• H – iş parçacıklarını göster veya gizle.
• k – PID girerek sinyal gönderme ekranını aç.
• q – programdan çık.

CPU yüzdesi tek başına yeterli değildir. Bir işlem sürekli yüksek CPU kullanıyorsa darboğaz hesaplama olabilir. Bellek tüketimi artıyor ve available değeri düşüyorsa bellek baskısı araştırılmalıdır. Swap kullanımı da ayrıca kontrol edilmelidir:

free -h
vmstat 1 5

free -h toplam, kullanılan ve erişilebilir belleği okunabilir birimlerle verir. vmstat çıktısındaki si ve so değerleri düzenli olarak yükseliyorsa swap giriş-çıkışı vardır. Yavaşlığın nedeni yalnızca tek bir işlemin CPU tüketimi olmayabilir.

CPU ve bellek tüketimi nasıl yorumlanır?

Linux’ta bir işlem için görülen CPU yüzdesi, izleme aracının gösterim biçimine bağlıdır. Çok çekirdekli sistemlerde bir işlemin yüzde 100 CPU kullanması genellikle tek bir mantıksal işlemciyi tamamen kullandığı anlamına gelir. Bazı araçlar toplam makine kapasitesini yüzde 100 kabul eder, bazıları çekirdek başına değer gösterir.

Bellek tarafında RES, işlemin RAM’de tuttuğu yerleşik kısmı; VIRT, sanal adres alanını; SHR ise paylaşılabilir kısmı ifade eder. VIRT değerinin yüksek olması tek başına fiziksel RAM tüketiminin yüksek olduğunu kanıtlamaz. Daha doğru değerlendirme için RES, sistemin available belleği ve süreç sayısı birlikte incelenmelidir.

İşlemin durumu da ipucu verir. R çalışan veya çalışmaya hazır, S kesilebilir uyku, D kesilemeyen bekleme, Z ise sonlanmış fakat ebeveyni tarafından toplanmamış zombi işlemi gösterir. D durumunda işlemi tekrar tekrar öldürmeye çalışmak çoğu zaman çözüm değildir; disk veya ağ depolama gecikmesi incelenmelidir.

ps -eo pid,stat,wchan:32,cmd | awk '$2 ~ /^D/ || $2 ~ /^Z/ {print}'

Bu komut, beklenmeyen D veya Z durumlarını ayıklamaya yardımcı olur. Zombi işlemler için asıl incelenmesi gereken çoğu zaman zombi değil, onu temizlemeyen ebeveyn süreçtir.

Kontrol edin – CPU alarmında işlem durumunu, bellek alarmında RES ve available değerlerini birlikte değerlendirin.

Bir işlemin ebeveynini ve dosyalarını nasıl bulursunuz?

Her Linux işleminin bir PID’si ve çoğunlukla bir ebeveyn PID’si bulunur. Süreç ağacını görmek, bir servisin neden birden fazla worker oluşturduğunu veya kapanan bir işlemin neden yeniden başladığını anlamayı kolaylaştırır:

pstree -aps 9134
ps -o pid,ppid,user,lstart,cmd -p 9134

pstree -aps verilen PID’ye giden ebeveyn zincirini gösterir. ps -o yalnızca seçilen sütunları yazdırır; uzun ve karmaşık çıktılar yerine gerekli bilgiler alınır.

Bir işlemin açık dosyalarını ve ağ soketlerini incelemek için:

lsof -p 9134
ls -l /proc/9134/fd
tr '\0' ' ' < /proc/9134/cmdline; echo

Linux kernel belgelerinde /proc, süreç bilgilerini sanal dosya sistemi üzerinden sunan bir arayüz olarak açıklanır. /proc/PID/fd altındaki sembolik bağlantılar açık dosyaları, soketleri veya pipe nesnelerini gösterir. Yetki yoksa başka kullanıcıların süreç ayrıntıları kısıtlı görünebilir; her incelemeyi root ile yapmak gerekmez.

Bir web uygulamasının hangi portu tuttuğu araştırılıyorsa ss daha uygun olabilir:

ss -ltnp
ss -ltnp | grep ':8080'

Komut satırında portu görmek, uygulama ile reverse proxy arasındaki yanlış yönlendirmeleri ayırmaya yardım eder. Örneğin Nginx’in 80 ve 443 numaralı portlarda dinlerken uygulamanın 127.0.0.1:8080 üzerinde bulunması beklenen bir mimari olabilir.

kill komutu hangi sinyali ne zaman gönderir?

kill adındaki komut yalnızca zorla kapatma yapmaz; bir PID’ye sinyal gönderir. Varsayılan sinyal SIGTERM, yani 15 numaralı sinyaldir. Uygulama bu sinyali yakalayarak bağlantıları kapatabilir, geçici dosyaları silebilir veya kuyruğu güvenli biçimde durdurabilir.

kill 9134
kill -TERM 9134
kill -15 9134

Bu üç kullanım aynı temel sinyali ifade eder. Sürecin kapanıp kapanmadığını yeni bir ps veya pgrep çağrısıyla doğrulayın:

kill -0 9134 && echo 'PID mevcut veya erişilebilir' || echo 'PID bulunamadı ya da izin yok'

kill -0 gerçek bir sonlandırma yapmaz; PID’nin varlığını ve sinyal gönderme yetkisini sınamak için kullanılır. İşlem SIGTERM‘e yanıt vermiyorsa nedenini loglarda arayın. Son çare olarak SIGKILL gönderilebilir:

kill -KILL 9134
kill -9 9134

SIGKILL işlem tarafından yakalanamaz veya ertelenemez. Bu nedenle temizlik kodu çalışmaz; açık bağlantılar, geçici dosyalar ve uygulama içi durum beklenmedik biçimde kalabilir. Veritabanı, dosya yazma veya kuyruk işleyen süreçlerde bu sinyal dikkatle kullanılmalıdır.

Sinyal adlarının listesini görmek için:

kill -l

Bir servis yöneticisi tarafından başlatılmış süreci doğrudan kill -9 ile sonlandırmak yerine servis arayüzünü kullanmak daha doğru olur:

sudo systemctl status nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

Systemd servisi yeniden başlatacak şekilde yapılandırılmışsa doğrudan öldürülen süreç birkaç saniye içinde tekrar ortaya çıkabilir. Bu yeni bir arıza olmayabilir; servis politikasının beklenen davranışıdır.

Sıra önemli – Önce SIGTERM gönderin, kapanışı doğrulayın; SIGKILL‘i yalnızca işlem gerçekten yanıt vermiyorsa kullanın.

Toplu sonlandırma ve servis güvenliği

Birden fazla süreci ada göre kapatmak için pkill veya killall kullanılabilir:

pgrep -a worker
pkill -TERM -u appuser -f '/opt/app/worker.py'

-u kullanıcıyla, -f ise yalnızca kısa işlem adıyla değil tam komut satırıyla eşleştirme yapar. Tam komut satırı eşleştirmesi güçlüdür; aynı metni taşıyan beklenmedik bir süreci de seçebilir. Bu yüzden önce pgrep -a ile sonucu görmeden çalıştırılmamalıdır.

İşlem yönetimi sırasında terminal oturumunun kopması da hesaba katılmalıdır. Uzun süren inceleme veya bakım komutlarında tmux kullanmak, SSH bağlantısı kesildiğinde izleme oturumunu korur. Bir işlemi arka plana almak ile onu bağımsız bir servis haline getirmek aynı şey değildir; üretim görevleri için systemd, supervisor veya uygulamanın kendi servis mekanizması daha izlenebilirdir.

Kaynağı belirlenemeyen bir süreç için hemen kapatma yerine şu sıra izlenebilir: komut satırını görüntüleyin, kullanıcıyı kontrol edin, ebeveyn süreci bulun, açık dosyaları ve soketleri inceleyin, ilgili logları okuyun. Özellikle WordPress kullanan VPS’lerde PHP-FPM worker sayısı, web istekleri ve veritabanı beklemeleri birlikte incelenmelidir. Yalnızca en yüksek CPU kullanan worker’ı öldürmek temel nedeni ortadan kaldırmaz.

İşlem yönetimini otomasyona taşımak

Aynı kontrol adımları üçüncü kez tekrarlanıyorsa küçük bir Bash Script yazmak mantıklı hale gelir. Script önce gözlem yapmalı; otomatik sonlandırma gibi geri dönüşü zor bir adımı varsayılan davranış haline getirmemelidir.

#!/usr/bin/env bash
set -u

pattern="/opt/app/worker.py"

if ! pgrep -af -- "$pattern"; then
  echo "İşlem bulunamadı: $pattern" >&2
  exit 1
fi

echo "Önce PID ve komut satırını doğrulayın. Otomatik kill uygulanmadı."

set -u tanımsız değişkenleri hata olarak ele alır. Bu örnek bilerek işlem sonlandırmaz; üretim otomasyonunda yanlış eşleşmenin etkisini sınırlamak, tek satırlık agresif komutlardan daha değerlidir.

Ansible ile birden fazla VPS’te gözlem komutlarını standartlaştırabilirsiniz. Tek sunucuda bir kez çalışacak bir komut için YAML dosyası açmak ise gereksiz bir katman oluşturabilir. İşlem sayısı, CPU, bellek ve servis durumu monitoring sistemine aktarılıyorsa alarmın yanında PID, komut adı ve son yeniden başlatma zamanı da tutulmalıdır.

Güvenli başlangıç – Otomasyona önce gözlem ve raporlama adımlarını ekleyin; otomatik sonlandırmayı açık onay veya net bir eşik arkasında tutun.

Kaynak tüketen işlemleri incelerken pratik sıra

Bir VPS’in yavaşladığı senaryoda aşağıdaki sıra gereksiz yeniden başlatmaları azaltır:

1. uptime ile yük ortalamasını ve çalışma süresini görün.
2. free -h ile erişilebilir RAM ve swap durumunu kontrol edin.
3. top veya ps ile CPU ve bellek tüketen ilk işlemleri bulun.
4. ps -o pid,ppid,user,stat,cmd -p PID ile işlemi doğrulayın.
5. journalctl -u servis-adı ve uygulama loglarını okuyun.
6. İşlem bir systemd servisi ise systemctl status ve servis politikasını inceleyin.
7. Gerekliyse önce systemctl stop veya SIGTERM kullanın.
8. Son durumu yeniden ölçün; aynı alarm tekrarlanıyorsa kök nedeni araştırın.

Disk doluluğu da işlem davranışını bozabilir. /var dolduğunda log yazamayan uygulamalar kilitlenebilir veya yeni worker başlatamayabilir. Bu durumda ncdu, df -h ve logrotate yapılandırması birlikte kontrol edilmelidir. İşlemi öldürmek dolu diski boşaltmaz.

VPS katmanında CPU çalınma zamanı da gözden kaçabilir. top içindeki st değeri sanal makinenin fiziksel işlemciyi hypervisor ile paylaşırken beklediği zamanı gösterir. Süreçler normal göründüğü halde uygulama yavaşsa VPS sağlayıcısının host yoğunluğu veya sanal CPU kotası ayrıca incelenmelidir.

Güvenli Linux işlem yönetimi, en yüksek sayıyı bulup kapatmaktan ibaret değildir. Ölçüm, kimlik doğrulama, sinyal seçimi ve kapanış sonrası kontrol aynı zincirin parçalarıdır. Bir sonraki alarmda terminale reboot yazmadan önce bu zincirin ilk halkasını kontrol edin.

İşleme Müdahale Etmeden Önce Kontrol Edin

• Yük ortalamasını ve sistemin çalışma süresini görüntüleyin.
• Erişilebilir belleği ve swap kullanımını kontrol edin.
• PID, kullanıcı, tam komut satırı ve ebeveyn PID'sini doğrulayın.
• İşlemin açık dosyalarını ve dinlediği soketleri inceleyin.
• İlgili servis ve uygulama loglarını okuyun.
• Önce SIGTERM veya servis yöneticisiyle kontrollü durdurma uygulayın.
• Kapanıştan sonra servis durumunu ve alarmın tekrarlanıp tekrarlanmadığını ölçün.

Sık Sorulan Sorular

Kaynaklar

• Linux kernel – The /proc Filesystem — docs.kernel.org