Rehber

Linux'ta süreçler: ps, top, htop, kill, sinyaller ve nice

Güncellendi: · Skillaria.Top

Linux süreçleri ps aux (anlık görüntü), top ve htop (yenilenen liste ve yük) ile izlenir. kill PID komutu varsayılan olarak nazik SIGTERM gönderir; kill -9 (SIGKILL) yalnızca süreç yanıt vermediğinde kullanılmalıdır. Öncelik başlatırken nice ile, çalışan süreç için renice ile değiştirilir; aralık -20 ile 19 arasındadır.

Linux'ta çalışan her program, kendi PID numarası, sahibi, durumu ve önceliğiyle bir süreçtir. Süreçleri ps, top ve htop ile görebilir, kill ile sonlandırabilir, nice ve renice ile önceliklerini değiştirebilirsiniz. Aşağıda bu komutların çıktısını nasıl okuyacağınızı, hangi sinyali ne zaman göndereceğinizi ve neden kill -9'un ilk refleksiniz olmaması gerektiğini anlatıyoruz.

Süreç ve PID nedir

Süreç, çalışma anındaki bir programdır: kodu, belleği, açık dosyaları ve bir dizi özniteliği vardır. Çekirdek her sürece benzersiz bir PID tanımlayıcısı verir ve onu başlatan ebeveynin numarası olan PPID'i de kaydeder. Sistemdeki ilk süreç, PID 1, genellikle systemd'dir ve diğer tüm süreçlerin “atası” olur.

Yeni bir süreç iki adımda oluşur. Önce ebeveyn fork() çağrısıyla kendi kopyasını oluşturur, sonra kopya execve() çağrısıyla kendi kodunu yeni programın koduyla değiştirir. Terminale ls yazdığınızda bash tam olarak bunu yapar ve çocuk sürecin bitmesini wait() ile bekler.

$ echo $$          # geçerli kabuğun PID'i
4182
$ ps -o pid,ppid,cmd -p $$
    PID    PPID CMD
   4182    4170 -bash

ps ile süreçleri görüntüleme

ps anlık bir görüntü alır: süreçleri yalnızca komutu çalıştırdığınız andaki haliyle gösterir ve çıkar. Argümansız çalıştırıldığında yalnızca geçerli terminale ait süreçleri listeler; bu yüzden pratikte neredeyse her zaman iki seçenekten biri kullanılır.

$ ps aux | head -5
USER       PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
root         1  0.0  0.3 168540 12780 ?     Ss   09:12   0:03 /sbin/init
root         2  0.0  0.0      0     0 ?     S    09:12   0:00 [kthreadd]
www-data  1532  1.2  2.1 412308 86420 ?     S    09:15   1:47 php-fpm: pool www
postgres  1610  0.4  3.8 221004 154312 ?    Ss   09:15   0:31 postgres: checkpointer

