Bu kapsamlı rehberde; Keyhel Panel’de Jailed SSH ortamında güvenlikten ödün vermeden, gerekli izinleri ayarlamayı, NVM (Node Version Manager) kullanarak Node.js kurmayı ve uygulamalarınızı PM2 ile 7/24 kesintisiz nasıl çalıştıracağınızı adım adım anlatıyoruz.

1. Adım: Ön Hazırlık – “Ek İkili Dosyalar” ve Kütüphane İzinleri

Jailed SSH (Hapishane) ortamı, kullanıcıyı sadece belli başlı komutlarla sınırlandırır. NPM’in paketleri indirebilmesi, zipli dosyaları açabilmesi ve özellikle Vite/Rollup gibi modern araçların Linux çekirdek kütüphanelerine ulaşıp derleme (build) yapabilmesi için sunucu panelinizden bazı komutlara izin vermeniz gerekir.

Hosting panelinizden (Örn: KeyHelp’te Yapılandırma > Sınırlandırılmış SSH > Ek İkili Dosyalar bölümüne) aşağıdaki listeyi eksiksiz olarak ekleyin ve kaydedin:

/usr/bin/node
/usr/bin/npm
/usr/local/bin/pm2
/usr/bin/sed
/usr/bin/awk
/usr/bin/tr
/usr/bin/uname
/usr/bin/tar
/usr/bin/gzip
/usr/bin/xz
/usr/bin/sort
/usr/bin/grep
/usr/bin/tail
/usr/bin/head
/usr/bin/cut
/usr/bin/wc
/usr/bin/dirname
/usr/bin/find
/usr/bin/tee
/usr/bin/sha256sum
/usr/bin/rm
/usr/bin/cp
/usr/bin/mv
/lib/x86_64-linux-gnu/librt.so.1
/usr/lib/x86_64-linux-gnu/librt.so.1
/lib64/librt.so.1

Not: Listenin sonundaki librt.so.1 yolları, Vite ve Rollup kullanan projelerde derleme sırasında alınan Error: librt.so.1: cannot open shared object file (ERR_DLOPEN_FAILED) hatasının kesin çözümüdür.

2. Neden Jailed SSH’ta Standart Node.js Kurulumu Çöker?

İzinleri verdikten sonra bile, sistem sizi genellikle /www veya /home/kullaniciadi gibi bir dizine hapseder. Ancak Node.js ve NPM, kurulum ve önbellek (cache) işlemleri için ana sunucu dizinlerine (/.npm) erişmeye çalışır.

Bu durum karşılaştığımız en meşhur hatayı doğurur: Error: EACCES: permission denied, mkdir '/.npm'

Çözüm: Uygulamaları “Root” düzeyinde değil, tamamen kullanıcının kendi izole alanında (Kapsayıcı mantığıyla) kurmaktır.

3. Adım Adım NVM ile Özel Node.js Motoru Kurmak

Her müşteriye veya projeye kendi bağımsız Node.js motorunu atamak için NVM kullanıyoruz. Bu sayede aynı sunucuda bir proje Node 18 ile çalışırken diğeri Node 20 ile çakışmadan çalışabilir.

Terminalinize giriş yapın ve ortamı uyandırmak için şu komutları sırasıyla girin (NVM kurulu değilse standart cURL komutuyla kurabilirsiniz):

# NVM'in yolunu belirleyin
export NVM_DIR="/www/.nvm"

# NVM'i aktif edin
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# İstediğiniz Node sürümünü kurun ve kullanın (Örn: v20)
nvm install 20
nvm use 20

4. NPM EACCES (Yetki) Hatalarını Tamamen Aşmak

NPM’in sunucu kök dizinlerine dosya yazmaya çalışmasını engellemek için ona “Ev” dizininin neresi olduğunu söylemeliyiz. Aşağıdaki komut, NPM’in tüm önbellek dosyalarını kısıtlı alanımız olan /www içerisine yazmasını sağlar:

export HOME="/www"

Sürüm Çakışmalarını (ERESOLVE) Gidermek

Projelerinizde paket sürümleri uyuşmazlığı (npm error ERESOLVE) yaşıyorsanız, NPM’e eski tip bağımlılık çözümlemeyi kullanmasını söyleyerek kurulumu zorlayabilirsiniz:

npm install --legacy-peer-deps

