Mail Sunucusu için RAM, CPU ve Disk Gereksinimleri

Bir mail sunucusu kuracakken en zor cevaplanan soru şudur: kaç GB RAM, kaç çekirdek, ne kadar disk? İnternette bulacağın cevapların çoğu ya "2 GB yeter" gibi tehlikeli derecede iyimser ya da "16 GB alın" gibi gereksiz derecede savurgandır. Mail sunucusu kaynak gereksinimleri aslında kullanıcı sayısıyla doğrudan orantılı değildir; belirleyici olan hangi bileşenleri çalıştırdığın, günlük mesaj hacmin ve kaç kullanıcının aynı anda IMAP ile bağlı durduğudur. Yüz kullanıcılı bir kurum, spam taraması ve virüs taraması açıksa, bin kullanıcılı ama yalnızca aktarma yapan bir sunucudan daha fazla RAM ister.

Bu rehberde önce bir posta yığınında kaynağı kimin yediğini bileşen bileşen açacağım — çünkü doğru planlama, toplamı tahmin etmekle değil parçaları toplamakla yapılır. Sonra farklı ölçekler için somut RAM/CPU/disk tabloları vereceğim, disk tarafında kapasiteden çok daha önemli olan IOPS konusunu ele alacağım ve büyüme planlamasını anlatacağım. Sonunda da kaynak planlamasında en sık yapılan hataları toplayacağım; özellikle "disk ucuz, boldan alalım" diyip IOPS'u hesaba katmamak gibi, sunucu kurulduktan aylar sonra ortaya çıkan hataları.

Kaynağı Kim Tüketiyor#

Bir posta yığını tek bir program değildir; birlikte çalışan altı ayrı servisin toplamıdır ve her birinin karakteri farklıdır.

Bu tablonun en önemli satırı ClamAV'dir. Antivirüs, imza veritabanını tamamen belleğe yükler ve bu veritabanı sürekli büyür; küçük bir mail sunucusunda toplam RAM tüketiminin en büyük tek kalemi genellikle ClamAV olur. Yani "2 GB yeter" tavsiyesi, antivirüs kapalı bir kurulum varsayar. Açtığın anda o kurulum takılmaya başlar.

İkinci dikkat çekici satır Dovecot'un indeks davranışıdır. IMAP, kullanıcının klasörlerini hızlı listeleyebilmek için indeks dosyaları tutar ve bunlar disk önbelleğinde durduğunda çok hızlı, durmadığında acı verecek kadar yavaş çalışır. Yani RAM, Dovecot için sadece süreç belleği değil, aynı zamanda dosya sistemi önbelleğidir — bu yüzden "boşta duran RAM" bir mail sunucusunda israf değil, performansın ta kendisidir.

Kendi sunucunda hangi bileşenin ne yediğini görmek için:

# Bileşen bazında bellek kullanımı (RSS, MB)
ps -eo rss,comm --sort=-rss | awk 'NR>1 {a[$2]+=$1} END {for(c in a) printf "%-18s %8.1f MB\n", c, a[c]/1024}' | sort -k2 -rn | head -n 12

# Anlık genel durum
free -h

# Dosya sistemi önbelleği ne kadar yer kaplıyor
grep -E '^(Cached|Buffers|MemAvailable)' /proc/meminfo

Ölçeğe Göre RAM ve CPU Planlaması#

Aşağıdaki tablo, tam bir yığın (MTA + IMAP + spam filtresi + antivirüs + webmail) çalıştıran bir sunucu için başlangıç noktalarıdır. Rakamları mutlak doğru olarak değil, planlamanın alt sınırı olarak oku:

Son satır önemli bir ayrımı gösteriyor: yalnızca giden posta ileten bir SMTP sunucusu (uygulama bildirimleri, işlemsel postalar) çok daha az kaynak ister, çünkü ne posta kutusu tutar ne de gelen içeriği tarar. Bu tür bir kurulum için SMTP sunucu paketleri ölçek olarak yeterlidir; kurulum tarafında Node.js tabanlı hafif bir alternatif arıyorsan Haraka mail sunucusu yazısına bakabilirsin.

CPU tarafında mail sunucuları genellikle darboğaz yaşamaz — istisnası antivirüs taramasıdır. Büyük ekli mesajların yoğun geldiği bir sunucuda ClamAV taraması CPU'yu tek başına doyurabilir. İki basit önlem işe yarar: tarama boyutu sınırı koymak ve eşzamanlı tarama sayısını sınırlamak.

