schedtool Komutu: Süreç Zamanlama Politikaları

Üretim ortamında bir uygulama yavaşlamaya başladığında, ilk içgüdüsel tepki genellikle CPU kullanımına bakmak olur. top açılır, htop çalıştırılır, belki vmstat ile biraz daha derine inilir. Ama çoğu zaman gözden kaçan bir şey vardır: süreçlerin çekirdek tarafından nasıl zamanlandığı. Hangi sürecin ne zaman CPU alacağı, ne kadar öncelikli olduğu, gerçek zamanlı bir politikayla mı yoksa sıradan bir politikayla mı çalıştığı… İşte tam bu noktada schedtool devreye giriyor.

schedtool, Linux çekirdeğinin zamanlama (scheduling) altyapısıyla doğrudan konuşmanızı sağlayan küçük ama son derece etkili bir araç. Özellikle ses/video işleme, düşük gecikmeli ağ uygulamaları, veritabanı süreçleri ve yoğun hesaplama gerektiren iş yüklerinde zamanlama politikasını doğru ayarlamak, fark yaratan detaylardan biri.

Linux Zamanlama Politikalarını Anlamak

schedtool komutunun nasıl kullanıldığına girmeden önce, Linux’un sunduğu zamanlama politikalarına kısaca bakmak gerekiyor. Bunları anlamadan komutu kullanmak, körü körüne tuş basmaktan farksız.

Linux çekirdeği birkaç farklı zamanlama politikası sunar:

SCHED_OTHER (0): Varsayılan politika. CFS (Completely Fair Scheduler) tarafından yönetilir. Çoğu masaüstü ve sunucu süreci bu politikayla çalışır.
SCHED_FIFO (1): Gerçek zamanlı, First In First Out. Yüksek öncelikli, preemptif olmayan (aynı öncelikte) zamanlama. Ses sürücüleri, RT uygulamaları için.
SCHED_RR (2): Gerçek zamanlı, Round Robin. FIFO’ya benzer ama zaman dilimli çalışır.
SCHED_BATCH (3): CPU yoğun, etkileşimsiz işler için. Sürecin latency’sine toleranslıdır, throughput odaklıdır.
SCHED_IDLE (5): Sistem tamamen boşta olduğunda çalışması istenen düşük öncelikli görevler için. nice -19‘dan bile daha düşük öncelik.

Bunlara ek olarak ISO ve RR politikalarının bazı varyantları da schedtool aracılığıyla erişilebilir. Hangi politikanın ne işe yaradığını kavramak, doğru aracı doğru işe uygulamanın temelini oluşturuyor.

Kurulum

Çoğu dağıtımda schedtool varsayılan olarak yüklü gelmez. Kurulumu oldukça basit:

# Debian/Ubuntu tabanlı sistemlerde
sudo apt-get install schedtool

# RHEL/CentOS/Fedora tabanlı sistemlerde
sudo dnf install schedtool

# Arch Linux
sudo pacman -S schedtool

Kurulum sonrası versiyon kontrolü yapıp aracın sağlıklı çalıştığını doğrulayabilirsiniz:

schedtool --version

Mevcut Bir Sürecin Zamanlama Politikasını Görüntüleme

En temel kullanım, çalışan bir sürecin mevcut zamanlama politikasını sorgulamak. Bunun için sadece PID vermek yeterli:

schedtool <PID>

Örnek bir çıktı şöyle görünür:

schedtool 1234

PID 1234: PRIO   0, POLICY  0: SCHED_NORMAL  , niceness  0

Burada birkaç önemli bilgi var:

PRIO: Gerçek zamanlı öncelik değeri (RT politikalar için 1-99 arası)
POLICY: Politika numarası
niceness: SCHED_OTHER için nice değeri

Şimdi diyelim ki bir PostgreSQL sürecinin nasıl zamanlandığını görmek istiyorsunuz:

# Önce PostgreSQL'in PID'ini bulalım
pgrep -u postgres -d 'n'

# Ardından schedtool ile sorgulayalım
schedtool $(pgrep -u postgres | head -1)

Birden fazla sürecin politikasını aynı anda sorgulamak da mümkün:

schedtool 1234 5678 9012