5. Jailed Ortamda PM2 Kurulumu ve “module_conf.json” Hatası Çözümü

Uygulamanızı arka planda sürekli çalıştıracak olan PM2’yi kurmak, yetki sorunlarının en çok yaşandığı yerdir. PM2 logları ve PID dosyalarını ana dizindeki /.pm2 içine yazmaya çalışır. Bunu önlemek için PM2’nin çalışma alanını yeniden yönlendiriyoruz:

# PM2'ye yeni bir ev gösteriyoruz
export PM2_HOME="/www/.pm2"

# PM2'yi global olarak kuruyoruz
npm install -g pm2

Kurulumun başarılı olup olmadığını test etmek için:

pm2 status

Bu komut size boş da olsa o meşhur PM2 tablosunu vermelidir.

6. Uygulamayı Başlatmak ve PM2’yi Kalıcı Hale Getirmek

Tüm altyapımız hazır. Şimdi Node.js veya derlenmiş (build edilmiş) projemizi canlıya alalım.

1. Uygulamanızın klasörüne girin:

cd /www/

2. PM2 ile uygulamayı başlatın: Birden fazla uygulama barındırıyorsanız --name parametresi ile isimleri birbirinden ayırmayı unutmayın.

pm2 start index.js --name "proje-adi" --cwd /www/

3. İşlemi Kaydedin: Sunucu herhangi bir sebeple yeniden başlatıldığında uygulamanızın otomatik olarak tekrar açılması için listeyi kaydedin:

pm2 save

Bonus: SSH Her Açıldığında Ayarları Korumak (.bashrc Otomasyonu)

Jailed SSH ortamları çok “unutkandır”. Terminali kapatıp açtığınızda pm2 status veya npm komutları tekrar hata verebilir. Çünkü girdiğimiz export komutları hafızadan silinir.

Her girişinizde tek bir kelimeyle ortamı hazırlamak için kendinize bir kısayol (alias) oluşturun:

echo 'alias start="export HOME=/www && export PM2_HOME=/www/.pm2 && export NVM_DIR=/www/.nvm && [ -s \"\$NVM_DIR/nvm.sh\" ] && . \"\$NVM_DIR/nvm.sh\" && nvm use 20"' >> /www/.bashrc
source /www/.bashrc

Artık SSH’a her bağlandığınızda sadece start yazıp Enter’a basmanız yeterlidir. Tüm NVM ve PM2 yollarınız saniyeler içinde arka planda hazır hale gelecektir.

Özet

Kısıtlı SSH izinleri, modern web uygulamaları geliştirmek için bir engel değildir. Doğru yapılandırılmış NVM ortamları, çekirdek librt izinleri ve export yönlendirmeleri ile ana sunucuya hiçbir zarar vermeden (Root yetkisi kullanmadan) tamamen izole, güvenli ve yüksek performanslı Node.js barındırma altyapıları kurabilirsiniz. Başarılar dileriz!

Bir web sitesi sahibinin karşılaşabileceği en sinir bozucu durumlardan biri, anlık trafik arttığında veya bir sipariş geldiğinde sitenin aniden çökmesi ve ekranda o meşhur “508 Resource Limit Is Reached” veya “CPU Quota Exceeded” hatasının belirmesidir.

Bu hata, paylaşımlı hosting ortamlarında CloudLinux (LVE Manager) veya benzeri sistemlerin, sitenizin diğer siteleri yavaşlatmasını engellemek için sizin fişinizi çekmesi anlamına gelir. Peki, WordPress neden bu kadar çok CPU tüketir ve bu darboğazı kod seviyesinde nasıl çözersiniz?

Kör uçuşu bırakıp, sorunu bir sistem yöneticisi (SysAdmin) gibi adım adım çözelim.

Adım 1: Darboğazı Teşhis Edin (Kör Uçuşuna Son)

CPU’nuzu neyin sömürdüğünü bilmeden eklenti silmek veya değiştirmek vakit kaybıdır. İlk olarak sorunun kaynağını bulmalısınız:

• Erişim Logları (Access Logs): Sunucu panelinizden (KeyHelp, cPanel vb.) erişim günlüklerini açın. Aynı saniye içinde yüzlerce kez xmlrpc.php veya wp-login.php dosyasına istek geliyorsa, sorun kodlarınızda değil, bir Brute Force (Kaba Kuvvet) saldırısındadır.