# /etc/clamav/clamd.conf - tarama sınırları
# Bu boyutun üstündeki dosyayı tarama (tarama süresi patlar)
MaxFileSize 30M
MaxScanSize 100M
# Aynı anda kaç bağlantı taranabilir
MaxThreads 6

# /etc/postfix/main.cf - eşzamanlı teslimat sınırı
# Aynı anda kaç teslimat süreci çalışsın
default_destination_concurrency_limit = 10
# Toplam süreç sayısını sınırla (RAM taşmasını önler)
default_process_limit = 60

default_process_limit özellikle kritiktir: varsayılan değerlerle bir posta patlaması sırasında Postfix onlarca süreç açar, her biri RAM tüketir ve sistem takas alanına düşer. Sunucunun RAM'ine göre bu sınırı bilinçli olarak belirlemek, ani yüklerde sunucunun ayakta kalmasını sağlar.

Disk Kapasitesi Nasıl Hesaplanır#

Disk planlamasında iyi haber şu: hesap oldukça basittir ve tahmin edilebilir. Formül:

Toplam disk = (kullanıcı sayısı × kullanıcı başına kota) + kuyruk payı + log payı + indeks payı + arşiv

Bu kalemleri tek tek düşünelim. Kullanıcı kotası en büyük kalemdir ve kotayı gerçekten uygulaman gerekir; kotasız bir sistemde tek bir kullanıcının kutusu diskin tamamını yiyebilir. Kuyruk payı normal koşullarda küçüktür ama bir teslimat sorununda hızla büyür, o yüzden en az birkaç GB ayır. Log payı, logrotate düzgün çalışıyorsa sınırlıdır. Dovecot indeksleri posta boyutunun küçük bir yüzdesi kadar yer kaplar ama dosya sayısı olarak çoktur.

Somut bir örnek yapalım: 50 kullanıcı, kullanıcı başına 5 GB kota.

# Kaba hesap
# 50 kullanıcı x 5 GB = 250 GB
# + kuyruk payı        =   5 GB
# + log payı           =   5 GB
# + indeks payı (~%5)  =  13 GB
# ------------------------------
# Toplam               = 273 GB  -> en az 400 GB disk al (%50 pay)

# Mevcut kullanımı ölçmek için
du -sh /var/vmail 2>/dev/null
du -sh /var/spool/postfix /var/log