Bu size üç sürecin de politika bilgisini sırayla döker. Bir servisin tüm worker thread’lerini toplu kontrol ederken oldukça işe yarıyor.

Zamanlama Politikasını Değiştirmek

İşte asıl güç burada başlıyor. schedtool ile çalışan bir sürecin politikasını anında değiştirebilirsiniz. Temel sözdizimi şu şekilde:

schedtool -<politika_bayrağı> [-p öncelik] <PID>

SCHED_BATCH ile CPU Yoğun İşleri Arka Plana Almak

Diyelim ki bir yedekleme scripti çalışıyor ve sistemi yavaşlatıyor. Bu süreci SCHED_BATCH politikasına almak, diğer interaktif süreçlerin bundan etkilenmemesini sağlar:

# Yedekleme scriptinin PID'i 4521 olsun
sudo schedtool -B 4521

-B bayrağı SCHED_BATCH anlamına gelir. Bu değişiklikten sonra süreç, sistem meşgul olduğunda CPU almak için sıraya girer ve interaktif süreçlerin önüne geçmez. Yedekleme süreci biraz daha yavaş tamamlanabilir ama sunucunun genel yanıt süresi korunmuş olur.

SCHED_IDLE ile Gerçekten Düşük Öncelikli Görevler

Log analizi, arşiv sıkıştırma gibi “vakit bulunca yapılsın” türünden işler için:

sudo schedtool -D 4521

-D bayrağı SCHED_IDLE politikasını etkinleştirir. Bu süreç, sistemde başka yapacak iş kalmadığında CPU alır. Kelime kelime “boş zamanında çalış” demek bu.

SCHED_FIFO ile Gerçek Zamanlı Öncelik

Ses işleme uygulamaları, düşük gecikmeli ağ paket işleyicileri gibi süreçler için gerçek zamanlı politika kullanmak gerekebilir:

# Öncelik değeri 50 olan SCHED_FIFO politikası
sudo schedtool -F -p 50 7823

Dikkat: RT politikaları dikkatsiz kullanıldığında sistemi kitleyebilir. Gerçek zamanlı politikayla çalışan bir süreç, sonsuz döngüye girerse CPU’yu bırakmaz ve sistem yanıt vermez hale gelir. Bu yüzden /etc/security/limits.conf üzerinden RT öncelik sınırlarını doğru yapılandırmak önemli.

SCHED_RR ile Round Robin Gerçek Zamanlı

FIFO’dan farkı, aynı öncelikteki RT süreçler arasında zaman paylaşımı yapılmasıdır:

sudo schedtool -R -p 30 7823

SCHED_NORMAL’e Geri Dönmek

Bir süreci eski haline, yani varsayılan politikaya geri almak için:

sudo schedtool -N 4521

Yeni Bir Süreci Belirli Politikayla Başlatmak

schedtool‘un en pratik özelliklerinden biri de bir komutu doğrudan istediğiniz zamanlama politikasıyla başlatabilmeniz. Bu, sistemd service unit dosyalarını düzenlemeden ya da uygulama koduna dokunmadan politika atamanın en temiz yolu:

schedtool -B -e <komut> [argümanlar]

-e bayrağı “execute” anlamına gelir. Örnekler:

# Bir tar arşivini SCHED_BATCH politikasıyla çalıştır
sudo schedtool -B -e tar czf /backup/home.tar.gz /home/

# CPU yoğun bir Python scripti SCHED_IDLE ile başlat
sudo schedtool -D -e python3 /opt/scripts/heavy_analysis.py

# Gerçek zamanlı öncelikle bir ağ uygulaması başlat
sudo schedtool -F -p 40 -e /usr/local/bin/low_latency_app

Bu yaklaşım, cron job’larında veya systemd timer servislerinde zamanlama politikasını merkezi olarak yönetmek için ideal.

Gerçek Dünya Senaryoları

Senaryo 1: Gece Yedekleme Penceresi Optimizasyonu

Bir müşteri ortamında gece 02:00’de başlayan yedekleme süreci, sabah 07:00’de sistemi kullanan kullanıcıların şikayetlerine yol açıyordu. Yedekleme tam bitmemişti ve sistemi yoğun şekilde kullanıyordu. Çözüm basitti:

#!/bin/bash
# /opt/scripts/backup_wrapper.sh

BACKUP_LOG="/var/log/backup/$(date +%Y%m%d).log"

# Yedekleme sürecini SCHED_BATCH politikasıyla başlat
# Nice değerini de düşür, çift güvence
schedtool -B -e nice -n 15 /opt/backup/run_backup.sh >> "$BACKUP_LOG" 2>&1

echo "Yedekleme tamamlandi: $(date)" >> "$BACKUP_LOG"

Bu script ile yedekleme süreci artık sistem meşgul olduğunda sessiz kalıyor, boşluk bulduğunda ilerliyordu. Kullanıcı şikayetleri sıfıra indi.

Senaryo 2: Video Encoding Farm’da Latency Yönetimi

Bir encoding cluster’ında hem canlı stream işleyen hem de arşiv video encode eden süreçler çalışıyordu. Canlı stream süreçleri kritikti, arşiv işleri bekleyebilirdi:

# Canlı stream işleyiciler için - sistemi izleyen bir script
#!/bin/bash

LIVE_STREAM_PROCS=$(pgrep -f "live_encoder")
ARCHIVE_PROCS=$(pgrep -f "archive_encoder")

# Canlı stream süreçlerine yüksek RT önceliği
for pid in $LIVE_STREAM_PROCS; do
    sudo schedtool -R -p 60 "$pid"
    echo "Live encoder PID $pid -> SCHED_RR p60"
done

# Arşiv encode süreçlerini arka plana al
for pid in $ARCHIVE_PROCS; do
    sudo schedtool -B "$pid"
    echo "Archive encoder PID $pid -> SCHED_BATCH"
done

Bu düzenlemenin ardından canlı stream kesintileri ciddi ölçüde azaldı.

Senaryo 3: Java Uygulama Sunucusunda GC Pause Optimizasyonu

Bir JVM uygulamasında Garbage Collection pause’ları sorun yaratıyordu. GC thread’leri tam iş yükünde diğer worker thread’lerin önüne geçiyordu. JVM’in GC thread’lerini tespit edip politikasını değiştirmek için:

#!/bin/bash
# JVM GC thread'lerini SCHED_BATCH'e al

APP_PID=$(pgrep -f "myapp.jar")

if [ -z "$APP_PID" ]; then
    echo "Uygulama sureci bulunamadi"
    exit 1
fi