• Query Monitor Eklentisi: Sitenize geliştirici olarak giriş yapın ve Query Monitor eklentisini kurun. Hangi eklentinin veritabanına kaç saniye süren sorgular (Slow Queries) gönderdiğini milisaniyesine kadar tespit edin.

Adım 2: Heartbeat API ve admin-ajax.php Krizini Durdurun

WordPress, tarayıcı ile sunucu arasında sürekli bir iletişim kurmak için Heartbeat API’yi kullanır. Özellikle e-ticaret (WooCommerce) sitelerinde sepete ürün ekleme veya varyasyon seçme gibi işlemler admin-ajax.php üzerinden yürütülür. Anlık 50 kişinin sitede gezindiğini ve her saniye sunucuya bir AJAX isteği yolladığını düşünün. Düşük kapasiteli işlemciler bu kuyruğu eritemez ve CPU %100’e vurur.

Çözüm: Heartbeat API’nin frekansını düşürün veya gereksiz yerlerde tamamen kapatın. Temanızın functions.php dosyasına şu kodu ekleyerek Heartbeat’i sadece yazma ekranlarıyla sınırlandırabilirsiniz:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
    global $pagenow;
    if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' ) {
        wp_deregister_script('heartbeat');
    }
}

Adım 3: wp-cron.php‘yi Sunucu Tarafına Taşıyın

WordPress’in zamanlanmış görevleri (yazı yayımlama, yedek alma, e-posta gönderme) wp-cron.php üzerinden çalışır. Ancak WordPress, gerçek bir Cron sistemine sahip değildir; her ziyaretçi siteye girdiğinde bu dosya tetiklenir. Yüksek trafikli bir sitede her tıklamada wp-cron.php‘nin çalışması işlemcinizi felç eder.

Çözüm: WordPress’in sanal cron’unu kapatıp, gerçek sunucu cron’una geçin.

1. wp-config.php dosyanıza şu satırı ekleyerek sanal cron’u kapatın: define('DISABLE_WP_CRON', true);

2. Hosting panelinizin “Zamanlanmış Görevler” (Cron Jobs) bölümüne giderek şu komutu ekleyin (her 15 dakikada bir çalışacak şekilde): wget -q -O - https://siteniz.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Adım 4: Zombi Botları ve xmlrpc.php‘yi Engelleyin

xmlrpc.php, WordPress’in dış uygulamalarla (örneğin mobil uygulama) iletişim kurmasını sağlar. Ancak günümüzde hackerların DDoS saldırıları ve şifre denemeleri için en çok kullandığı arka kapıdır. Sunucunuz bu istekleri yanıtlamaya çalışırken CPU limitini doldurur.

Çözüm: Eğer WordPress mobil uygulamasını veya Jetpack gibi dış servisleri kullanmıyorsanız, .htaccess dosyanıza şu kodu ekleyerek bu dosyaya erişimi kökten kapatın:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Adım 5: Acı Gerçek: Sorun Yazılımda Değil, Donanımınızda Olabilir

Yukarıdaki tüm optimizasyonları yaptınız, eklentilerinizi azalttınız, Redis Object Cache kurup veritabanı sorgularını RAM’e aldınız ama hala CPU sınırına takılıyorsanız… Artık yazılımın sınırlarına geldiniz demektir.

Sektördeki birçok standart hosting firması, sunucularında çok çekirdekli ancak tek çekirdek performansı (IPC) çok zayıf olan eski nesil Intel Xeon işlemciler kullanır. Dahası, tek bir sunucuya yüzlerce site doldurarak size sadece “kağıt üzerinde” kaynak ayırırlar. Ağır bir WooCommerce veya Elementor tabanlı siteniz varsa, bu işlemciler PHP kuyruklarını (Workers) eritemez.

SaviorHost ile “Limitlere” Veda Edin

Biz SaviorHost olarak, CPU darboğazını eklentilerle saklamaya çalışmıyoruz; saf donanım gücüyle eziyoruz.

• AMD Ryzen™ 9 7900 İşlemci Gücü: Saat döngüsü başına işlem (IPC) gücü inanılmaz yüksek olan Ryzen 9 mimarisi sayesinde, ağır PHP betikleri ve dinamik veritabanı sorguları milisaniyeler içinde işlenir. CPU şişmez, sıraya girmez.

