MongoDB Production Notları: Linux Sunucuda Performans ve Kararlılık Ayarları

Hızlı kontrol listesi

Paket, veri dizini ve antivirüs

Belgeler her zaman en son kararlı sürümü kullanmanızı ve küçük sürüm güncellemelerini takip etmenizi ister. Linux dağıtımlarının kendi depolarındaki mongodb paketi MongoDB tarafından bakımı yapılan paket değildir ve resmî paketlerle çakışır; resmî depodan kurulum yapmadan önce kaldırılmalıdır. mongod, storage.dbPath dizininde okuma ve yazma iznine sahip olmalıdır ve bu dizindeki dosyalar yapılandırılan depolama motoruna ait olmalıdır; başka bir motorla oluşturulmuş dosyalar varsa mongod başlamaz.

Sunucuda antivirüs veya EDR tarayıcısı çalışıyorsa veri dizinini ve log dizinini taramadan hariç tutun. Belgelere göre veri dosyaları zaten sıkıştırılmıştır, taramanın getirdiği G/Ç ve işlemci yükü güvenlik faydası olmadan performansı ciddi biçimde düşürebilir ve tarayıcı dosyaları karantinaya alırsa veritabanı bozulabilir.

Bellek ve WiredTiger önbelleği

WiredTiger iki katmanlı bellek kullanır: kendi iç önbelleği ve işletim sisteminin dosya sistemi önbelleği. Belgelere göre varsayılan iç önbellek boyutu şu iki değerden büyük olanıdır: (RAM - 1 GB) değerinin %50'si veya 0,256 GB. Örneğin toplam 4 GB RAM'i olan bir sistemde önbellek 0,5 x (4 GB - 1 GB) = 1,5 GB olur. Dosya sistemi önbelleği ise WiredTiger'ın ve diğer süreçlerin kullanmadığı tüm boş belleği otomatik olarak kullanır.

Belgeler iç önbelleği varsayılanın üzerine çıkarmaktan kaçınmanızı ister. Gerçekten gerekiyorsa dikey ölçeklemede bellek değişikliklerine uyum sağlaması için yüzde tabanlı storage.wiredTiger.engineConfig.cacheSizePct (komut satırında --wiredTigerCacheSizePct) önerilir; bu değer kullanılabilir belleğin en fazla %80'i olabilir ve hesaplanan sonuç 0,256 GB ile 10000 GB arasında kalmalıdır. Sabit bir değer vermek için storage.wiredTiger.engineConfig.cacheSizeGB ayarı vardır. Kapsayıcı (container) içinde çalışıyorsanız WiredTiger bazı durumlarda kapsayıcının bellek sınırını hesaba katmayabilir; belgeler WiredTiger'ın gördüğü bellek sınırını hostInfo komutuyla kontrol etmenizi ve gerekirse önbelleği uygun değere ayarlamanızı önerir.

storage:
  dbPath: /var/lib/mongodb
  wiredTiger:
    engineConfig:
      cacheSizeGB: 1.5

Önbellek ve tahliye (eviction) istatistikleri serverStatus komutunun wiredTiger.cache alanında bulunur. mongostat çıktısındaki used ve dirty sütunları da bu alandan hesaplanan önbellek doluluk yüzdeleridir.

MongoDB 9.0 ile bellek tarafında önemli bir değişiklik gelir: sürüm notlarına göre tek bir sorgu işleminin kullanabileceği toplam bellek artık sınırlıdır. Varsayılan sınır 1 gigabayt veya sunucu sürecinin kullanabildiği belleğin %20'si, hangisi büyükse odur. Sınırı aşan işlemler ExceededMemoryLimit (146) veya QueryExceededMemoryLimitNoDiskUseAllowed (292) hatasıyla başarısız olur; önceki sürümlerde bir işlem sınırsız bellek kullanabiliyordu. Aşama başına 100 MB sınırı ve diske taşma davranışı değişmemiştir. Sınır internalQueryMaxMemoryUsageBytesPerOperation parametresiyle ayarlanır. Ayrıntı için MongoDB 9.0 yenilikleri ve aggregation pipeline yazılarına bakın.

