Linux Performans Ayarları: CPU, RAM ve I/O Derinlemesine Analizi

 · 

Linux Performans Ayarları: CPU, RAM ve I/O Derinlemesine Analizi

Linux Performans Ayarları: CPU, RAM ve I/O Derinlemesine Analizi

Üretim ortamlarındaki Linux sunucularda performans sorunları, kullanıcı deneyiminden iş sürekliliğine kadar geniş bir yelpazede olumsuz etkilere yol açabilir. Bu sorunların kök nedenini belirlemek için CPU, bellek (RAM) ve disk G/Ç (I/O) kaynaklarının sistematik bir şekilde analiz edilmesi kritik öneme sahiptir. Bu analiz, sadece anlık durum tespiti yapmakla kalmaz, aynı zamanda uzun vadeli optimizasyon stratejileri geliştirmek için de temel oluşturur.

CPU Performans Analizi

CPU kullanımı, bir sistemin işlem yükünü doğrudan gösterir. Aşırı CPU kullanımı, uygulamanın yetersiz kaynak tahsisinden, kötü optimize edilmiş koddan veya beklenenden fazla işlem talebinden kaynaklanabilir.

Kullanılan Araçlar ve Metrikler

CPU performansını izlemek için çeşitli araçlar mevcuttur:

  • top veya htop: Anlık süreç bazında CPU kullanımını gösterir.
  • vmstat: Sistem genelinde CPU, bellek, G/Ç ve takas alanı istatistiklerini raporlar.
  • sar: Sistem aktivitesi verilerini toplar ve raporlar (CPU, bellek, G/Ç vb.).

top çıktısında dikkat edilmesi gereken ana metrikler şunlardır:

top - 14:30:01 up 1 day, 2:30, 2 users, load average: 1.50, 1.25, 1.10Tasks: 200 total, 2 running, 198 sleeping, 0 stopped, 0 zombie%Cpu(s): 25.3 us, 10.7 sy, 0.0 ni, 60.0 id, 3.5 wa, 0.0 hi, 0.5 si, 0.0 stMiB Mem : 7987.5 total, 2000.0 free, 3500.0 used, 2487.5 buff/cacheMiB Swap: 2048.0 total, 1900.0 free, 148.0 used. 4000.0 avail Mem    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND   1234 appuser   20   0 1000m  200m   50m S  15.0   2.5   1:15.23 myapp-process   5678 root      20   0  500m   50m   20m R  10.0   0.6   0:30.45 another-proc

%Cpu(s) satırında:

  • us (user): Kullanıcı alanı işlemlerinin CPU kullanımı. Yüksek olması, uygulamanın yoğun işlem yaptığını gösterir.
  • sy (system): Çekirdek (kernel) işlemlerinin CPU kullanımı. Yüksek olması, sistem çağrılarının veya donanım etkileşimlerinin yoğun olduğunu işaret edebilir.
  • id (idle): Boşta kalan CPU yüzdesi. Düşük olması CPU'nun doymuş olduğunu gösterir.
  • wa (iowait): G/Ç bekleyen işlemlerin harcadığı CPU yüzdesi. Yüksek olması, disk veya ağ G/Ç'sının bir darboğaz olduğunu düşündürür.
  • st (steal): Sanallaştırılmış ortamlarda, hypervisor'ın CPU kaynaklarını başka bir sanal makineye ayırması nedeniyle kaybedilen CPU yüzdesi.

Üretim Senaryosu: Yüksek CPU Yükü ve Çözüm

Bir e-ticaret uygulamasının web sunucusunda (Nginx + PHP-FPM) yük altında anormal derecede yüksek CPU kullanımı gözlemleniyor. top çıktısında PHP-FPM süreçlerinin %us değerlerinin sürekli %80'in üzerinde olduğu görülüyor. Ayrıca load average değerleri sunucunun çekirdek sayısının çok üzerinde seyrediyor.

# top -bn1 | grep "Cpu(s)"%Cpu(s): 85.3 us,  5.7 sy,  0.0 ni,  5.0 id,  3.0 wa,  0.0 hi,  1.0 si,  0.0 st