• Ultra Hafif KeyHelp Mimarisi: Arka planda RAM ve işlemcinizi sömüren hantal kontrol panelleri (cPanel vb.) yerine, donanımın %99’unu doğrudan web sitenize tahsis eden Alman harikası KeyHelp mimarisini kullanıyoruz.

• Cömert PHP Worker Sayısı: E-ticaret sitelerinizin “admin-ajax” kuyruklarında boğulmaması için paketlerimizde rakiplerin sunmadığı düzeyde 50 PHP Worker limiti sunuyoruz.

Eğer CPU limitleriyle savaşmaktan, sitenizi sürekli optimize etmeye çalışıp yine de 508 hatası almaktan yorulduysanız; yeni nesil Yüksek Performanslı Linux Hosting veya WordPress Hosting altyapımıza geçiş yapın.

Donanım limitlerini düşünmeyi bırakın, sadece projenizi büyütmeye odaklanın. Farkı 15 Gün Koşulsuz İade Garantisi ile sıfır riskle test edebilirsiniz!

Son yıllarda PHP 8 serisi ile (özellikle JIT – Just In Time Compiler mimarisiyle) gelen devrim niteliğindeki yenilikler, PHP 8.5 ile çok daha kusursuz bir hale geldi. Peki, eski bir sürümden güncel sürümlere geçmek sitenize ne kazandırır?

1. CPU ve Bellek (RAM) Optimizasyonu Güncel PHP sürümleri, kodu makine diline çevirirken çok daha agresif optimizasyonlar yapar. Aynı işlemi yapmak için %30’a varan oranda daha az RAM kullanır ve CPU’yu çok daha az meşgul eder. Bu, anlık trafik artışlarında (hit dalgalanmalarında) sunucunuzun çökmesini engeller.

2. Daha Hızlı Kod İşleme (Execution Time) Özellikle WooCommerce ödeme adımlarında yavaşlık yaşayan sitelerde veya ağır Laravel projelerinde, güncel sürümler sorguları çok daha kısa sürede işler. Bu hız artışı, ziyaretçi deneyimini doğrudan iyileştirir.

3. Üst Düzey Güvenlik Eski PHP sürümleri yeni keşfedilen güvenlik açıklarına karşı yama almaz. Sitenizi güncel bir PHP sürümünde barındırmak, veritabanı sızıntılarına karşı en güçlü ilk savunma hattıdır.

Panel Hantallığına Takılmayın Sektördeki birçok hosting firması, kullandıkları kontrol panellerinin (CWP vb.) hantallığı ve güncelleme almaması nedeniyle müşterilerini eski PHP sürümlerine mahkum bırakabiliyor. SaviorHost altyapısındaki Linux web hosting paketlerimizde kullandığımız Alman harikası KeyHelp kontrol paneli, güncel PHP sürümlerini anında ve stabil bir şekilde destekler.

AMD Ryzen™ 9 işlemcilerimizin sağladığı devasa gücü, en güncel PHP mimarisiyle birleştirerek yazılımlarınızın sınırlarını zorlayabilirsiniz.

Aşağıdaki rehber, en hızlı geri dönüş için önce teşhis, ardından kalıcı çözüm adımlarını sunar. Geliştirici olmanıza gerek yok—adımları sırayla uygulamanız yeterli.

1) İlk Teşhis: Hatanın Gerçek Yüzünü Görün (Debug Mode)

500’ün “neden”ini görmek için Debug Mode’u açın. Yönetim paneline erişebiliyorsanız Gelişmiş Parametreler → Performans → Hata Ayıklama Modu (Debug Mode) bölümünden aktif edin; erişemiyorsanız config/defines.inc.php dosyasında _PS_MODE_DEV_ değerini true yapın. İşiniz bitince mutlaka kapatın. (Resmi yardım merkezi ve topluluk kılavuzları bunu önerir.) help-center.prestashop.com+1

Neyi beklemelisiniz?
Beyaz sayfa yerine ayrıntılı PHP/Symfony hata yığını göreceksiniz. Satır ve dosya adı, sorunun modül/tema/çekirdek kaynaklı olup olmadığını açık eder.

2) En Sık Nedenler ve Hızlı Çözümler

A) Tema/Modül Çatışmaları (Güncelleme Sonrası)

• Belirti: 500, BO/FO’da aniden çökme.