Burada a tüm kullanıcıların süreçlerini, u sahibi de içeren ayrıntılı biçimi, x terminali olmayan süreçleri (daemon'lar) gösterir. System V tarzındaki alternatif sözdizimi ps -ef'tir: PPID'i gösterir; kimin kimi başlattığını anlamak istediğinizde kullanışlıdır.

SütunAnlamı
PIDsüreç tanımlayıcısı
%CPU, %MEMişlemci ve fiziksel bellek payı
VSZKB cinsinden sanal bellek (RAM'e yüklenmemiş olanlar dahil)
RSSKB cinsinden gerçekten kullanılan fiziksel bellek
STATsüreç durumu (R, S, D, Z, T) ve bayraklar
TIMEtoplam işlemci süresi, çalışma süresi değil

ps ile faydalı yöntemler

# bellekte ilk 10
ps aux --sort=-%mem | head -11

# işlemcide ilk 10
ps aux --sort=-%cpu | head -11

# kendi sütunlarınız
ps -eo pid,ppid,user,ni,stat,etime,cmd

# süreç ağacı
ps -ef --forest
pstree -p

# ada göre PID bulma
pgrep -a nginx
pidof nginx

Sık yapılan hata, ps aux | grep nginx ile süreç aramak ve çıktıda grep'in kendisini görmektir. pgrep kullanın veya kendi komut satırıyla eşleşmeyen grep [n]ginx numarasını uygulayın.

Süreç durumları: R, S, D, Z, T

STAT sütunundaki harf süs değildir, sürecin gerçek durumudur. Yükü nasıl yorumlayacağınız ve kill'in işe yarayıp yaramayacağı buna bağlıdır.

KodDurumPratikte ne anlama gelir
RRunningçalışıyor veya CPU kuyruğunda bekliyor
SInterruptible sleepbir olay bekliyor (ağ, girdi, zamanlayıcı); çoğu sürecin olağan durumu
DUninterruptible sleepçekirdek içinde G/Ç bekliyor, sinyaller iletilmez
ZZombiesonlandı, ama ebeveyn çıkış kodunu almadı
TStoppedSIGSTOP sinyali veya Ctrl+Z ile durduruldu

Harfin ardındaki ek simgeler de faydalıdır: s — oturum lideri, + — terminalin ön plan süreci, < — yüksek öncelik, N — düşük öncelik, l — çok iş parçacıklı.

D durumundaki süreç

D durumundaki süreç bir sistem çağrısının içindedir ve örneğin diskten veya takılmış bir NFS'ten yanıt bekler. Ona hiçbir sinyal iletilmez, SIGKILL bile. Bu yüzden burada kill -9 işe yaramaz: beklemenin nedenine bakmalısınız — iostat, dmesg, ağ depolamanın durumu.

Zombi süreçler

Zombi zaten ölmüştür: CPU ya da bellek tüketmez, yalnızca süreç tablosunda bir satır yer kaplar. Onu öldüremezsiniz, çünkü zaten sonlanmıştır. Ebeveyn wait() çağırdığında ya da ebeveyn kendisi sonlandığında zombi, PID 1 tarafından evlat edinilip kaldırılır.

# zombileri ve ebeveynlerini bul
ps -eo pid,ppid,stat,cmd | awk '$3 ~ /Z/'

Tek bir zombi zararsızdır. Yüzlercesi varsa ve sayı artıyorsa, sorun ebeveyn programdadır: düzeltilmeli veya yeniden başlatılmalıdır.

top: gerçek zamanlı süreçler ve yük

top aynı listeyi gösterir, ama birkaç saniyede bir yeniler ve sistem özetini de verir. “Sunucu yavaşladı” dendiğinde ilk çalıştırılan komut budur.

top - 14:21:07 up 12 days,  3:02,  2 users,  load average: 1.84, 1.20, 0.95
Tasks: 213 total,   2 running, 211 sleeping,   0 stopped,   0 zombie
%Cpu(s): 23.1 us,  4.2 sy,  0.0 ni, 70.3 id,  1.9 wa,  0.0 hi,  0.5 si,  0.0 st
MiB Mem :   7821.4 total,    412.6 free,   3105.8 used,   4303.0 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   4398.2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1532 www-data  20   0  412308  86420  14212 R  38.2   1.1   1:47.31 php-fpm
   1610 postgres  20   0  221004 154312 148900 S   6.0   1.9   0:31.08 postgres

Satır %Cpu(s) en önemlisidir: us kullanıcı kodu, sy çekirdek, id boşta, wa disk beklemesi. İşlemci boşken wa değerinin yüksek olması, darboğazın girdi/çıktıda olduğunun işaretidir.

top kısayol tuşları

Tuşİşlem
P / MCPU / bellek sıralaması
1her çekirdeği ayrı göster
ctam komut satırı
ukullanıcıya göre filtre
ksürece sinyal gönder
rsürecin nice değerini değiştir
Hiş parçacıklarını göster
qçıkış

Betikler ve loglar için toplu mod kullanışlıdır: top -b -n 1 | head -20 etkileşim olmadan tek bir görüntü verir. Belirli bir süreci izlemek için top -p 1532.

Load Average bir yüzde değil, bir kuyruktur

load average üç sayısı, sırasıyla son 1, 5 ve 15 dakikadaki ortalama kuyruk uzunluğudur. Linux'ta kuyruğa R ve D durumundaki süreçler girer; normal uyku S girmez. LA değerini çekirdek sayısıyla (nproc) karşılaştırın: 4 çekirdekte 4 değeri tam yük demektir, 12 ise kapasitenin üç katı kuyruk demektir.

LA yüksekse ama işlemci boşta duruyorsa, D durumundaki süreçlere bakın: ps -eo stat,pid,cmd | grep '^D'. Neredeyse her zaman yavaş bir disk veya ağ depolaması söz konusudur.

htop: top'a kullanışlı bir alternatif

htop aynı bilgileri çekirdek başına renkli göstergeler, kaydırma, fare desteği ve süreç ağacıyla gösterir. Genellikle kurmanız gerekir: sudo apt install htop veya sudo dnf install htop.

  • F3 veya / — ada göre süreç arama;
  • F4 — yalnızca eşleşenleri bırakan filtre;
  • F5 veya t — “ebeveyn — çocuklar” ağacı;
  • F6 — sıralama sütununu seçme;
  • F7 / F8 — nice değerini azaltma / artırma;
  • F9 — seçili süreç için sinyal menüsü;
  • Space — toplu işlem için birden fazla süreç işaretleme.

Bir şey kuramadığınız sunucularda top yeterlidir: bu işlemlerin hepsi onda da vardır.

Süreci sonlandırma: kill ve sinyaller

kill komutu “öldürmez”, sürece bir sinyal gönderir. Sonra ne olacağı sinyale ve programın onu nasıl işlediğine bağlıdır.

SinyalNumaraAmaç
SIGHUP1terminal bağlantısının kopması; birçok daemon yapılandırmayı yeniden okur
SIGINT2kesme, Ctrl+C ile aynı
SIGKILL9çekirdek tarafından zorla sonlandırma, yakalanamaz
SIGTERM15düzgünce sonlanma isteği; kill'in varsayılanı
SIGSTOP19duraklatma, yakalanamaz
SIGCONT18duraklatılmış süreci sürdürme
SIGTSTP20terminalden duraklatma, Ctrl+Z

Numaralar x86 ve ARM için geçerlidir; tam liste kill -l ile görünür. Sinyali numarayla değil adıyla yazmak daha güvenlidir.

kill 1532              # SIGTERM
kill -TERM 1532        # aynısı, açıkça
kill -HUP $(pidof nginx)   # yapılandırmayı yeniden oku
kill -STOP 1532; kill -CONT 1532
kill -0 1532 && echo "süreç canlı"

0 sinyali hiçbir şey göndermez; yalnızca sürecin var olup olmadığını ve ona yazma hakkınız olup olmadığını kontrol eder — betiklerde kullanışlıdır.

Neden kill -9 ile başlanmamalı

SIGTERM programa dosyaları kapatma, tamponları boşaltma, kilit dosyalarını silme ve işlemleri düzgünce bitirme şansı verir. SIGKILL ise her şeyi anında keser: yazılmamış veriler kaybolur, geçici dosyalar kalır ve veritabanı bir sonraki açılışta kurtarma moduna girebilir.

Doğru sıra şöyledir:

  1. kill PID (SIGTERM) gönderin.
  2. 5–30 saniye bekleyip kill -0 PID ile kontrol edin.
  3. Yalnızca süreç hâlâ canlıysa ve D durumunda değilse — kill -9 PID.

systemd altındaki servisler için PID'i elle hiç kullanmayın: systemctl stop SIGTERM gönderir, zaman aşımını bekler ve gerekirse SIGKILL ile bitirir.

pkill ve killall: ada göre

pkill -f "python worker.py"   # tam komut satırına göre
pkill -u alice                 # kullanıcının tüm süreçleri
killall -TERM node             # adı node olan tüm süreçler
pgrep -l -f worker             # önce desenin neleri yakalayacağını kontrol edin

Toplu pkill öncesinde her zaman aynı desenle pgrep çalıştırın: -f komut satırının herhangi bir parçasıyla eşleşir ve istenmeyen süreçleri de yakalayabilir.

Sinyalleri yalnızca kendi süreçlerinize gönderebilirsiniz; başkalarınınkiler için sudo gerekir. Operation not permitted hatası tam olarak bunu belirtir.

Süreç önceliği: nice ve renice

nice değeri, zamanlayıcıya hangi sürecin işlemciyi kimin önüne bırakacağını söyler. Aralık -20 (en yüksek öncelik) ile 19 (herkese yol verir) arasındadır; varsayılan 0'dır. top'ta bu değer NI sütununda görünür; PR ise türetilmiş dahili önceliktir.

# ağır bir işi düşük öncelikle başlat
nice -n 10 tar czf backup.tar.gz /var/www

# çalışan bir sürecin önceliğini düşür
renice -n 15 -p 1532

# önceliği artır (yalnızca root)
sudo renice -n -5 -p 1610

# bir kullanıcının tüm süreçleri
sudo renice -n 10 -u alice

Normal kullanıcı yalnızca kendi süreçlerinin önceliğini düşürebilir; negatif değerler yalnızca root'a açıktır. nice'ın sınırını da bilmek gerekir: yalnızca CPU'yu etkiler. Sistemi diskle yavaşlatan bir iş varsa ionice -c3 komut kullanın — idle sınıfı diskten yalnızca kimse ihtiyaç duymadığında yararlanır.

Arka plan süreçleri ve kabuk görevleri

Komutu sonuna & ekleyerek arka planda çalıştırabilir veya Ctrl+Z ile duraklatabilirsiniz. Kabuk, görevlerin listesini tutar ve bunları yerleşik komutlarla yönetirsiniz.

$ long_task &
[1] 5120
$ jobs
[1]+  Running    long_task &
$ fg %1        # ön plana getir
^Z             # duraklat (SIGTSTP)
$ bg %1        # arka planda sürdür

Terminali kapattığınızda kabuk görevlere SIGHUP gönderir ve onlar sonlanır. Süreç çıkıştan sonra da yaşasın istiyorsanız nohup komut & ile başlatın, disown ile kabuktan ayırın veya tmux kullanın. Kalıcı çalışma için en doğrusu onu bir systemd servisi olarak tanımlamaktır.

Tipik tanı senaryoları

İşlemciyi kim yiyor

top -o %CPU            # ya da top içinde P
ps -eo pid,user,%cpu,etime,cmd --sort=-%cpu | head

Bir süreç CPU'yu boşa harcıyorsa, önce renice ile önceliğini düşürün — bu güvenlidir ve sorunu incelemeniz için zaman kazandırır.

Portu kim almış

sudo ss -ltnp | grep :8080
sudo lsof -i :8080

Çıktıda PID görünür; ardından /proc/PID/ içinde çalıştırılabilir dosyayı (exe), çalışma dizinini (cwd) ve argümanları (cmdline) bulabilirsiniz.

Süreç beklenmedik şekilde kayboldu

Yaygın neden, bellek yetersiz kaldığında süreçleri öldüren OOM Killer'dır. Kontrol: dmesg -T | grep -i oom veya journalctl -k | grep -i "killed process".

Özet

Linux süreçleriyle çalışmak için küçük bir komut seti yeterlidir: anlık görüntü için ps aux, izleme için top ve htop, sonlandırma için doğru sinyalli kill, öncelikler için nice/renice. Harekete geçmeden önce sürecin durumunu okuyun: zombi ve D durumundaki süreçler sinyallerle çözülmez. Her zaman SIGTERM ile başlayın ve kill -9'u son çare olarak saklayın. Süreçler, bellek, Load Average ve sistem çağrıları kursta uygulamalı olarak ayrıntılı işlenmektedir.

Sık sorulan sorular

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

Bunlar aynı komutun iki sözdizimidir: aux BSD tarzıdır ve %CPU, %MEM, STAT sütunlarını verir; -ef System V tarzıdır ve PPID sütununu verir. Her iki durumda da gösterilen süreçler aynıdır: sistemdeki tüm süreçler.

Sistemde kaç süreç çalışıyor?

En kolayı top'taki Tasks satırına bakmak veya ps -e --no-headers | wc -l çalıştırmaktır. İş parçacığı sayısını ps -eLf --no-headers | wc -l gösterir.

kill -9 uygulanmasına rağmen süreç neden sonlanmıyor?

Ya D durumundadır ve çekirdekte G/Ç beklediği için bekliyordur ya da zaten sonlanmış bir zombidir. İlkinde disk veya ağ depolama sorununu, ikincisinde ebeveyni düzeltmeniz veya yeniden başlatmanız gerekir.

PID 1'i sonlandırırsam ne olur?

Çekirdek init'i korur: kullanıcının gönderdiği SIGKILL dahil sıradan sinyaller, init bunları işlemiyorsa ona iletilmez. init yine de sonlanırsa sistem kernel panic'e düşer.

Bir sürecin bellek kullanımını nasıl sınırlarım?

systemd servisi için birim dosyasına MemoryMax= yazın; tek seferlik çalıştırma için systemd-run --scope -p MemoryMax=500M komut kullanın. Bu cgroups üzerinden çalışır ve eski ulimit -v'den daha güvenilirdir.

Bu konuyu videoyla öğrenin

Bu konu “Linux: с нуля до уверенного администрирования” kursunda uygulamalı olarak ayrıntılı işleniyor.

Kursa git