Bu durumda, PHP-FPM'in aşırı kaynak tükettiği açıktır. İlk adım, hangi PHP betiklerinin bu yükü oluşturduğunu tespit etmektir. Uygulama logları ve APM (Application Performance Monitoring) araçları (örneğin New Relic, Datadog) bu konuda yardımcı olabilir. Genellikle bu durum, optimize edilmemiş veritabanı sorgularından, karmaşık döngülerden veya harici API çağrılarının bloklamasından kaynaklanır. Çözüm olarak:

  • Veritabanı sorgularının indekslenmesi ve optimize edilmesi.
  • PHP kodunda profil çıkarma (Xdebug gibi araçlarla) ve darboğazları giderme.
  • Gereksiz döngülerin veya pahalı işlemlerin önbelleğe alınması (Redis, Memcached).
  • PHP-FPM worker sayılarının ve bellek limitlerinin gözden geçirilmesi.
  • Yük dengeleme ile daha fazla sunucu eklenerek yükün dağıtılması.

RAM Performans Analizi

RAM, çalışan uygulamaların ve işletim sisteminin hızlı erişim için kullandığı geçici depolama alanıdır. Yetersiz RAM veya yanlış yapılandırma, sistemin takas alanını (swap) kullanmaya başlamasına ve ciddi performans düşüşlerine neden olabilir.

Kullanılan Araçlar ve Metrikler

Bellek kullanımını izlemek için:

  • free -h: Toplam, kullanılan, boş ve önbelleğe alınan bellek miktarını gösterir.
  • vmstat: Bellek ve takas alanını periyodik olarak raporlar.
  • sar -r: Bellek kullanım istatistiklerini kaydeder ve raporlar.
  • smem: Süreç bazında gerçek bellek tüketimini (PSS, RSS) daha detaylı gösterir.

free -h çıktısı:

              total        used        free      shared  buff/cache   availableMem:          7.8Gi       4.2Gi       1.5Gi       100Mi       2.1Gi       3.2GiSwap:         2.0Gi       500Mi       1.5Gi
  • total: Toplam fiziksel bellek.
  • used: Uygulamalar ve çekirdek tarafından kullanılan bellek.
  • free: Hiç kullanılmayan boş bellek.
  • buff/cache: İşletim sistemi tarafından disk G/Ç işlemlerini hızlandırmak için kullanılan bellek. Bu, aslında "kullanılabilir" belleğin bir parçasıdır.
  • available: Yeni uygulamalar tarafından anında kullanılabilecek bellek. free + buff/cache'in büyük bir kısmıdır.
  • Swap: Disk üzerinde takas alanı kullanımı.

Üretim Senaryosu: Yüksek Swap Kullanımı ve Çözüm

Bir veritabanı sunucusu (PostgreSQL) zaman zaman yavaşlama yaşıyor ve sorgu süreleri beklenenin üzerine çıkıyor. free -h çıktısında Swap: 2.0Gi 1.5Gi 500Mi gibi değerler gözlemleniyor; bu, takas alanının önemli ölçüde kullanıldığını gösteriyor.

# vmstat 1 5procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 0  0 1536000 512000  65536 2048000   10   500   200  1000  800 1200 20 10 60 10  0

vmstat çıktısında si (swap-in) ve so (swap-out) değerlerinin yüksek olması, sistemin aktif olarak disk ile bellek arasında veri taşıdığını ve bu durumun disk G/Ç'sını artırarak performansı düşürdüğünü gösterir. Bu, veritabanı sisteminin belleğe sığmayan çok fazla veriyle çalıştığını veya uygulamanın çok fazla bellek tükettiğini işaret eder.