• Çözüm: Son kurduğunuz modülü FTP ile /modules/ altında geçici olarak yeniden adlandırın (devre dışı kalır). Ardından önbelleği temizleyip sayfayı yenileyin. PrestaShop’un genel 500 hata kılavuzu modül kaynaklı çöküşleri özel olarak vurgular. help-center.prestashop.com

B) PHP Sürümü / Eklenti Uyumsuzluğu

• Belirti: Hata yığında Deprecated, Fatal error: Uncaught TypeError vb.

• Çözüm: Kullanılan PrestaShop sürümünün PHP uyumluluğunu kontrol edin. PrestaShop 8 için öneri PHP 8.1’dir; sistem gereksinimleri resmi dökümantasyonda detaylıdır. Ayrıca intl gibi eklentilerin yüklü olduğundan emin olun. PrestaShop

C) Dosya/klasör izinleri hatalı (permissions)

• Belirti: Log dizinine yazılamıyor, cache temizlenmiyor → 500.

• Çözüm: Tipik olarak dosyalar 644, klasörler 755 olmalı; özellikle var/cache ve var/logs (veya /var/log) yazılabilir olmalı. Toplulukta izin/ownership kaynaklı 500’ler sıkça görülür. prestashop.com

D) Bozulmuş .htaccess veya URL Yeniden Yazımı (mod_rewrite)

• Belirti: Friendly URL açıkken 500/404, yönlendirme döngüsü.

• Çözüm: .htaccess dosyasını yeniden üretin ve sunucuda URL rewrite’ın aktif olduğundan emin olun. PrestaShop 8 kullanıcı kılavuzu Friendly URL’lerin URL rewriting gerektirdiğini özellikle belirtir. docs.prestashop-project.org

E) Önbellek/Smarty Bozulmaları

• Belirti: Sayfalar açılmıyor ya da eski halini gösteriyor.

• Çözüm: BO’dan Performans → Önbellek temizle; erişemiyorsanız var/cache/prod ve var/cache/dev içeriğini silin (dizini değil, içeriği). Barındırma sağlayıcı rehberleri manuel temizlemeyi adım adım gösterir. SiteGround

3) Adım Adım “Hızlı Kurtarma” Akışı (How-To)

1. Debug Mode’u açın ve ekranda görünen gerçek hatayı not alın. (Sebebi netleştirir.) help-center.prestashop.com

2. Son değişikliği geri alın: Yeni modül/tema/sürüm güncellemesi yaptıysanız kapatın veya geri sarın. help-center.prestashop.com