İşlemci

Belgeler her mongod veya mongos örneğinin en az iki gerçek çekirdeğe ya da bir çok çekirdekli fiziksel işlemciye erişmesini ister. WiredTiger çok iş parçacıklıdır: eşzamanlı aktif işlem sayısı işlemci sayısına kadar arttıkça verim artar, belirli bir eşiği aştıktan sonra düşer. Bu eşik uygulamaya göre değişir ve ölçerek bulunur; mongostat çıktısındaki ar|aw sütunu aktif okuma ve yazma sayısını gösterir. Şifreleme kullanıyorsanız AES-NI destekli işlemciler belirgin performans avantajı sağlar.

Disk ve dosya sistemi

Linux'ta üretim için XFS veya EXT4 önerilir; WiredTiger ile veri taşıyan düğümlerde EXT4'te görülebilen performans sorunlarından kaçınmak için XFS kuvvetle önerilir. Veri dosyalarının bulunduğu birimde atime kapatılmalı, yani dbPath bağlama noktası noatime ile bağlanmalıdır. MongoDB dizinler üzerinde fsync() destekleyen bir dosya sistemi ister; HGFS ve VirtualBox paylaşımlı klasörleri bunu desteklemez.

• SSD: MongoDB SATA SSD ile iyi sonuç ve fiyat performans oranı verir; mümkünse SSD kullanın.
• RAID: En iyi performans için RAID-10 önerilir; RAID-5 ve RAID-6 genellikle yeterli performans sağlamaz.
• NFS: dbPath için NFS sürücülerinden kaçının. Kullanmak zorundaysanız /etc/fstab içinde bg, hard, nolock, noatime ve nointr seçeneklerini ekleyin.
• Ayrı aygıtlar: Veri, journal ve loglar farklı aygıtlara ayrılabilir; ancak bu, anlık görüntü (snapshot) tarzı yedekleri zorlaştırır.
• Readahead: Ortam türünden bağımsız olarak 8 ile 32 arasında tutulmalıdır; MongoDB erişimi genellikle rastgele olduğu için yüksek değerler sınırlı fayda sağlar ve performansı düşürebilir.
• G/Ç zamanlayıcısı: Sanal makinelerde ve bulut disklerinde none, aynı sanal makinede birden çok iş yükü varsa kyber (Linux 4.12 ve sonrası), fiziksel sunucuda NVMe veya SSD için none, dönen disk için mq-deadline.

ulimit: açık dosya ve süreç sınırları

mongod ve mongos her gelen bağlantı için iki dosya tanımlayıcısı ve bir iş parçacığı kullanır; ayrıca her veri ve journal dosyası için birer dosya tanımlayıcısı tutar. Bu yüzden düşük ulimit değerleri yoğun yükte bağlantı hatalarına ve hizmet kaybına yol açabilir. Belgelere göre düşük bir "soft" sınır, bağlantı sayısı yükseldiğinde can't create new thread, closing connection hatalarına neden olabilir ve açık dosya sınırı 64000'in altındaysa MongoDB başlangıçta uyarı üretir.

MongoDB'yi systemd servisi olarak çalıştırıyorsanız sınırları servis dosyasının [Service] bölümünde kaynak sınırı yönergeleriyle verirsiniz; her yönerge hem hard hem soft sınırı aynı değere ayarlar. Belgeler mongod'u genellikle systemctl ile başlatmanızı önerir; elle mongod --config ~/mongod.conf gibi başlatırsanız kullanıcının systemd dilimindeki sınırlar geçerli olur.

[Service]
LimitFSIZE=infinity
LimitCPU=infinity
LimitAS=infinity
LimitMEMLOCK=infinity
LimitNOFILE=64000
LimitNPROC=64000

Değişiklikten sonra süreci yeniden başlatmanız gerekir; aksi halde yeni sınırlar uygulanmaz. Çalışan bir sürecin geçerli sınırlarını Linux'ta /proc dosya sistemi üzerinden görebilirsiniz. Aynı kullanıcı altında birden çok mongod çalışıyorsa değerleri buna göre ölçekleyin. Servis dosyalarını düzenleme ve systemctl daemon-reload gibi temel işlemler için systemd servis yönetimi yazısına bakabilirsiniz.