Çözüm yaklaşımları:

  • sysctl -w vm.swappiness=10 gibi çekirdek parametrelerini ayarlayarak takas kullanımını azaltmak (varsayılan 60'tır). Daha düşük bir değer, çekirdeğin diske yazmadan önce RAM'i daha fazla kullanmasını teşvik eder.
  • Veritabanı yapılandırmasını optimize etmek (örneğin, shared_buffers, work_mem gibi PostgreSQL parametreleri).
  • Uygulamanın bellek sızıntılarını tespit etmek ve gidermek.
  • Sunucuya daha fazla fiziksel RAM eklemek.
  • Veritabanının diskteki veri miktarını azaltmak (arşivleme, temizleme).

I/O Performans Analizi

Disk G/Ç performansı, veritabanları, log sunucuları, dosya sunucuları ve büyük veri işleme gibi G/Ç yoğun uygulamalar için kritik bir darboğaz olabilir. Yavaş diskler veya aşırı G/Ç yükü, uygulamanın genel yanıt süresini önemli ölçüde etkileyebilir.

Kullanılan Araçlar ve Metrikler

Disk G/Ç'sını izlemek için:

  • iostat -x 1: Disk bazında detaylı G/Ç istatistikleri sunar.
  • iotop: Süreç bazında anlık disk G/Ç kullanımını gösterir.
  • vmstat: Blok G/Ç istatistiklerini genel olarak raporlar.
  • sar -d: Disk G/Ç istatistiklerini kaydeder ve raporlar.

iostat -x 1 çıktısında önemli metrikler:

Device            r/s     w/s     rkB/s     wkB/s   avgqu-sz   await  %utilsda              0.00   85.00      0.00  1530.00       2.50    29.40  95.00
  • r/s, w/s: Saniyedeki okuma/yazma işlemleri.
  • rkB/s, wkB/s: Saniyede okunan/yazılan kilobayt miktarı.
  • avgqu-sz: G/Ç kuyruğunda bekleyen ortalama istek sayısı. Yüksek değerler darboğazı gösterir.
  • await: G/Ç isteklerinin ortalama servis süresi (ms cinsinden). Bu süre, kuyrukta bekleme süresini de içerir.
  • %util: Diskin meşgul olduğu yüzdesi. %100'e yakın değerler diskin doyduğunu gösterir.

Üretim Senaryosu: Disk Doygunluğu ve Çözüm

Bir log toplama sunucusu (örneğin Elasticsearch veya Splunk indeksleyicisi) yüksek hacimli logları işlerken yavaşlamalar yaşıyor. iostat -x 1 çıktısında belirli bir diskin (örneğin sda) %util değerinin sürekli %90'ın üzerinde olduğu ve await süresinin 50ms'yi aştığı görülüyor.

# iostat -x 1...Device            r/s     w/s     rkB/s     wkB/s   avgqu-sz   await  %utilsda             10.00  1500.00     200.00  25000.00      50.00    65.00 100.00

Bu durum, diskin yazma kapasitesinin log akışına yetişemediğini açıkça gösteriyor. iotop kullanarak hangi süreçlerin bu G/Ç yükünü oluşturduğunu tespit edebiliriz.

# iotop -oPa  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMAND12345 be/4 elastic  0.00 B/s   25.00 M/s  0.00 % 99.99 % elasticsearch

Görüldüğü üzere Elasticsearch süreci yoğun yazma işlemi yapıyor. Çözüm yaklaşımları:

  • Daha hızlı depolama birimlerine geçiş (HDD yerine SSD, NVMe).
  • RAID yapılandırmasını optimize etmek (RAID10 gibi yüksek performanslı seviyeler).
  • Veri yazma desenini optimize etmek (örneğin, daha büyük bloklar halinde yazma, önbellekleme).
  • Uygulama katmanında G/Ç azaltma (örneğin, Elasticsearch'te indeks optimizasyonu, sharding).
  • Yükü birden fazla diske veya sunucuya dağıtmak.
  • Log toplama hızını geçici olarak kısmak veya önbellekleme katmanı eklemek.

Sonuç

Linux sistemlerde performans sorunlarının tespiti ve çözümü, CPU, RAM ve I/O kaynaklarının bütünsel ve metodik bir şekilde analiz edilmesini gerektirir. Her bir bileşenin kendi içinde metrikleri ve araçları olsa da, gerçek bir darboğaz genellikle bu bileşenler arasındaki etkileşimden doğar. Yukarıda bahsedilen araçları ve senaryoları kullanarak, üretim ortamınızdaki potansiyel performans sorunlarını proaktif bir şekilde tespit edebilir ve etkili çözümler üretebilirsiniz. Doğru izleme ve düzenli analiz, sistemlerinizin kararlılığını ve verimliliğini sürdürmek için vazgeçilmezdir.

← Blog Listesine Dön