3. Önbelleği temizleyin: BO → Performans’tan; erişemiyorsanız var/cache/prod/* ve var/cache/dev/* klasörlerinin içeriğini silin. SiteGround

4. .htaccess’i yeniden oluşturun: BO → Mağaza Parametreleri → Trafik & SEO → Friendly URL’yi kapatıp kaydedin, sonra tekrar açıp kaydedin (yeniden yazım aktif olmalı). docs.prestashop-project.org

5. PHP sürümü ve eklentileri doğrulayın: PrestaShop 8 için öneri PHP 8.1; intl, mbstring, gd, curl, zip gibi yaygın eklentileri kontrol edin (eksikler 500’e yol açabilir). PrestaShop

6. İzin/ownership’i düzeltin: Özellikle var/ altındaki yazılabilir dizinler (cache/log) için kullanıcı ve izinleri kontrol edin. (Topluluk çözümleri sıkça buna işaret eder.) prestashop.com

7. Kalıcı sorunlarda log’lara bakın: Yönetim → Gelişmiş Parametreler → Günlükler (Logs) ve sunucudaki var/log dosyaları ipucu verir. (Resmi 1.7 kılavuzu log sayfasını açıklar.) docs.prestashop-project.org

İpucu: Yerel/uzak sunucunuzun uyumluluğunu topluca test etmek için PrestaShop’un resmi PhpPsInfo aracını çalıştırabilirsiniz (gereksinim kontrolü). GitHub

4) Örnek Senaryo ve Çözüm (Kopyala–Yapıştır)

Belirti: Tema güncellemesi sonrası tüm sayfalarda 500.

Çözüm Planı:

5) Kalıcı Sağlamlık: “Bir daha yaşanmaması” için 6 öneri

1. Sürüm uyum tablosuna göre güncelleyin: PHP/PrestaShop uyumunu kontrol etmeden sürüm yükseltmeyin. PrestaShop

2. Staging ortamı kullanın: Modül/tema güncellemelerini önce test mağazasında deneyin.

3. Düzenli yedek alın: Dosya + veritabanı.

4. İzin politikası: Dosyalar 644, klasörler 755; var/ altı yazılabilir. prestashop.com

5. Önbellek stratejisi: Büyük değişikliklerden sonra cache temizliği rutine bağlansın. SiteGround

6. Güncel intl/ICU ve gerekli eklentiler: Yerelleştirme ve tarih/sayı biçimleri için kritik. PrestaShop

SSS (Kısa)

500 hatası neden olur?
En çok modül/tema uyumsuzluğu, PHP sürüm/eklenti uyumsuzluğu, bozuk .htaccess, yanlış izinler ve bozuk cache yüzünden. Resmi yardım merkezi bu başlıkları kapsıyor. help-center.prestashop.com

Önbelleği elle nasıl temizlerim?
Yönetim yoksa var/cache/prod/* ve var/cache/dev/* içeriğini silin; ardından siteyi yenileyin. SiteGround

Friendly URL açıkken 500/404 alıyorum, ne yapmalıyım?
URL yeniden yazımı (mod_rewrite) aktif mi kontrol edin; Friendly URL’yi kapat–kaydet–aç–kaydet yaparak .htaccess’i yeniden oluşturun. docs.prestashop-project.org

Hangi PHP sürümünü kullanmalıyım?
PrestaShop 8 için öneri PHP 8.1’dir (güncel resmi dökümantasyona göre). PrestaShop

Swap; RAM yetersiz kaldığında veya çekirdek (kernel) seyrek kullanılan sayfaları RAM’den çıkarıp diske yazmaya karar verdiğinde devreye giren disk alanıdır. Linux, RAM hâlâ boş olsa bile önbellek/verimlilik için bazı sayfaları swap’a taşıyabilir; bu anormal değildir. Sorun, sistemin sürekli swap yapması (thrashing) ve I/O yükünün artmasıdır. wiki.archlinux.org+1

Swappiness parametresi (vm.swappiness), çekirdeğin swap’a yönelme eğilimini belirler (0–100). Düşük değer swap’ı azaltır, yüksek değer artırır. phoenixNAP | Global IT Services+1

Hızlı Kontrol Listesi (5 Dakikada)

1. Genel bellek ve swap kullanımını görün:

   free -h && swapon --show


2. Şu an en çok RAM yiyen süreçleri listeleyin:

   ps aux --sort=-%mem | head -n 15


3. Sistemde yoğun swap olup olmadığını gözlemleyin:

   vmstat 3
# si/so sütunları swap-in/swap-out hızlarını gösterir


4. OOM killer ve bellek hatalarını kontrol edin:

   dmesg | egrep -i 'out of memory|oom' || journalctl -k | egrep -i 'out of memory|oom'


5. Swappiness değerini öğrenin:

   cat /proc/sys/vm/swappiness


Not: Linux’un bir miktar swap kullanması normaldir; sürekli yüksek si/so ve yüksek disk I/O görüyorsanız problem var demektir. Unix & Linux Stack Exchange

Nedenler (Gerçek Dünya Senaryoları)

• RAM yetersizliği (trafik artışı, ağır sorgular, büyük PHP process’leri).

• Yanlış swappiness (çok yüksek ise gereksiz swap). Red Hat Learning

• Servis yapılandırması (ör. PHP-FPM pm.max_children, MySQL/InnoDB tamponları, Elasticsearch/Redis).

• Bellek sızıntısı (uygulama veya eklentiler).

• Hibernation/suspend gereksinimi (swap boyutu planlamasını etkiler). wiki.archlinux.org

Teşhis: Derinlemesine

1) Kullanım Profili ve Cache

Linux, seyrek kullanılan sayfaları swap’a taşıyıp RAM’i sayfa önbelleği için serbest bırakabilir; bu, performans optimizasyonudur. Panik yapmadan önce swap’in ne kadar aktif kullanıldığına bakın (yoğun si/so). Ask Ubuntu+1

2) Swappiness Etkisi

• Geçici deneme (yeniden başlatmaya kadar):

  sudo sysctl vm.swappiness=10


• Kalıcı ayar:
  /etc/sysctl.conf dosyasına satır ekleyin:

  vm.swappiness=10


  Ardından: sudo sysctl -p
  (Değerler 0–100; düşük değer genelde web sunucuları için daha mantıklıdır.) phoenixNAP | Global IT Services

Uyarı: Swappiness’ı aşırı düşürmek RAM baskısını gizlemez; RAM yetmiyorsa swap yine dolar ve OOM riski doğar. Kaynağı bulmak ve gerektiğinde RAM’i artırmak esastır. docs.kernel.org

3) Suçlu Süreçleri İzleyin

top, htop, smem ile süreç bazında kullanım. MySQL, PHP-FPM, Redis, Elasticsearch gibi servisler piklerde swap’a itebilir. “RAM boşken swap var” durumu genellikle seyrek sayfalar ile ilgilidir; bu normaldir. Server Fault

Çözümler (Kısa ve Uzun Vadeli)

A) Swap’i Temizlemek (Acil Durum)

Swap’i kapatıp açmak swap’teki sayfaları RAM’e taşır (yeterli RAM varsa):

Bu işlem geçicidir; kök nedeni çözmez. Red Hat

B) Swappiness’i Uygun Seviyeye Çekmek

• Web uygulamaları ve veritabanı ağırlıklı iş yüklerinde sıklıkla 10–20 aralığı tercih edilir. Test ederek en uygun değeri bulun. phoenixNAP | Global IT Services

C) Swap Alanını Büyütmek (Ubuntu/Debian örneği)

1. Mevcut durumu kontrol edin: swapon --show

2. Swap’i kapatın: sudo swapoff -a

3. Yeni dosya oluşturun (ör. 4G):

   sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile


4. Kalıcı yapmak için /etc/fstab’a ekleyin:

   /swapfile none swap sw 0 0


   (Detaylı adımlar ve varyasyonlar için rehberler.) digitalocean.com+2linuxize.com+2

D) zswap / zram ile Sıkıştırılmış Swap

• zswap: Disk yerine önce RAM içinde sıkıştırılmış cache kullanır; I/O’yu azaltabilir.

• zram: RAM içinde sıkıştırılmış blok aygıt oluşturur; düşük RAM’li VPS’lerde faydalı.
  Kurulum ve etkileri için dağıtım belgelerine bakın. wiki.archlinux.org+1

E) Uygulama ve Servis Tuning (WordPress Odaklı)

• PHP-FPM: pm.max_children, pm.max_requests değerlerini izleyip düşürün/dengeleyin.

• MySQL/InnoDB: innodb_buffer_pool_size’ı mevcut RAM’e göre ayarlayın; aşırı büyükse RAM baskısı yaratır.

• Object Cache: Redis/Memcached kullanın ama bellek sınırlarını (maxmemory) koyun.

• Cron/Queue işler (WP-CLI, yedekleme, indeksleme): pik saatlerde değil, yoğun olmayan saatlere alın.
  (Bu ayarlar swap’i doluran bellek baskısını kökten azaltır; Linux’un swap davranışına ilişkin genel kaynaklarla birlikte düşünün.) Unix & Linux Stack Exchange

F) Güvenlik ve Gizlilik

Swap’te hassas veriler kalabilir; şifreli swap tercih edin (özellikle fiziksel sunucularda/laptaplarda). wiki.archlinux.org

Ne Zaman Donanıma (RAM) Gitmeli?

• Swappiness düşürmenize, servisleri optimize etmenize ve zswap/zram denemenize rağmen vmstat’te sürekli yüksek si/so, yüksek I/O bekleme, OOM kayıtları görüyorsanız: RAM artışı en temiz çözümdür. Arch Wiki ve topluluk rehberleri de swap’ın RAM’in yerine geçmediğini, sadece tamamlayıcı olduğunu vurgular. wiki.archlinux.org

SSS

“RAM boşken neden swap kullanılıyor?”
Çekirdek, seyrek kullanılan sayfaları swap’e bırakarak RAM’i disk önbelleği için serbest tutabilir. Bu, normaldir ve performansı artırabilir. Sorun ancak sürekli aktif swap hareketi olduğunda başlar. Ask Ubuntu+1

“Swappiness’i 0 yaparsam swap tamamen kapanır mı?”
Hayır. Swappiness, eğilim parametresidir; swap’ı yok etmez. Zorunluluk doğarsa çekirdek yine swap kullanabilir. Unix & Linux Stack Exchange