Transparent Hugepages (THP)

THP, küçük bellek sayfalarını birleştirerek uygulamaya daha büyük sayfalar gibi sunan ve TLB aramalarının yükünü azaltan bir Linux bellek yönetimi özelliğidir. Bu konudaki öneri sürüme göre tersine döner: MongoDB 8.0 ve sonrası, güncellenmiş TCMalloc sürümünü kullanmak için THP'nin açık olmasını ister; 7.0 ve öncesi için ise THP kapatılmalıdır. Güncellenmiş TCMalloc yalnızca x86_64 ve ARM64 mimarilerinde kullanılır; PPC64LE ve s390x üzerinde eski TCMalloc kullanıldığı için bu mimarilerde THP kapatılmalıdır. THP sistem düzeyinde çalışır, süreç bazında açılıp kapatılamaz.

Belgeler THP'nin mongod başlamadan önce açılması için bir systemd birimi oluşturmanızı önerir. /etc/systemd/system/enable-transparent-huge-pages.service dosyası şöyledir:

[Unit]
Description=Enable Transparent Hugepages (THP)
DefaultDependencies=no
After=sysinit.target local-fs.target
Before=mongod.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo always | tee /sys/kernel/mm/transparent_hugepage/enabled > /dev/null && echo defer+madvise | tee /sys/kernel/mm/transparent_hugepage/defrag > /dev/null && echo 0 | tee /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none > /dev/null && echo 1 | tee /proc/sys/vm/overcommit_memory > /dev/null'

[Install]
WantedBy=basic.target

sudo systemctl daemon-reload
sudo systemctl start enable-transparent-huge-pages
sudo systemctl enable enable-transparent-huge-pages
cat /sys/kernel/mm/transparent_hugepage/enabled && cat /sys/kernel/mm/transparent_hugepage/defrag && cat /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none && cat /proc/sys/vm/overcommit_memory

Belgelere göre son komutun çıktısı sırasıyla always, defer+madvise, 0 ve 1 değerlerine benzemelidir. Belgeler ayrıca güncel TCMalloc'un CPU başına önbellekleri kullanabilmesi için Linux çekirdeğinin 4.18 veya üstü olmasını ve gerekirse mongod başlamadan önce GLIBC_TUNABLES=glibc.pthread.rseq=0 ortam değişkeniyle glibc rseq kaydının kapatılmasını anlatır; bunun durumu serverStatus içindeki tcmalloc.usingPerCPUCaches alanından doğrulanır.

Swap ve vm.swappiness

MongoDB, swap'tan kaçınılan veya en aza indirildiği sistemlerde en iyi performansı verir; ancak bellek biterse swap, Linux OOM Killer'ın mongod'u sonlandırmasını önleyebilir. Belgeler iki strateji önerir: ya swap alanı ayırıp çekirdeğin yalnızca yüksek bellek baskısında swap yapmasına izin vermek ya da swap ayırmayıp tamamen kapatmak. vm.swappiness değeri 0 swap'ı tamamen kapatır, 1 yalnızca bellek yetersizliğini önlemek için izin verir; birçok dağıtımda varsayılan 60'tır. Aynı sunucuda web sunucusu gibi başka yazılımlar da çalışıyorsa swap'ı kapatmayın ve değeri 1 yapın.

Geçerli değeri cat /proc/sys/vm/swappiness ile görürsünüz. Değiştirmek için belgelerin yolu, /etc/sysctl.conf dosyasına aşağıdaki satırı eklemek ve ayarı sudo sysctl -p ile uygulamaktır. RHEL ve CentOS'ta tuned profili kullanıyorsanız aynı değeri profilde de ayarlamanız gerekir.

vm.swappiness = 1

sudo sysctl -p

Çekirdek ve ağ ayarları