# JVM'in tüm thread'lerini listele
# GC thread'leri genellikle "GC Task" veya "G1" ismiyle görünür
cat /proc/$APP_PID/task/*/status | grep -E "^(Name|Pid):" | 
    paste - - | grep -i "gc|g1|shenandoah" | 
    awk '{print $4}' | while read tid; do
        schedtool -B "$tid"
        echo "GC thread $tid SCHED_BATCH yapildi"
    done

Senaryo 4: İzleme ve Raporlama

Bir sistemin tüm önemli servislerinin zamanlama politikalarını periyodik olarak izlemek ve raporlamak için:

#!/bin/bash
# /opt/monitoring/check_scheduling.sh

SERVICES=("nginx" "postgresql" "redis-server" "java")
REPORT_FILE="/var/log/scheduling_report_$(date +%Y%m%d_%H%M).txt"

echo "=== Zamanlama Politikasi Raporu ===" > "$REPORT_FILE"
echo "Tarih: $(date)" >> "$REPORT_FILE"
echo "" >> "$REPORT_FILE"

for service in "${SERVICES[@]}"; do
    echo "--- $service ---" >> "$REPORT_FILE"
    pids=$(pgrep -f "$service")
    
    if [ -z "$pids" ]; then
        echo "$service: Surec bulunamadi" >> "$REPORT_FILE"
        continue
    fi
    
    for pid in $pids; do
        schedtool "$pid" 2>/dev/null >> "$REPORT_FILE"
    done
    echo "" >> "$REPORT_FILE"
done

cat "$REPORT_FILE"

Dikkat Edilmesi Gereken Noktalar

Gerçek zamanlı politikalarda root yetkisi gerekir. SCHED_FIFO ve SCHED_RR politikalarını ayarlamak için root veya CAP_SYS_NICE yetkisi gerekir. Normal kullanıcılar SCHED_BATCH ve SCHED_IDLE politikalarını kendi süreçlerine uygulayabilir.

RT öncelikleri sistem stabilitesini etkileyebilir. Öncelik 99 ile çalışan bir süreç, çekirdek thread’lerinin bile önüne geçebilir. Bu değerlere gerçekten ihtiyaç duymadıkça 50’nin üzerine çıkmamak iyi bir pratik.

Öncelik değerleri SCHED_OTHER için geçerli değildir. Nice değerleri ile RT öncelik değerleri farklı şeyler. RT politikalarda -p ile verilen değer 1-99 arası olup yüksek değer daha yüksek öncelik anlamına gelirken, nice değerinde -20 en yüksek önceliktir.

Değişiklikler kalıcı değildir. schedtool ile yapılan değişiklikler sistem yeniden başlatıldığında ya da süreç yeniden başlatıldığında kaybolur. Kalıcı yapılandırma için systemd unit dosyasında CPUSchedulingPolicy= ve CPUSchedulingPriority= direktiflerini kullanmak daha sağlıklıdır.

taskset ile kombinasyon. schedtool zamanlama politikasını yönetirken, CPU affinity (hangi çekirdekte çalışacağı) için taskset veya schedtool’un kendi -a parametresi kullanılabilir:

# Hem SCHED_BATCH politikası hem de CPU 0-3'e sabitle
sudo schedtool -B -a 0x0f 4521

Buradaki 0x0f hexadecimal maske olup 0-3 numaralı CPU çekirdeklerini temsil eder.

systemd ile Entegrasyon

Servis bazlı ortamlarda schedtool komutunu doğrudan kullanmak yerine systemd’nin native desteğini de göz önünde bulundurun. Örneğin bir servis için:

[Service]
ExecStart=/usr/local/bin/myapp
CPUSchedulingPolicy=batch
Nice=10

Ya da RT politika için:

[Service]
ExecStart=/usr/local/bin/rt_app
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=50

schedtool ise bu systemd yapılandırmalarını hızlıca test etmek, çalışan süreçleri anında ayarlamak veya systemd kapsamı dışındaki süreçleri yönetmek için ideal. İkisi birbirinin rakibi değil, tamamlayıcısı.

Alternatif Araçlarla Karşılaştırma

chrt komutu schedtool‘a alternatif olarak sıkça kullanılır. Aslında chrt, util-linux paketinin parçası olduğu için çoğu sistemde zaten yüklüdür. Temel işlevsellik açısından benzerler, ancak schedtool‘un CPU affinity gibi ek özellikleri ve daha okunabilir çıktısı onu tercih edilebilir kılıyor. renice ise sadece nice değerini değiştirir, zamanlama politikasına dokunmaz; bu yüzden çok daha sınırlı bir araçtır.

Sonuç

schedtool, sistem yöneticisinin toolbox’ında yer alması gereken, az bilinen ama etkili araçlardan biri. Özellikle karma iş yükü çalıştıran sunucularda, yani hem interaktif işlemlerin hem de toplu işlerin aynı anda koştuğu ortamlarda, zamanlama politikalarını doğru yapılandırmak ciddi performans farkları yaratıyor.

Yedekleme işlerini SCHED_BATCH‘e almak, arşiv encode görevlerini SCHED_IDLE‘a çekmek, kritik düşük gecikmeli süreçlere RT önceliği vermek; bunların hepsi CPU frekansı artırmadan, donanım eklemeden yapılabilen optimizasyonlar. Çekirdek zaten bu mekanizmaları sunuyor, bizim görevimiz onları doğru kullanmak.

Üretim ortamında bu değişiklikleri uygulamadan önce test ortamında denemek, RT politikalar için mutlaka ulimit ayarlarını ve limits.conf konfigürasyonunu gözden geçirmek gerekiyor. Ama temkinli bir şekilde yaklaşıldığında, schedtool ile yapılacak birkaç satır değişiklik, uzun saatler süren profiling ve optimizasyon çalışmalarına alternatif olabilir.

schedtool Komutu ile Süreç Zamanlama Politikalarını Görüntüleme ve Değiştirme