# En çok yer kaplayan posta kutuları
du -sh /var/vmail/* 2>/dev/null | sort -rh | head -n 10

Üzerine %50 pay bırakmamı ciddiye al: posta kutuları hiçbir zaman küçülmez, sadece büyür ve disk %90'a geldiğinde büyütmek çoğu ortamda kesinti gerektirir. Arşivleme de yapıyorsan bu tamamen ayrı bir depolama kalemi olarak planlanmalı; hesaplama yaklaşımı için e-posta arşivleme ve saklama yazısına bak.

IOPS: Kapasiteden Daha Önemli Olan Metrik#

İşte kaynak planlamasının en çok gözden kaçan kısmı. Bir mail sunucusunun disk yükü, büyük dosya okuma/yazma değil, çok sayıda küçük rastgele erişimtir. Maildir biçiminde her mesaj ayrı bir dosyadır; bir kullanıcı klasörünü açtığında yüzlerce küçük dosya okunur, bir mesaj geldiğinde yeni bir dosya oluşturulur ve indeks güncellenir.

Bu iş yükü, dönen diskler (HDD) için en kötü senaryodur. Kapasitesi ne olursa olsun bir HDD saniyede sınırlı sayıda rastgele işlem yapabilir ve mail sunucusu bu sınırı kolayca doldurur. Sonuç, kullanıcıların "mail yavaş açılıyor" şikayeti ve giderek uzayan teslimat süreleridir.

Pratik kural: posta kutularının durduğu bölüm mutlaka SSD olmalı. Arşiv ve yedek gibi sıralı erişimli, seyrek okunan veriyi HDD'de tutmak sorun değildir ve maliyeti düşürür. Diskin gerçekten darboğaz olup olmadığını ölçmek için:

# Disk kullanımı ve bekleme süresi (%util yüksekse darboğaz var)
iostat -xz 2 5

# Hangi süreç disk bekliyor (D durumundakiler)
ps -eo state,pid,comm | awk '$1 ~ /D/ {print}'

# inode kullanımı - Maildir'de disk dolmadan inode biter
df -i /var/vmail

Son satır özellikle önemli: Maildir'de her mesaj bir dosya, yani bir inode demektir. Disk yüzdesi %40 görünürken inode'ların tükenmesi mümkündür ve bu durumda sunucu "yer yok" hatası verir. Dosya sistemini oluştururken mail bölümü için inode oranını bilinçli seçmek, sonradan düzeltilemeyen bir karardır.

Ağ, Bant Genişliği ve Ölçekleme#

Ağ tarafı genellikle darboğaz olmaz ama iki noktayı gözden kaçırma. Birincisi, bant genişliğinden çok eşzamanlı bağlantı sayısı önemlidir: yüz kullanıcı IMAP ile bağlıysa yüz açık soket vardır ve her biri süreç ya da iş parçacığı tüketir. Dovecot'ta bunu sınırla:

# /etc/dovecot/conf.d/10-master.conf
service imap-login {
  # Toplam eşzamanlı giriş süreci
  process_limit = 128
}
service imap {
  # Kullanıcı başına azami eşzamanlı oturum
  process_limit = 256
}

İkincisi, ek dosyalar. Ortalama mesaj boyutu küçük olsa da 20 MB'lık bir ek gönderen tek bir kullanıcı, o an tüm bağlantıyı doldurabilir. Aylık trafik tahminini yaparken ek payını yüksek tut; hesaplama için bant genişliği hesaplayıcı aracımızı kullanabilirsin.

Ölçekleme geldiğinde izlenecek sıra şudur ve bu sıraya uymak maliyeti düşürür:

1. Önce sınırları ayarla. default_process_limit, ClamAV tarama boyutu, Dovecot süreç sınırları — çoğu "yavaşlık" şikayeti donanım değil, ayar sorunudur.
2. RAM ekle. En ucuz ve en etkili adım; dosya sistemi önbelleği büyüdükçe disk yükü düşer.
3. Diski SSD'ye taşı. Hâlâ HDD'deysen buradan gelecek kazanç diğer her şeyden büyüktür.
4. Rolleri ayır. Veritabanını, webmail'i ve antivirüsü ayrı sunuculara böl.
5. Yatay ölçekle. Birden fazla MTA, paylaşımlı posta kutusu deposu — bu adım ciddi bir mimari iştir.

Çoğu kurulum ilk üç adımda çözülür. Rol ayırmaya geçmeden önce mutlaka ölç; hangi bileşenin darboğaz olduğunu bilmeden sunucu eklemek para harcamaktan başka işe yaramaz. Ölçüm kurulumu için mail sunucusu izleme yazısındaki metrikleri kullanabilirsin.

Sık Yapılan Hatalar#

En yaygın hata, antivirüsü hesaba katmadan RAM belirlemektir. "2 GB yeter" tavsiyesi ClamAV kapalıyken doğrudur; açtığın anda sunucu takas alanına düşer ve her şey yavaşlar. Tam yığın kuracaksan 4 GB mutlak alt sınırdır.

İkinci hata, HDD üzerinde posta kutusu barındırmaktır. Kapasite yeterli görünür ama rastgele erişim yükü diski doyurur; kullanıcılar "mail yavaş" der ve sen CPU grafiğine bakıp bir sorun bulamazsın. iostat -xz çıktısındaki %util değeri bunu anında gösterir.

Üçüncü hata, inode'u unutmaktır. Maildir'de her mesaj bir dosya olduğu için disk boşken inode bitebilir ve dosya sistemini yeniden oluşturmadan bunu düzeltmek mümkün değildir. Kurulum sırasında bilinçli karar ver.

Dördüncü hata, kota tanımlamamaktır. Kotasız bir sistemde tek bir kullanıcının kutusu tüm diski doldurabilir ve disk dolduğunda sunucu hiç kimseden posta kabul etmez. Beşinci hata, süreç sınırlarını varsayılan bırakmaktır: ani bir posta dalgasında MTA onlarca süreç açar, RAM tükenir ve sistem çöker. Altıncı hata ise büyüme payı bırakmamaktır; posta kutuları hiçbir zaman küçülmez ve %90 doluluğa gelmiş bir diski büyütmek genellikle kesinti gerektirir. Son olarak, kaynağı ölçmeden artırmak da yaygındır: darboğazın nerede olduğunu bilmeden RAM eklemek çoğu zaman hiçbir şeyi düzeltmez.

Sıkça Sorulan Sorular#

50 kullanıcılı bir mail sunucusu için ne kadar RAM gerekir#

Tam bir yığın (MTA, IMAP, spam filtresi, antivirüs, webmail) çalıştıracaksan 8 GB rahat bir başlangıçtır; 4 GB ile de çalışır ama antivirüs açıkken sıkışık kalırsın. Belirleyici olan kullanıcı sayısından çok hangi bileşenleri açtığındır: ClamAV kapalı, webmail yoksa 4 GB fazlasıyla yeterken, hepsi açıkken 8 GB makul alt sınır olur. RAM'i cömert tutmanın ek faydası, dosya sistemi önbelleğinin büyümesi ve disk yükünün düşmesidir.

Mail sunucusu için SSD şart mı#

Posta kutularının durduğu bölüm için pratikte şarttır. Mail iş yükü çok sayıda küçük rastgele okuma/yazmadan oluşur ve dönen diskler bu profilde çok düşük performans verir; kapasite yeterli olsa bile kullanıcılar belirgin yavaşlık yaşar. Arşiv ve yedek gibi sıralı erişimli veriyi HDD'de tutmak ise tamamen makuldür ve maliyeti düşürür.

Mail sunucusu ne kadar CPU kullanır#

Normal koşullarda çok az; MTA ve IMAP CPU açısından hafif servislerdir. CPU'yu asıl tüketen antivirüs taraması ve daha az ölçüde spam filtresidir. Büyük ekli mesajların yoğun geldiği bir sunucuda ClamAV tek başına CPU'yu doyurabilir; tarama boyutu sınırı ve eşzamanlı tarama sayısı ayarlarıyla bunu kontrol altına alırsın. İki ila dört çekirdek çoğu kurulum için yeterlidir.

Disk dolarsa ne olur#

MTA yeni posta kabul etmeyi bırakır ve gelen bağlantılara geçici hata döner; gönderen taraf daha sonra tekrar dener, yani mesajlar hemen kaybolmaz. Ancak kuyruktakiler de teslim edilemez ve IMAP tarafında yazma işlemleri hata vermeye başlar. Bunu önlemenin yolu kullanıcı kotası uygulamak, disk doluluğunu %85 eşiğiyle izlemek ve inode kullanımını ayrıca takip etmektir.

Antivirüs ve spam filtresi kapatılabilir mi#

Kapatabilirsin ama tavsiye etmem. Spam filtresi olmadan kutular kısa sürede kullanılamaz hale gelir; antivirüs olmadan ise zararlı ekler kullanıcıya doğrudan ulaşır. Kaynak sıkıntısı yaşıyorsan kapatmak yerine sınırlandır: antivirüste tarama boyutu sınırı koy, spam filtresinde bellekte tuttuğu sözlükleri ve eşzamanlılığı ayarla. Kaynak eklemek, korumayı kapatmaktan her zaman daha doğru bir çözümdür.

Kaynağı artırmadan önce neyi ölçmeliyim#

Üç şeyi sırayla ölç: free -h ile gerçekten RAM mi bitiyor yoksa önbellek mi büyük görünüyor, iostat -xz ile disk doygun mu (%util yüksek mi), ps -eo state ile süreçler disk bekliyor mu. Bu üç ölçüm darboğazın RAM'de mi diskte mi olduğunu net söyler. Ölçmeden RAM eklemek, sorun disktekiyse hiçbir şey değiştirmez ve boşa harcanan bir maliyet olur.

Kapanış#

Mail sunucusu kaynak planlaması, toplamı tahmin etmekle değil bileşenleri toplamakla yapılır. Aklında kalması gereken dört alışkanlık: RAM'i belirlerken antivirüsü hesaba kat, çünkü genellikle en büyük tek kalem odur; posta kutularını mutlaka SSD üzerinde tut ve arşivi ayrı bir depolamaya al; disk planlarken kapasitenin yanında inode sayısını ve IOPS'u da düşün; ve süreç sınırlarını varsayılan bırakma, ani yüklerde sunucuyu ayakta tutan şey odur. Her kullanıcıya kota tanımlamayı da ilk günden yap.

Doğru boyutta bir sunucu seçmek ya da mevcut kurulumunu büyütmek istiyorsan Clou.TR tarafında ölçeğine uygun seçenekler var. Küçük ve orta ölçekli kurulumlar için NVMe destekli VDS ve sanal sunucu paketlerimize, esnek büyüme isteyenler için bulut sunucu çözümlerimize bakabilirsin. Yalnızca giden posta altyapısı kuracaksan SMTP sunucu paketlerimiz, kurulum ve boyutlandırmayı bize bırakmak istersen sunucu yönetimi hizmetimiz uygun bir başlangıç noktası olur.