İşlem kontrol listesi büyük sistemler için şu çekirdek değerlerini başlangıç noktası olarak verir: fs.file-max 98000, kernel.pid_max 64000, kernel.threads-max 64000 ve vm.max_map_count 131060. TCP tarafında, keepalive değeri bulut sağlayıcınızın yük dengeleyicisindeki boşta kalma zaman aşımından büyükse bağlantılar sessizce düşebilir; belgeler tcp_keepalive_time değerini 120 yapmanızı önerir ve 300 saniyeden büyük değerlerin MongoDB soketlerinde 300'e çekildiğini belirtir. Uzun duraksamaların ardından ağ zaman aşımları görüyorsanız net.ipv4.tcp_retries2 değerini 5 veya daha düşük yapmanız önerilir. Keepalive değişikliklerinin geçerli olması için mongod yeniden başlatılmalıdır.

sysctl net.ipv4.tcp_keepalive_time
sudo sysctl -w net.ipv4.tcp_keepalive_time=120

Kalıcı yapmak için aynı değeri /etc/sysctl.conf dosyasına net.ipv4.tcp_keepalive_time = 120 olarak ekleyin. Saat eşitlemesi de zorunlu sayılmalıdır: bileşenler arasında saat kayması, zamana bağlı işlemlerde hatalı davranış olasılığını artırır ve özellikle sharded cluster'larda önemlidir. NUMA donanımında MongoDB çalıştırmak uzun süreli yavaşlık ve yüksek sistem süreci kullanımına yol açabileceği için NUMA'nın BIOS'ta kapatılması önerilir; bu mümkün değilse vm.zone_reclaim_mode değeri 0 yapılıp mongod düğüm aralamalı (interleave) çalıştırılmalıdır.

Bağlantılar ve ağ ortamı

Production notları MongoDB'yi her zaman bilinmeyen tüm sistemlerden erişimi engelleyen güvenilir bir ağda çalıştırmanızı ve varsayılan olarak yetkilendirmenin kapalı geldiğini hatırlatır; bu konu authentication ve güvenlik kontrol listesi yazılarında ele alınıyor. Bağlantı kaynaklarını aşırı yüklememek için sürücü bağlantı havuzunu tipik eşzamanlı istek sayısının %110 ile %115'i civarından başlatıp ihtiyaca göre ayarlamanız önerilir. Sunucunun kabul edeceği eşzamanlı bağlantı sayısını sınırlamak için net.maxIncomingConnections ayarı kullanılır.

Dayanıklılık: journal, replica set ve yazma onayı

MongoDB, çökme veya ciddi bir arıza durumunda journal'a yazılmış ama veri dosyalarına henüz işlenmemiş yazmaları kurtarmak için diske yazılan bir journal (write ahead logging) kullanır. İşlem kontrol listesi tüm örneklerin journal kullanmasını, replica set'in en az üç oy veren ve veri taşıyan üyeden oluşmasını ve yazmaların w: majority yazma onayıyla yapılmasını ister. Üyelerin RAM, işlemci, disk ve ağ açısından eşit donatılması, üyeler arasında çift yönlü ağ bağlantısı olması ve IP adresi yerine ana makine adı kullanılması da öneriler arasındadır. Ayrıntılar için replica set kurulumu ve write concern ve read concern yazılarına bakın.

İzleme: mongostat ve mongotop

mongostat, çalışan bir mongod veya mongos'un durumuna hızlı bir bakış sunar ve işlevsel olarak vmstat'a benzer. Son argüman saniye cinsinden sorgulama aralığıdır (varsayılan 1); 1'den büyük bir değer verirseniz değerler saniye başına ortalamaya çevrilir. --rowcount (-n) satır sayısını sınırlar. Erişim denetimi açıksa kullanıcının küme kaynağında serverStatus eylemine sahip olması gerekir; yerleşik clusterMonitor rolü bunu sağlar.

mongostat --rowcount=20 1
mongostat -n=12 300
mongostat --uri="mongodb://izleyici@localhost:27017/?authSource=admin" 5

