Linux sunucuda RAM doldu: OOM hatası ve kapanan servislerin çözümü
Linux sunucuda RAM dolu görünüyor, bir işlem Killed diyerek kapanıyor veya servis kendiliğinden duruyor. İlk iş, bütün sunucunun belleğinin mi yetersiz kaldığını, uygulamanın kendi sınırına mı ulaştığını bulmaktır. Linux'un dosya önbelleği için RAM kullanması normaldir; yalnız yüksek kullanım yüzdesine bakarak arıza kararı veremeyiz.
Bu rehberde VPS RAM yetersizliği, Linux OOM hatası ve Ubuntu'da swap oluşturma konularını aynı çözüm akışında ele alıyoruz. Önce olayı kayıtlardan doğrulayacak, belleği kullanan uygulamayı bulacak, sonra iş yükü ve swap için uygun yolu seçeceğiz. Genel CPU ve disk ölçümleri için sunucu kaynak kontrolü rehberine bakabilirsiniz.
Gereken erişim: SSH bağlantısı ve gerektiğinde sudo yetkisi. Komutlar bağlandığınız Linux sunucuda çalışır. root kullanıcısıyla bağlıysanız sudo önekini yazmanız gerekmez. İlk incelemeler salt okunurdur; swap bölümü ise diskte dosya oluşturur ve sistem ayarını değiştirir. Paylaşımlı hosting kullanıyorsanız bu işlemleri tüm sunucuya uygulayamazsınız; cPanel kaynak kullanımını inceleyin.
SSH bağlantısı da yanıt vermiyorsa: DCHost müşteri portalındaki konsolu deneyin. Konsol da kullanılamıyorsa hizmet numarası ve olay saatiyle destek talebi açın; yalnız RAM doluluğu varsayımıyla art arda güç kapatma veya yeniden başlatma yapmayın.
Görseller Ubuntu 24.04 LTS kullanan gerçek bir demo VPS'ten alınmıştır. OOM örneği, yalnız test uygulamasına ayrılmış küçük bir bellek sınırı içinde oluşturuldu; sunucunun bütün RAM'i tüketilmedi. Swap işlemleri ayrı bir örnektir. Kendi sunucunuzda hata üretmek için RAM doldurmanız gerekmez. Ekranlardaki demo servis ve dosya adları örneğe aittir; özel sunucu bilgileri gizlenmiştir.
1. RAM gerçekten yetersiz mi, önbellek mi?
Sorunun yaşandığı saati not edin. Sunucuya bağlandığınızda uygulama zaten kapanmışsa RAM boşalmış olabilir; o anki rahat görünüm geçmişteki OOM olayını dışlamaz.
date -Is
free -h
vmstat 1 5
vmstat birkaç saniye boyunca ölçüm alır. İlk satırın CPU ve I/O hızları açılıştan beri geçen süreyi, sonraki satırlar birer saniyelik aralıkları yansıtır. Süreç ve bellek alanları ise o anki durumu gösterir.
| Alan | Nasıl yorumlanır? |
|---|---|
available | Yeni uygulamalar için swap kullanmadan ayrılabilecek RAM'in tahmini. Yalnız free sütunundan daha anlamlıdır; kesin tahsis garantisi değildir. |
buff/cache | Dosya ve sistem önbellekleri. Linux ihtiyaç olduğunda bunun uygun bölümünü geri kazanabilir; tamamı her an boşaltılabilecek alan değildir. |
Swap used | Swap'ta duran veri. Tek başına yavaşlama veya aktif bellek sıkışması kanıtı değildir. |
vmstat içindeki si / so | Diskten RAM'e ve RAM'den swap'a veri hareketi. Uzun süre düşük available, sürekli hareket ve uygulama gecikmesi birlikte değerlendirilir. |
Yalnız free sütununa bakmayın. Linux önbellek kullanır; available değeri daha anlamlı bir başlangıç noktasıdır.
1. adım: available değerini okuyun
- available değerini okuyun
Bu kayıtta 1,6 GiB bellek kullanılabilir. buff/cache değerini tek başına RAM yetersizliği olarak yorumlamayın.
- Swap hareketini ayrı değerlendirin
vmstat çıktısındaki si ve so değerleri sıfır. İlk satırdaki hızlar açılıştan beri ortalamadır; sonraki hızlar ölçüm aralığına aittir.
Bu ölçüm sırasında sunucunun genel belleği tükenmiş değil. Swap henüz tanımlı değil.
Başlangıç ölçümünde yaklaşık 1,9 GiB toplam RAM, 1,6 GiB kullanılabilir bellek ve sıfır etkin swap vardı. Daha sonra gördüğümüz demo OOM olayı, toplam RAM dolduğu için değil, test servisinin kendi sınırına ulaştığı için oluştu.
Sonraki adım: available düşükse veya uygulama beklenmedik biçimde kapanıyorsa olay kaydına geçin. available yeterli, belirti yok ve yalnız buff/cache yüksekse önbelleği zorla temizlemeyin. drop_caches kullanmak uygulamanın bellek ihtiyacını düzeltmez; verilerin yeniden diskten okunmasına yol açabilir.
2. Kapanmanın sebebi gerçekten OOM mi?
OOM, “Out of memory” ifadesinin kısaltmasıdır. Çekirdek, gerekli belleği sağlayamadığı bazı durumlarda bir veya daha fazla süreci sonlandırabilir. Ancak Killed, 137 çıkış kodu veya durmuş bir servis, tek başına OOM kanıtı değildir. 137 yaygın kabuklarda SIGKILL sinyaliyle ilişkilidir; elle sonlandırma, başka bir yönetim aracı veya uygulamanın kendi çıkış kodu da araştırılmalıdır.
Önce son 30 dakikanın çekirdek kayıtlarını inceleyin. Olay daha eskiyse süreyi değiştirin:
sudo journalctl -k -b --since "30 minutes ago" --no-pager \
--grep='oom-kill|out of memory|killed process|memory cgroup' \
--case-sensitive=no
-k çekirdek kayıtlarını, -b mevcut açılışı seçer. Olay yeniden başlatmadan önce olduysa sudo journalctl --list-boots ile kayıtlı açılışları bulun; önceki açılış mevcutsa -b -1 kullanın. Eski kayıtların saklanmamış olması veya yanlış saat aralığı, sonuç çıkmamasına neden olabilir.
Kapanan servisi biliyorsanız aşağıdaki ilk satırda my-app.service yerine gerçek servis adını yazın:
APP_UNIT=my-app.service
sudo journalctl -u "$APP_UNIT" -b --since "30 minutes ago" --no-pager
systemctl show "$APP_UNIT" \
--property=Id,LoadState,ActiveState,SubState,Result,ExecMainCode,ExecMainStatus
LoadState=not-found, yazdığınız servis adının bulunmadığını gösterir; adı düzeltin. Result=oom-kill önemli bir ipucudur. Yine de aynı saat, süreç ve servisle ilişkili günlükleri birlikte okuyun. Servis yeniden başladıysa güncel Result geçmişteki hatayı artık göstermeyebilir.
Test servisi başlayamadı. Kapanmanın nedenini görmek için servisin sonuç alanlarını okuyoruz.
1. adım: Result=oom-kill satırını bulun
- Result=oom-kill satırını bulun
Servis sonucu, işlemin OOM nedeniyle sonlandırıldığını gösteriyor. Sonraki adımda günlük kaydıyla hangi sınırın aşıldığını doğrulayacağız.
- Sinyal ve durum alanlarını birlikte okuyun
ExecMainCode=2 ve ExecMainStatus=9 birlikte SIGKILL ile sonlanmayı gösterir; failed başarısız durumdur. Bu alanlar tek başına OOM kanıtı değildir.
Bu hata yalnızca bellek sınırı konulan demo serviste oluşturuldu; sunucunun genel RAM’i doldurulmadı.
Önce servisin günlüğüne, ardından aynı olayın çekirdek kaydına bakın. Böylece genel RAM sorunu ile servis sınırını ayırabilirsiniz.
1. adım: OOM killer mesajını kontrol edin
- OOM killer mesajını kontrol edin
Servis günlüğü, bu servisteki bir sürecin OOM killer tarafından sonlandırıldığını söylüyor. Süreç kimliğini ve olay zamanını kendi kaydınızla eşleştirin.
- Cgroup sınırını fark edin
Çekirdek kaydındaki CONSTRAINT_MEMCG, bu denemede servis grubunun sınırına takıldığımızı açıklar.
CONSTRAINT_MEMCG bu olayın cgroup bellek sınırıyla ilgili olduğunu gösterir. Genel sunucu belleğinin tükendiği sonucu çıkarılmaz.
Gerçek demoda dchost-oom-demo.service, 96 MiB bellek sınırı ve MemorySwapMax=0 ile çalışıyordu. Yalnız test programı 160 MiB bellek ayırmayı denedi. Sonuç Result=oom-kill, ExecMainCode=2, ExecMainStatus=9 ve ActiveState=failed oldu. Çekirdek kaydındaki CONSTRAINT_MEMCG, olayın servis grubunun bellek sınırında gerçekleştiğini doğruladı; bu örnek bütün sunucunun RAM'inin bittiği bir olay değildir.
Üç farklı durum, üç farklı çözüm
| Bulgu | Anlamı ve izlenecek yol |
|---|---|
| Çekirdekte sistem genelindeki bellek sıkışmasıyla ilişkili OOM kaydı | Olay anındaki uygulama yükünü, kullanılabilir RAM'i ve swap durumunu birlikte inceleyin. Killed process satırı tek başına kapsamı söylemez; çevresindeki OOM kaydını da okuyun. |
Memory cgroup out of memory, CONSTRAINT_MEMCG veya ilgili grubun limit/olay kayıtları | Uygulama ya da konteyner kendi bellek sınırına ulaşmış olabilir. Sunucuda boş RAM olsa bile bu sınırda OOM oluşabilir. Servis sınırını kontrol edin. |
systemd-oomd günlüğünde sonlandırma kaydı | Bu servis, bellek baskısını değerlendirip çekirdeğin OOM aşamasından önce müdahale edebilir. Kendi günlüklerini ve izlediği birimlerin ayarlarını inceleyin. |
Her sistemde systemd-oomd kurulu veya etkin değildir. Önce durumunu okuyun; varsa aynı olay aralığına bakın:
systemctl is-active systemd-oomd.service
sudo journalctl -u systemd-oomd.service -b --since "30 minutes ago" --no-pager
inactive, yalnız şu anki durumu gösterir. Cannot allocate memory, Python MemoryError veya uygulamaya ait “memory limit” hatası görüyorsanız uygulama ve süreç sınırlarını da inceleyin; bunlar mutlaka bir OOM kill gerçekleştiği anlamına gelmez. OOM korumasını veya systemd-oomd servisini kapatmak genel çözüm değildir.
3. Belleği hangi uygulama kullanıyor?
Çalışan süreçleri RAM kullanımına göre sıralayın:
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 11
PID süreç numarası, COMMAND program adı, RSS ise sürecin RAM'de bulunan bölümünün yaklaşık büyüklüğüdür. RSS burada KiB cinsindedir; örneğin 32768, 32 MiB eder. Liste başlıkla birlikte en fazla 11 satır gösterir. Tam komut satırını göstermediğimiz için komuta yazılmış parola veya erişim anahtarları da bu listede yer almaz.
Süreç adını, PID numarasını ve RAM kullanımını birlikte okuyun. Listenin başındaki süreç otomatik olarak sorunlu sayılmaz.
1. adım: Süreci ve PID değerini belirleyin
- Süreci ve PID değerini belirleyin
COMMAND süreç adını, PID ise o çalışmanın kimliğini gösterir. Burada ilk sırada fwupd var; yalnızca bu listeye bakarak süreci kapatmayın.
- RSS birimini doğru okuyun
ps çıktısındaki RSS, KiB cinsindendir. 48576 KiB yaklaşık 47,4 MiB eder; %MEM sütunu RAM içindeki payını gösterir.
Bu görüntü OOM testinden önce alındı. Canlı süreç listesinin nasıl okunacağını gösterir; testte sonlandırılan süreci göstermez.
Bu görsel, OOM denemesi öncesindeki süreç listesidir; hata veren demo işinin geçmişini günlüklerden okuduk. Listedeki bir sistem servisini OOM'nin nedeni olarak işaretlemiyoruz.
En üstteki süreç mutlaka hatalı değildir. Veritabanı, antivirüs taraması veya yedekleme işi beklenen miktarda bellek kullanıyor olabilir. Bir uygulamanın birden fazla işçi süreci (worker) de bulunabilir. Ayrıca OOM tarafından kapatılan süreç artık listede olmayacaktır; bu yüzden ikinci adımdaki kayıtları kullanıyoruz.
RSS değerlerini toplayıp sunucunun toplam RAM kullanımı diye yorumlamayın. Paylaşılan sayfalar birden fazla süreçte sayılabilir. Gerekirse tek bir süreç için PSS değerini inceleyin; bu ölçüm paylaşılan belleği onu kullanan süreçler arasında orantılı böler.
Aşağıdaki 1234 yerine inceleyeceğiniz gerçek PID'yi yazın:
CHECK_PID=1234
sudo awk '/^(Rss|Pss|Swap):/ {print}' "/proc/$CHECK_PID/smaps_rollup"
Bu dosya her ortamda erişilebilir olmayabilir. Süreç kapanırsa dosya da kaybolur; PID daha sonra başka bir süreç için kullanılabileceğinden, kimliğini tekrar kontrol edin. PSS, süreç karşılaştırmasını iyileştirir; çekirdeğin bütün bellek kullanımını kapsayan toplam sunucu hesabı değildir.
4. Sunucuda RAM varken servis neden kapanıyor?
Bir cgroup, bir servis veya konteyner grubunun kaynak kullanımını sınırlamaya yarar. systemd ile çalışan bir serviste aşağıdaki değerleri okuyun. APP_UNIT hâlâ kendi servis adınız olmalıdır:
systemctl show "$APP_UNIT" \
--property=ControlGroup,MemoryCurrent,MemoryHigh,MemoryMax,MemorySwapMax
| Ayar | Ne anlama gelir? |
|---|---|
MemoryCurrent | Servis grubunun şu anki bellek kullanımı. Tek bir sürecin RSS değeriyle aynı hesap değildir. |
MemoryHigh | Bellek geri kazanımını ve yavaşlatmayı devreye sokabilen eşik. Tek başına aşılması doğrudan OOM kill talimatı değildir. |
MemoryMax | Grubun bellek üst sınırı. Kullanım bu sınırın altına indirilemezse grup içinde OOM oluşabilir. |
MemorySwapMax | Grubun kullanabileceği swap sınırı. 0 ise ilgili grubun yeni swap kullanımına izin verilmez. |
infinity | O ayarda sonlu sınır olmadığı anlamına gelir. Üst cgroup, konteyner veya sunucunun kendi kapasitesi yine sınırlayıcı olabilir. |
Sunucuda kullanılabilir RAM olsa bile bir servisin kendi bellek sınırı daha düşük olabilir.
1. adım: 96 MiB sınırını doğrulayın
- 96 MiB sınırını doğrulayın
100663296 bayt, 96 MiB eder. MemorySwapMax=0 bu servis için swap kullanımının kapalı olduğunu gösterir.
- oom_kill sayacını kaydedin
oom_kill 1, bu demo grubunda bir sürecin OOM nedeniyle sonlandırıldığını gösteriyor. Sonraki denemeden sonra sayacın artıp artmadığını karşılaştıracağız.
memory.events burada yalnızca demo üst grubundan okunuyor. Sayaçlar bu grubun olaylarını gösterir; sunucunun tüm geçmişini özetlemez.
cgroup v2 kullanılan sistemlerde grubun memory.events dosyası max, oom ve oom_kill gibi sayaçlar içerir. oom ile oom_kill aynı şey değildir: her başarısız bellek isteği bir sürecin öldürülmesiyle sonuçlanmaz. Sayaçlar grubun ömrü boyunca birikir ve memory.events alt grupların olaylarını da kapsayabilir. Demoda max=18, oom=1 ve oom_kill=1 görüldü; max=18, 18 sürecin kapatıldığı anlamına gelmez. Olay öncesi/sonrası değerleri, doğru grup ve günlük saatiyle eşleştirin. Grup kaldırıldıysa bu dosya da bulunmayabilir.
Çözüm seçimi: Önce uygulamanın daha az eşzamanlı iş veya daha küçük veri parçalarıyla çalışmasını değerlendirin. Sınır yanlış belirlenmişse, diğer servislerin ihtiyacını da hesaba katarak uygulama ya da konteyner ayarından düzeltin. Üst sınırı körlemesine infinity yapmak sorunu bütün sunucuya taşıyabilir. Sunucuya swap eklemek, MemoryMax değerini otomatik artırmaz; MemorySwapMax=0 olan grubun kısıtını da kaldırmaz.
Gerçek örnek: daha küçük işi aynı sınırda tamamlamak
Testin bellek isteğini 160 MiB’den 32 MiB’ye düşürdük. Servisin bellek ve swap sınırlarını değiştirmedik.
1. adım: 32 MiB iş yükünün tamamlandığını görün
- 32 MiB iş yükünün tamamlandığını görün
Günlükte 32 MiB isteği ve Workload completed mesajı var. Gerçek uygulamanızda benzer bir düşüş için eşzamanlı işlem veya iş boyutu ayarını inceleyin.
- Başarıyı sınırla birlikte doğrulayın
Result=success yazıyor; MemoryMax aynı ve MemorySwapMax hâlâ 0. Alttaki oom_kill sayacı da 1’de kaldı.
Bu sonuç test iş yükünü azaltarak alındı. Swap açıldığı için OOM sorununun çözüldüğü anlamına gelmez.
Demo programının tek seferde istediği bellek 160 MiB'den 32 MiB'ye indirildi. Aynı 96 MiB MemoryMax ve MemorySwapMax=0 altında yeniden çalıştırıldığında günlükte Workload completed: 32 MiB allocated and touched, servis sonucunda Result=success görüldü. Başarı, iş yükünün küçültülmesinden geldi; bu aşamada swap eklenmedi.
Örneğin yalnız demo servisini içeren üst grubunda oom=1 ve oom_kill=1 sayaçları başarılı denemeden sonra da kaldı. Önceki olayı saymaları normaldir; başarı için bu sayıların sıfırlanması gerekmez. Kayıtta görülen reset-failed, servis hata durumunu temizler; bellek ihtiyacını veya cgroup olay sayacını düzeltmez.
Ekrandaki ActiveState=active, bu örnekte programın hâlâ çalıştığı anlamına gelmez. Demo bir kez çalışıp tamamlanan oneshot servisidir; RemainAfterExit ayarı başarılı çıkıştan sonra birimi etkin gösterir. Gerçek bir web servisinde işlem sonucu yanında yanıt verdiğini de kontrol etmelisiniz.
Bu örnek, daha az bellek isteyen bir işin aynı sınırda tamamlanabildiğini gösterir; 160 MiB'lık verinin parçalar hâlinde işlendiği bir test değildir. Gerçek uygulamada bellek ihtiyacını azaltma seçenekleri; aynı anda çalışan worker sayısını azaltmak, büyük dosyayı tek seferde belleğe almak yerine parça parça işlemek veya aynı saate denk gelen yedekleme ve tarama işlerini ayırmak olabilir. Bu ayarlar uygulamaya özeldir; bütün PHP, veritabanı ve kuyruk servislerine uygulanacak tek bir sayı yoktur.
96 MiB sınırındaki demo serviste 160 MiB isteği başarısız oldu; 32 MiB denemesi aynı sınırda tamamlandı. Yaklaşık 20 saniyelik gerçek kayıt, 1× hızda; bekleme aralıkları korunmuştur.
Kaydın yazılı anlatımı
- Yalnız demo servisi başlatılır; 160 MiB isteyen iş, 96 MiB servis sınırında OOM ile durur.
- Servis sonucu ile çekirdek kaydı birlikte okunur;
oom-killveCONSTRAINT_MEMCGaynı olayı gösterir. MemoryMax,MemorySwapMaxve yalnız demo servisini kapsayan grubun olay sayaçları kontrol edilir.- Demo işinin talebi 32 MiB yapılır ve aynı bellek sınırında yeniden çalıştırılır.
- İşin tamamlandığı,
Result=successolduğu ve öncekioom_kill=1sayacının tarihçe olarak kaldığı görülür.
5. Swap gerekli mi, ne kadar ayırmalısınız?
Swap, disk üzerinde belleğe yardımcı olarak kullanılan alandır. Daha az kullanılan bazı bellek sayfalarının diske taşınmasını sağlar. Kısa süreli bellek artışlarında pay bırakabilir; sürekli RAM açığını ve uygulama hatasını tek başına çözmez. Disk erişimi RAM'den daha yavaştır. Büyük swap dosyası, yoğun uygulamaya aynı miktarda RAM eklemekle eşdeğer değildir.
“RAM'in iki katı swap” kuralını bütün VPS'lere uygulamayın. Normal ve yoğun saatlerdeki available, uygulamanın kısa süreli ihtiyacı, mevcut swap kullanımı, disk kapasitesi ve kabul edilebilir gecikme birlikte değerlendirilmelidir.
| Durum | Uygun yaklaşım |
|---|---|
| Arada bir yükselen bellek ihtiyacı, yeterli disk, uygulama swap kullanımına uygun | Ölçülü swap alanını değerlendirin ve uygulama gecikmesini takip edin. |
Sürekli düşük kullanılabilir RAM, yoğun si / so, gecikme | İş yükünü ve bellek ayarlarını iyileştirin; gerekirse RAM kapasitesini artırmayı planlayın. |
Servisin kendi bellek sınırı veya MemorySwapMax=0 | Önce ilgili sınırı ve uygulamanın ihtiyacını ele alın. |
| cPanel/WHM veya başka yönetim paneli | Panelin desteklenen işletim sistemi, RAM ve swap önerilerini; ayrıca veritabanı, posta ve antivirüs yükünü birlikte değerlendirin. |
cPanel'in işletim sistemine göre yayımladığı swap önerileri panel gereksinimi içindir; her Linux sunucu için zorunlu bir boyut kuralı değildir. Swap eklemek, cPanel veya uygulama için gerekli fiziksel RAM'in yerine geçmez. cPanel kurulum rehberindeki hazırlıkları da kontrol edin.
6. Ubuntu'da swap dosyası oluşturun
Aşağıdaki yöntem yerel ext4 dosya sistemi için hazırlanmıştır. KVM VPS'inizde dosya sistemi farklı olabilir. Önce kontrol edin; Btrfs, NFS, overlay veya kısıtlı konteyner ortamına aynı komutları uyarlamayın.
Önce mevcut swap ve diski kontrol edin
swapon --show
free -h
findmnt --target / --output SOURCE,FSTYPE,TARGET
findmnt --fstab --types swap --output SOURCE,TARGET,FSTYPE,OPTIONS
df -h -- /
swapon --show etkin swap alanlarını gösterir; boş sonuç etkin swap olmadığını belirtir. /etc/fstab içinde kayıtlı ama henüz etkinleşmemiş bir alan ayrıca bulunabilir. Hiç swap kaydı yoksa findmnt --fstab --types swap eşleşme bulamayabilir ve 1 çıkış kodu döndürebilir; bu durum tek başına /etc/fstab dosyasının bozuk olduğunu göstermez. Var olan swap dosyasının üstüne yazmayın ve etkin alana yeniden mkswap uygulamayın.
Etkin swap alanını, dosya sistemini ve boş disk alanını kontrol ederek başlayın.
1. adım: Mevcut swap alanını belirleyin
- Mevcut swap alanını belirleyin
free çıktısında Swap toplamı 0 B. swapon listesi de boş; bu demoda önceden etkin bir swap alanı yok.
- Dosya sistemini ve boş alanı okuyun
Kök dosya sistemi ext4 ve df çıktısında 36 GiB boş alan var. Swap dosyası diskten yer ayırır; yeterli boş alan bırakın.
Bu yöntem bu demodaki ext4 dosya sistemi içindir. Btrfs, ağ dosya sistemi veya sağlayıcı kısıtı varsa aynı komutları doğrudan uygulamayın.
Demoda kök dosya sistemi ext4, başlangıçta etkin swap sayısı sıfırdı. Yaklaşık 38 GiB kök bölümde 36 GiB kullanılabilir alan bulunduğu kontrol edildi; örnek dosya bundan sonra oluşturuldu.
Örnekte 1 GiB büyüklüğünde, adı /swap-dchost-demo olan yeni dosya kullanılıyor. Bu boyut, oluşturma ve kaldırmayı göstermek içindir; sizin sunucunuz için kapasite tavsiyesi değildir. Diskte bu dosya, uygulamalar ve günlükler için yeterli alan bırakın. Disk doluysa önce alan sorununu çözün.
Yeni dosyayı oluşturun
Bu komut, mevcut dosyanın üstüne yazmamak için conv=excl kullanır. Dosya erişimi yalnız root için açılır:
sudo sh -c 'umask 077; dd if=/dev/zero of=/swap-dchost-demo bs=1M count=1024 conv=excl status=progress'
File exists alırsanız durun; mevcut dosyayı silip devam etmeyin. Yazma hatası veya No space left on device varsa sonraki mkswap adımına geçmeyin. Komut başarıyla tamamlandığında boyutu ve izni kontrol edin:
sudo stat -c '%n | %s bytes | permissions=%a | owner=%U' /swap-dchost-demo
1 GiB örneğinde boyut 1073741824 bayt, izin 600, sahip root olmalıdır. Swap dosyası bellekteki hassas verileri içerebileceği için herkese okunabilir bırakılmaz.
Bu demoda 1 GiB dosya oluşturuldu, erişimi yalnız root ile sınırlandı ve swap biçimi yazıldı.
1. adım: Mevcut dosyanın üzerine yazmayı engelleyin
- Mevcut dosyanın üzerine yazmayı engelleyin
dd komutundaki conv=excl, aynı adla dosya varsa işlemi durdurur. count=1024 ve bs=1M bu örnekte 1 GiB oluşturur.
- Boyutu ve erişim izinlerini doğrulayın
1.0G dosya boyutunu, -rw------- ise yalnız dosya sahibinin okuma ve yazma iznini gösterir. Bu dosyanın sahibi root.
conv=excl mevcut dosyanın üzerine yazmayı engeller. mkswap yalnız bu iş için yeni oluşturduğunuz dosyada çalıştırılmalıdır.
dd, bu örnekte dosyanın içeriğini gerçekten yazar. truncate ile yalnız uzunluk vermek boşluklu dosya oluşturabilir; swapon böyle bir dosyayı reddedebilir. Btrfs'te NOCOW, sıkıştırma, veri yerleşimi ve snapshot kısıtları vardır; yalnız dd kullanmak bu koşulları sağlamaz. Btrfs kullanıyorsanız Btrfs'in swap dosyası yönergesini izleyin.
Swap olarak hazırlayıp etkinleştirin
Yalnız az önce oluşturduğunuz yeni dosyada sırayla çalıştırın:
sudo mkswap /swap-dchost-demo && sudo swapon /swap-dchost-demo
swapon --show=NAME,TYPE,SIZE,USED,PRIO
free -h
&&, ilk komut başarılıysa etkinleştirmeye geçer. mkswap dosyaya swap yapısı yazar; bunu veri diskinize, rastgele /dev/... aygıtına veya eski swap alanına uygulamayın. swapon hata verirse hatayı araştırın; dosya listede görünmeden swap etkinleşti kabul etmeyin.
Swap listesinde dosyanın görünmesi, alanın etkin olduğunu gösterir. Kullanılabilir RAM’i ayrıca okuyun.
1. adım: Etkin swap alanını bulun
- Etkin swap alanını bulun
1024M boyut, yaklaşık 1 GiB alanı gösterir. USED sütunundaki 0B, bu anda swap kullanılmadığı anlamına gelir; bir hata değildir.
- available değerini tekrar okuyun
Bu ölçümde free sütunu 97 MiB’ye düşmüş olsa da available hâlâ 1,6 GiB. Dosya oluşturma sırasında büyüyen önbelleği RAM tükenmesiyle karıştırmayın.
Swap alanının etkin olması, MemorySwapMax=0 olan test servisinin swap kullanabileceği anlamına gelmez.
Gerçek etkinleştirmede dosya 1,0 GiB kapasite, USED=0B ve PRIO=-2 ile listelendi. Kullanılabilir swap boyutu 1073737728 bayttı; 1 GiB dosya boyutundan bir sayfa küçüktür, çünkü swap başlığı için alan ayrılır.
Kontrol: Tam dosya yolu swapon --show listesinde, yeni kapasite de free -h içindeki Swap satırında görünmelidir. USED=0B, kullanılmadığı anlamına gelir; etkinleşmenin başarısız olduğu anlamına gelmez. Yalnız bu adım yapıldıysa yeniden açılış için kalıcı kayıt oluşturulmuş olmaz.
7. Yeniden açılışta kullanılması için kaydı doğrulayın
Swap alanını kalıcı kullanacaksanız /etc/fstab içine kayıt gerekir. Bu dosyada sistem diskleri de bulunur; var olan satırları değiştirmeyin. Önce bir yedek alın ve yedek yolunu not edin:
FSTAB_BACKUP="/etc/fstab.before-swap-$(date +%Y%m%d-%H%M%S)"
sudo cp --archive --no-clobber -- /etc/fstab "$FSTAB_BACKUP" &&
sudo cmp -- /etc/fstab "$FSTAB_BACKUP" &&
printf 'Backup: %s\n' "$FSTAB_BACKUP"
Yedekleme veya karşılaştırma hatası varsa devam etmeyin. cmp, dosyalar aynıysa çıktı üretmez; son Backup: satırı bu iki kontrol başarılı olunca görünür. Yedek yolunu not ettikten sonra dosyayı açın:
sudoedit /etc/fstab
Dosya içine yalnız kendi swap dosyanızın kaydı henüz yoksa aşağıdaki satırı ekleyip kaydedin. /swap-dchost-demo bu rehberdeki örnek yoldur:
/swap-dchost-demo none swap sw 0 0
Ardından dosyanın okunabilirliğini ve kayıtları doğrulayın:
sudo findmnt --verify --verbose && sudo systemctl daemon-reload
findmnt --fstab --types swap --output SOURCE,TARGET,FSTYPE,OPTIONS
swapon --show=NAME,TYPE,SIZE,USED,PRIO
Hata varsa yeniden başlatmayın; eklediğiniz satırı düzeltin veya yalnız bu değişikliği geri alın ve kontrolü tekrarlayın. Önceden var olan bir uyarıyı kendi eklediğiniz kaydın hatasıyla karıştırmayın. daemon-reload, systemd'nin yapılandırmayı yeniden okumasını sağlar; sunucuyu veya uygulama servislerini yeniden başlatmaz.
fstab satırının doğru dosyayı gösterdiğini ve systemd tarafından okunduğunu kontrol ediyoruz.
1. adım: fstab satırını doğru dosyayla eşleştirin
- fstab satırını doğru dosyayla eşleştirin
SOURCE alanı /swap-dchost-demo dosyasını, FSTYPE ise swap türünü gösteriyor. Kendi dosyanızın yoluyla eşleştiğinden emin olun.
- systemd biriminin kaynağını kontrol edin
LoadState=loaded, ActiveState=active ve SourcePath=/etc/fstab birlikte görülüyor. Bunlar mevcut oturum kontrolüdür; yeniden açılışın başarıyla denendiği anlamına gelmez.
Bu kayıtta normal dosya biçimindeki swap alanı için bir findmnt uyarısı var; metindeki açıklamayı okuyun. Yeniden başlatma testi yapılmadı.
Gerçek demoda önce /etc/fstab yedeği ve içeriği doğrulandı; ardından yalnız /swap-dchost-demo none swap sw 0 0 satırı eklendi. Var olan disk kayıtları korundu.
Ekrandaki bir uyarı neden var? Bu Ubuntu sistemindeki findmnt 2.39.3, 0 parse errors, 0 errors, 1 warning bildirdi. Tek uyarı, non-bind mount source /swap-dchost-demo is a directory or regular file idi. Bu sürümün genel kaynak kontrolü, normal dosya olan geçerli swap alanında da bu uyarıyı üretebilir. Bu nedenle yalnız çıkış koduna bakmadık; doğru swap kaydı ve gerçek etkinleşme ayrıca kontrol edildi. Farklı uyarı veya hata görürseniz aynı açıklamanın geçerli olduğunu varsaymayın.
Systemd'nin oluşturduğu swap birimini de salt okunur olarak kontrol edebilirsiniz:
SWAP_UNIT=$(systemd-escape --path --suffix=swap /swap-dchost-demo)
systemctl show "$SWAP_UNIT" --property=Id,LoadState,ActiveState,What,SourcePath
Demoda üretilen birim LoadState=loaded, ActiveState=active ve SourcePath=/etc/fstab gösterdi. swapon listesi de aynı dosyayı etkin gösteriyordu. Böylece kayıt dosyası, systemd birimi ve etkin swap alanı birlikte kontrol edildi.
Bu kontrolün sınırı: findmnt --verify ve etkin swap listesi, gerçek bir yeniden açılış denemesi değildir. Kalıcılığı uçtan uca doğrulamak için uygun bakım zamanındaki açılıştan sonra aynı dosyanın swapon --show çıktısında bulunduğunu tekrar kontrol edin. Sırf rehberi takip etmek için çalışan sunucuyu şimdi yeniden başlatmayın.
8. Swap dosyasını güvenle kaldırın
Swap kapatılırken oradaki bellek sayfalarının yeniden yerleştirilmesi gerekir. RAM zaten sıkışıkken swapoff çalıştırmayın. Önce yükü azaltın, ilgili swap alanının kullanılan miktarını ve kullanılabilir RAM'i kontrol edin:
swapon --show=NAME,SIZE,USED,PRIO --bytes
free -m
vmstat 1 5
Kullanılabilir RAM, kaldıracağınız swap'taki veriyi ve devam eden uygulamaların ihtiyacını rahatça karşılayabilmelidir. Bir anlık ölçüm bunun garantisi değildir. Yoğun kullanım varsa işlemi erteleyin veya uygun kapasiteyi sağlayın. swapoff -a kullanmayın; bu komut diğer swap alanlarını da kapatır.
Yalnız rehberdeki dosyayı devreden çıkarın:
sudo swapoff /swap-dchost-demo
swapon --show=NAME,TYPE,SIZE,USED,PRIO
swapoff başarısız olursa dosyayı silmeyin. Yetersiz bellek durumunda komut hata dönebilir; neden giderilmeden tekrar tekrar denemeyin. Başarılı olduğunda /swap-dchost-demo artık etkin listede bulunmamalıdır.
- Kalıcı kayıt eklediyseniz
sudoedit /etc/fstabile yalnız bu dosyaya ait satırı kaldırın; diğer swap ve disk kayıtlarını koruyun. sudo findmnt --verify --verboseile kontrol edin, ardındansudo systemctl daemon-reloadçalıştırın.- Dosya artık etkin değilse ve ona ait açılış kaydı da yoksa yalnız bu örnek dosyayı silin:
sudo rm -- /swap-dchost-demo
Kullanılabilir RAM ve swap kullanımı kontrol edildikten sonra yalnız demo swap alanı kapatıldı ve dosyası kaldırıldı.
1. adım: Swap alanının kapandığını doğrulayın
- Swap alanının kapandığını doğrulayın
swapon listesi boş ve free çıktısında Swap toplamı 0 B. Bu demoda başka etkin swap alanı yok.
- Dosyayı ve fstab sonucunu kontrol edin
Demo dosyası artık yok. İlgili fstab kaydı geri alındıktan sonra doğrulama da hata veya uyarı döndürmüyor.
swapoff başarılı olmadan dosyayı silmeyin. Kendi fstab dosyanızda yalnız kaldırdığınız swap alanına ait satırı değiştirin.
Eski yedeği bütün /etc/fstab dosyasının üzerine geri kopyalamak, sonradan yapılmış başka disk ayarlarını silebilir. Yalnız sizin eklediğiniz satırı kaldırmak çoğu durumda daha kontrollü geri almadır.
9. Sorun çözüldü mü? Aynı işlemi yeniden ölçün
Uygulamanın başarısız olan işlemini, işin kapsamına uygun biçimde yeniden deneyin. Gerçek web/veritabanı servisini sırf test için durdurmayın. Son kontrol yalnız “RAM yüzdesi düştü” olmamalıdır:
- İşlem beklenen sonucu üretiyor mu; uygulama veya hizmet yanıt veriyor mu?
- Aynı zaman aralığında yeni OOM ya da beklenmedik sonlandırma kaydı var mı?
- Benzer yük altında
available, uygulamanın bellek kullanımı vesi/sodeğerleri nasıl değişiyor? - Kalıcı swap kullanacaksanız dosya etkin mi, izin doğru mu, açılış kaydı doğrulandı mı?
Demo temizliğinin ardından RAM, disk, fstab ve SSH durumu yeniden kontrol edildi.
1. adım: RAM durumunu yeniden okuyun
- RAM durumunu yeniden okuyun
available değeri 1,6 GiB. Swap toplamı da 0 B; demo swap alanı artık etkin değil.
- SSH ve başarısız birimleri kontrol edin
SSH için active görülüyor. systemctl --failed listesi boş; bu kontrolde başarısız systemd birimi bulunmuyor.
Geçici test dosyaları ve servisler kaldırıldı; demo için eklenen fstab kaydı geri alındı. Bu ekran o andaki ölçümü gösterir.
Demo sonunda yalnız oluşturduğumuz swap alanı başarıyla kapatılıp dosyası kaldırıldı. /etc/fstab, başlangıçtaki içeriğiyle birebir doğrulanarak geri alındı; son kontrol hata veya uyarı bildirmedi. Test servisi, grubu ve yardımcı dosyaları da kaldırıldı.
Son ekranda 1,6 GiB kullanılabilir RAM, sıfır etkin swap, kök diskte %6 kullanım, etkin SSH ve sıfır başarısız systemd birimi görüldü. Bu, kontrollü demonun bitiş kontrolüdür; önceki OOM olayının günlükleri korunur. Kendi uygulamanız için asıl başarı ölçütü, sorun yaşanan işlemin benzer yük altında tamamlanmasıdır.
swappiness değerini değiştirmeli misiniz?
Mevcut değeri sysctl vm.swappiness ile okuyabilirsiniz. Bu ayar RAM'in yüzde kaçında swap başlayacağını söyleyen bir eşik değildir; çekirdeğin swap I/O'su ile dosya sayfalarını geri kazanma maliyetini değerlendirmesini etkiler. En uygun değer iş yüküne ve depolamaya bağlıdır. Her VPS için otomatik 10, 60 veya 0 yazmayın. Bu rehberde çözüm adına genel bir swappiness değişikliği yapılmaz.
Sık sorulan sorular
Linux RAM kullanımının yüksek görünmesi normal mi?
Dosya önbelleği nedeniyle yüksek görünmesi normal olabilir. available, uygulama gecikmesi ve olay anındaki kayıtları birlikte inceleyin. Yalnız free düşük diye önbelleği temizlemeyin; kapanan bir uygulama varsa kayıtları ayrıca kontrol edin.
VPS'te RAM boşken neden OOM hatası alıyorum?
Servis veya konteyner kendi MemoryMax sınırına ulaşmış olabilir. Üst grubun sınırı veya uygulamanın kendi bellek ayarı da etkili olabilir. Sunucudaki toplam boş RAM, her uygulamanın bu belleği kullanabileceği anlamına gelmez.
Ubuntu'da swap oluşturmak RAM yetersizliğini tamamen çözer mi?
Hayır. Swap bazı iş yüklerinde kısa süreli bellek artışlarına pay bırakır; sürekli yetersiz RAM'i veya bellek sızıntısını düzeltmez. Uygulamanın swap kullanımı engelliyse yeni alan o sınırı kaldırmaz. Yoğun swap hareketi de gecikmeye yol açabilir.
Killed veya 137 kesin OOM mu demektir?
Hayır. Aynı saatteki çekirdek, servis ve varsa systemd-oomd kayıtlarını eşleştirin. Elle gönderilen SIGKILL, başka bir yönetim aracı veya uygulamanın döndürdüğü kod da benzer görünüm oluşturabilir.
Swap kullanımını sıfırlamak için kapatıp açmalı mıyım?
Sırf sayaç sıfırlansın diye yapmayın. Swap'ta veri bulunması tek başına arıza değildir. RAM baskısı varken swapoff, durumu ağırlaştırabilir. Kullanımdaki değişimi ve uygulama gecikmesini izleyin.
RAM paketini ne zaman yükseltmeliyim?
Normal iş yükünde sürekli düşük kullanılabilir RAM, tekrarlayan OOM ve uygulama ayarları iyileştirildikten sonra devam eden bellek ihtiyacı varsa değerlendirin. Yeni pakette ihtiyacınız olan RAM'in arttığını doğrulayın; servis ya da konteyner sınırının ayrıca güncellenmesi gerekebilir. Yükseltme hazırlığına bakın.
Destek talebine ne eklemeli?
DCHost müşteri portalından destek talebi açarken hizmet numarasını, saat dilimiyle olay zamanını, kapanan uygulamayı, son değişikliği ve aynı aralığa ait kısa kayıtları ekleyin. free, ilgili servis sınırları ve OOM kaydının çevresindeki birkaç satır incelemeyi kolaylaştırır. Parola, özel anahtar, oturum bilgisi veya tam yapılandırma dosyası paylaşmayın; herkese açık ekranlarda IP ve özel sunucu adlarını gizleyin.
RAM değerleri normale döndüğü hâlde sunucu yavaşsa yüksek CPU ve load average kontrolüne geçin. Yoğun bir yedekleme işi, işlemci kotası veya I/O beklemesi farklı bir inceleme gerektirir; swap eklemek bu durumların genel çözümü değildir.
Kaynaklar ve ilgili rehberler
- Linux çekirdeği: cgroup v2 bellek sınırları ve olayları
- Linux çekirdeği: süreç belleği, PSS ve MemAvailable
- Linux çekirdeği: swappiness ve drop_caches
- systemd: servis kaynak sınırları
- systemd: systemd-oomd
- util-linux: swapon ve swapoff kılavuzu
- util-linux: mkswap kılavuzu
- cPanel: Ubuntu sistem gereksinimleri
- Linux disk doluluğu çözümü
- Sunucu güncellemelerini planlama
- Sunucu yedekleme planı