mongotop ise mongod'un okuma ve yazma işlerine koleksiyon başına ne kadar zaman harcadığını milisaniye cinsinden gösterir ve varsayılan olarak her saniye değer döndürür; yalnızca son zamanlarda etkinlik olan ad alanlarını listeler. Kimlik doğrulamalı sunucuda kullanıcının serverStatus ve top ayrıcalıklarına ihtiyacı vardır; clusterMonitor rolü bunları da sağlar.

mongotop
mongotop 30

Bu iki araç anlık bakış içindir. Belgeler kalıcı izleme için Cloud Manager, Ops Manager ya da başka bir izleme sistemiyle temel ölçümlerin izlenmesini ve alarm kurulmasını önerir. Yavaş sorguları ayrıntılı incelemek için yavaş sorgu profiler ve explain yazılarına bakabilirsiniz.

Yedek ve geri yükleme provası

İşlem kontrol listesinin yedekleme maddesi kısadır ama önemlidir: yedekleme ve geri yükleme sürecinizi düzenli aralıklarla test edin; böylece hem geri yüklemenin ne kadar süreceğini bilirsiniz hem de sürecin çalıştığını doğrularsınız. Araçlar için mongodump ve mongorestore yazısına bakın.

Sık yapılan hatalar

• Eski bir rehbere bakıp THP'yi kapatmak: Bu öneri 7.0 ve öncesi içindir; 8.0 ve sonrasında x86_64 ve ARM64 üzerinde THP açık olmalıdır.
• WiredTiger önbelleğini RAM'in çoğuna çıkarmak: Dosya sistemi önbelleği ve diğer süreçler için bellek kalmaz; belgeler varsayılanın üzerine çıkmamayı önerir.
• ulimit'i yalnızca oturumda değiştirmek: Servis olarak çalışan mongod için sınırlar systemd servis dosyasında verilmelidir ve süreç yeniden başlatılmalıdır.
• MongoDB ile web sunucusunu aynı makinede çalıştırırken swap'ı kapatmak: Bu durumda belgeler swap'ın açık kalmasını ve vm.swappiness değerinin 1 olmasını önerir.
• Veri dizinini NFS'e koymak: Performans düşebilir ve kararsızlaşabilir.
• Saat eşitlemeyi atlamak: Replica set ve sharded cluster'da zamana bağlı işlemler tutarsız davranabilir.

Sık Sorulan Sorular

Küçük bir VPS'te MongoDB çalıştırmak için en az ne kadar RAM gerekir?

Belgeler sabit bir RAM alt sınırı vermez; işlemci için en az iki çekirdek ister ve önbelleğin varsayılan olarak (RAM - 1 GB) değerinin yarısı kadar, en az 0,256 GB olacağını söyler. Gerçek ihtiyaç veri ve indekslerin çalışma kümesine bağlıdır; belgeler belleğin artırılmasının G/Ç verimini artırmada etkili olabileceğini de not eder.

Production notlarındaki her ayarı uygulamak zorunda mıyım?

Hayır; bunlar öneridir ve bazıları donanımınıza (NUMA, RAID, disk türü) bağlıdır. Ancak ulimit, THP, swap, dosya sistemi ve saat eşitlemesi neredeyse her Linux kurulumunu ilgilendirir.

mongostat ile mongotop arasındaki fark nedir?

mongostat sunucu genelindeki işlem sayılarını, kuyrukları, önbellek ve bağlantı durumunu verir. mongotop ise zamanın hangi koleksiyonlarda okuma ve yazmaya harcandığını gösterir. Biri "ne kadar yük var", diğeri "yük nerede" sorusuna cevap verir.

Sunucu bağlantıları reddediyor; nereden başlamalıyım?

Önce ulimit ve net.maxIncomingConnections sınırlarını, ardından ağ ve kimlik doğrulama ayarlarını kontrol edin. Adım adım teşhis için MongoDB bağlantı hataları yazısına bakın.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MongoDB öğrenme rehberi · mongod.conf yapılandırması · MongoDB güvenlik kontrol listesi · MongoDB yavaş sorgu profiler · MongoDB replica set kurulumu · Linux sunucu yönetimi temelleri · systemd servis yönetimi