MongoDB'de yavaş sorguları bulmanın yerleşik yolu database profiler'dır. db.setProfilingLevel(1, { slowms: 100 }) komutu, bağlı olduğunuz veritabanında 100 milisaniyeden uzun süren işlemleri system.profile koleksiyonuna kaydettirir; ardından bu koleksiyonu normal bir sorguyla inceler, şüpheli sorguyu explain() ile analiz edersiniz. Profiler varsayılan olarak kapalıdır ve açıkken performansı ve disk kullanımını etkiler.
Bu yazıda profiler seviyelerini, slowms, sampleRate ve filter seçeneklerini, ayarları mongod.conf dosyasında kalıcı hale getirmeyi, system.profile çıktısını okumayı ve profiler açık değilken yavaş işlemleri diagnostic logdan bulmayı MongoDB 9.0 belgelerine dayanarak anlatıyoruz. Yapılandırma dosyasının genel yapısı için mongod.conf yapılandırma yazısına bakabilirsiniz.
Profiler ne kaydeder?
Profiler, çalışan bir mongod üzerinde yürütülen veritabanı komutları hakkında ayrıntılı bilgi toplar; CRUD işlemlerinin yanı sıra yapılandırma ve yönetim komutları da buna dahildir. Topladığı her şeyi profillenen her veritabanındaki system.profile koleksiyonuna yazar. Bu koleksiyon varsayılan boyutu 1 megabayt olan bir capped koleksiyondur; belgelere göre bu boyut genellikle birkaç bin profil belgesi tutabilir ve dolduğunda en eski kayıtların yerine yenileri yazılır. Koleksiyon, o veritabanı için profiler açıldıktan sonra oluşturulur.
Belgelerin notuna göre profiler veriyi bir koleksiyona yazdığı için, aksi halde yalnızca okunan bir veritabanında bile bir miktar yazma etkinliği oluşturur. Ayrıca system.profile koleksiyonu üzerinde bir transaction içinden okuma dahil hiçbir işlem yapılamaz.
Profiler seviyeleri

| Seviye | mongod.conf karşılığı | Davranış |
|---|---|---|
| 0 | off | Profiler kapalı, veri toplamaz (varsayılan) |
| 1 | slowOp | slowms eşiğini aşan veya filtreye uyan işlemleri kaydeder |
| 2 | all | Bütün işlemleri kaydeder; slowms ve filter değerlerini yok sayar |
Seviye 1 günlük kullanım için asıl seviyedir. Bu seviyede bir filter tanımlarsanız slowms ve sampleRate profilleme için kullanılmaz ve yalnızca filtreye uyan işlemler kaydedilir. Seviye 2 her işlemi yazdığı için belgeler bunun özellikle yüksek ek yük yarattığını belirtir; yalnızca kısa süreli hata ayıklamada ve geliştirme ortamında düşünülmelidir.
Profiler'ı açmak, ayarlamak ve kapatmak
Çalışma anında profiler mongosh yardımcısı db.setProfilingLevel(seviye, seçenekler) ile ayarlanır. Metot, önceki ayarları içeren bir belge döndürür; was alanı önceki seviyeyi, ok: 1 ise işlemin başarılı olduğunu gösterir. Belgelerdeki örneğe göre varsayılan ayarlı bir sunucuda dönüş aşağıdaki gibidir:
use magaza
// Seviye 1, 100 ms eşiği
db.setProfilingLevel( 1, { slowms: 100 } )
// çıktı: { was: 0, slowms: 100, sampleRate: 1, ok: 1 }
// Güncel durumu görmek
db.getProfilingStatus()
// İşiniz bitince kapatın
db.setProfilingLevel( 0 )İkinci parametre bir belge yerine sayı olarak verilirse slowms değeri kabul edilir; yani db.setProfilingLevel(1, 100) ile db.setProfilingLevel(1, { slowms: 100 }) aynı işi yapar. Kullanılabilecek seçenekler şunlardır:
slowms(varsayılan 100): Bir işlemin yavaş sayılacağı süre eşiği, milisaniye cinsinden. Belgelere göre yavaş işlemler, MongoDB'nin o işlem üzerinde gerçekten çalıştığı süre olanworkingMillisdeğerine göre belirlenir; kilit beklemek veya akış kontrolü gibi etkenler eşiği aşıp aşmamayı etkilemez.sampleRate(varsayılan 1.0): Yavaş işlemlerin ne kadarının kaydedileceği, 0 ile 1 arasında.0.42değeri yavaş işlemlerin rastgele yüzde 42'sinin profillenmesi demektir; değer sistem logu için de geçerlidir.filter: Hangi işlemlerin profilleneceğini ve loglanacağını belirleyen bir sorgu ifadesi; alanlar profiler çıktısındaki herhangi bir alan olabilir. MongoDB 8.0 ve sonrasındaworkingMillisda filtrede kullanılabilir. Filtreyi kaldırmak içinfilter: "unset"verilir.slowinprogms(MongoDB 8.3 ile, varsayılan 5000): Hâlâ sürmekte olan bir işlemin yavaş sayılacağı eşik; işlem bu süreyi aştığı anda yavaş süren işlem olarak loglanır.
// Yalnızca 2 saniyeden uzun süren sorgu işlemlerini kaydet
db.setProfilingLevel( 1, { filter: { op: "query", millis: { $gt: 2000 } } } )
// Yavaş işlemlerin yarısını örnekle, eşiği 50 ms yap
db.setProfilingLevel( 1, { slowms: 50, sampleRate: 0.5 } )
// Filtreyi kaldır
db.setProfilingLevel( 1, { filter: "unset" } )Global mi, veritabanı bazında mı?
Bu ayrım sık karıştırılır. Belgelere göre slowms ve sampleRate globaldir: setProfilingLevel() ile hangi veritabanında ayarlarsanız ayarlayın, sürecin bütün veritabanlarını etkiler. Profiler seviyesi ve filter ise komutla ayarlandığında veritabanı düzeyinde geçerlidir; komut satırı veya yapılandırma dosyası seçeneği olarak verildiklerinde bütün süreci etkiler. Profiler veritabanı bazında çalıştığı için birden çok veritabanını izlemek istiyorsanız komutu her birinde ayrı çalıştırmanız gerekir.
Ayarı kalıcı yapmak: mongod.conf
setProfilingLevel() ile yapılan değişiklikler kalıcı değildir. Sunucu yeniden başladığında seviye 0'a ya da yapılandırma dosyasındaki operationProfiling.mode veya komut satırındaki --profile değerine döner. Ayarın her açılışta geçerli olmasını istiyorsanız mongod.conf dosyasının operationProfiling bölümünü kullanın:
operationProfiling:
mode: slowOp
slowOpThresholdMs: 100
slowOpSampleRate: 1.0mode alanı off, slowOp veya all değerlerinden birini alır ve sırasıyla 0, 1 ve 2 seviyelerine karşılık gelir. Dosyaya bir filtre yazmak isterseniz belgelere göre filtre belgesini tek tırnak içinde, metin olarak vermeniz gerekir; dosyada tanımlanan filtre dağıtımdaki bütün veritabanlarına uygulanır, tek bir veritabanı için filtre ise setProfilingLevel() ile verilir.
operationProfiling:
mode: slowOp
filter: '{ op: "query", millis: { $gt: 2000 } }'Aynı ayarları geçici bir test sunucusunda komut satırından da verebilirsiniz. Belgelerdeki örnek, seviye 1, 15 ms eşik ve yavaş işlemlerin yüzde 50'sini örnekleme ayarlarıyla başlatır:
mongod --profile 1 --slowms 15 --slowOpSampleRate 0.5Değişikliği uyguladıktan sonra servisi yeniden başlatmanız gerekir; systemd ile servis yönetimi için systemd servis yönetimi yazısına bakabilirsiniz. MongoDB 5.0 ve sonrasında profile komutu veya setProfilingLevel() ile seviye, slowms, sampleRate ya da filter üzerinde yapılan değişiklikler log dosyasına da kaydedilir.
system.profile koleksiyonunu sorgulamak

Profiler verisi sıradan bir koleksiyonda durduğu için onu bildiğiniz sorgularla inceleyebilirsiniz. Belgelerdeki örnek sorgulardan uyarlanmış birkaç kalıp:
// En yeni 10 kayıt
db.system.profile.find().limit( 10 ).sort( { ts: -1 } )
// Komutlar dışındaki işlemler
db.system.profile.find( { op: { $ne: "command" } } )
// Belirli bir koleksiyon (veritabani.koleksiyon)
db.system.profile.find( { ns: "magaza.urunler" } )
// 5 ms'den uzun sürenler, en yavaş önce
db.system.profile.find( { millis: { $gt: 5 } } ).sort( { millis: -1 } )
// Belirli bir zaman aralığı, user alanı gizli
db.system.profile.find(
{ ts: { $gt: ISODate("2026-11-07T08:00:00Z"), $lt: ISODate("2026-11-07T09:00:00Z") } },
{ user: 0 }
).sort( { millis: -1 } )Hızlı bir bakış için mongosh'taki show profile yardımcısı, profilleme açık bir veritabanında en az 1 milisaniye süren en yeni beş işlemi gösterir.
Hangi alanlara bakmalı?
Profil belgesindeki alanlar işlem türüne göre değişir. Yavaş sorgu ararken en işe yarayanlar şunlardır:
| Alan | Anlamı |
|---|---|
| op | İşlem türü: query, insert, update, remove, getMore, command ve diğerleri |
| ns | veritabani.koleksiyon biçiminde ad alanı |
| command | Çalıştırılan komutun tam içeriği, filtre dahil |
| millis | mongod açısından işlemin başından sonuna geçen süre (ms) |
| keysExamined | Taranan index anahtarı sayısı |
| docsExamined | Taranan belge sayısı |
| nreturned | Döndürülen belge sayısı |
| planSummary | Yürütme planının özeti |
| hasSortStage | Sıralama index sırasından okunamayıp sonradan yapıldıysa true |
| usedDisk | Bir aggregation aşaması bellek sınırı yüzünden diske yazdıysa true |
| fromMultiPlanner, replanned | Planlayıcının birden çok planı değerlendirdiği veya önbellekteki planı atıp yeniden planladığı durumlar |
| ts | İşlemin zaman damgası |
Belgelerin "Find Slow Queries" eğitimi bu alanların nasıl yorumlanacağını açıkça sıralar. keysExamined sıfırsa sorgu index kullanmamıştır ve bir index oluşturmak gerekir. Index kullanılmış ama docsExamined değeri nreturned değerinden çok büyükse index etkisizdir; indexi güncellemek veya sorgu filtresindeki alanlar için yeni bir index oluşturmak gerekebilir. keysExamined yüksek, docsExamined düşükse index etkili kullanılıyordur. Aynı eğitimdeki örnek kayıtta bir yaş filtresi sıfır index anahtarı ve 100000 belge inceleyip 40 belge döndürmüş ve 143 ms sürmüştür; tipik bir eksik index belirtisi.
Aynı sorgu farklı değerlerle yüzlerce kez kaydedilmiş olabilir. Bunları gruplamak için profil belgelerindeki planCacheShapeHash alanından yararlanabilirsiniz: belgelere göre bu özet yalnızca sorgunun şekline bağlıdır ve aynı şekle sahip yavaş sorguları (yazma işlemlerinin filtreleri dahil) tanımlamaya yardım eder. planningTimeMicros alanı ise find veya aggregate komutunun planlamada geçirdiği süreyi mikrosaniye olarak verir; belgeler bazı eski sürümlerde bu değerin planlama dışı işleri de içerebildiğini, bu yüzden tek başına değerlendirilmemesi gerektiğini not eder. currentOp ile profiler, CRUD işlemleri için aynı temel teşhis bilgilerini raporlar; fark, currentOp'un o anda süren işlemleri, profiler'ın ise tamamlanmış işlemleri göstermesidir.
// Belgelerdeki eğitimden uyarlanmış: yalnızca teşhis alanları
db.system.profile.find(
{ },
{ command: 1, millis: 1, docsExamined: 1, keysExamined: 1, nreturned: 1, planSummary: 1 }
).sort( { ts: -1 } )Uçtan uca bir iş akışı
Profiler'ı bir teşhis aracı olarak kısa süreli kullanmak en sağlıklı yoldur. Belgelerdeki adımları birleştiren pratik bir sıra şöyle:
- 1. Eşiği belirleyin: Uygulamanız için "yavaş" ne demek, karar verin. Belgeler eğitimde 100 ms kullanır ama bunun uygulamaya göre değişmesi gerektiğini söyler.
- 2. Profiler'ı açın: İlgili veritabanında
db.setProfilingLevel(1, { slowms: 100 }). - 3. Trafiği bekleyin: Gerçek kullanımın yavaş sorguları üretmesine izin verin.
- 4. Kayıtları sorgulayın:
millisdeğerine göre sıralayıpkeysExamined,docsExaminedvenreturneddeğerlerine bakın. - 5. Explain ile doğrulayın:
commandalanındaki filtreyi alıpexplain("executionStats")ile çalıştırın. - 6. Indexi düzeltin: Eksik veya yanlış sıralı indexi ESR kuralına göre oluşturun.
- 7. Profiler'ı kapatın:
db.setProfilingLevel(0); belgeler işiniz bitince kapatmayı önerir.
Profiler kapalıyken: diagnostic log
Profiler kapalı (seviye 0) olsa bile slowms ve sampleRate değerleri diagnostic logu etkilemeye devam eder: eşiği aşan istemci işlemleri mongod loguna "Slow query" mesajıyla, işlemin tam komut nesnesiyle birlikte yazılır. Böylece system.profile koleksiyonuna yazma yükü olmadan yavaş işlemleri yakalayabilirsiniz. Filtreyi de seviye 0 ile tanımlayabilirsiniz; bu durumda profiler kaydı tutmaz ama filtre logu yönlendirir.
// Profiler kapalı, ama 50 ms üzeri işlemler loga yazılsın
db.setProfilingLevel( 0, { slowms: 50 } )MongoDB logları yapılandırılmış JSON biçimindedir ve belgeler bunları incelemek için açık kaynaklı jq aracını önerir. Belgelerdeki örnek, 2000 milisaniyenin üzerindeki yavaş işlemleri şöyle süzer:
jq 'select(.attr.workingMillis>=2000)' /var/log/mongodb/mongod.logBu yöntem özellikle sharded cluster'da işe yarar: profiler mongos üzerinde açılamaz, çünkü mongos'un profil verisini yazabileceği bir koleksiyonu yoktur. mongos için setProfilingLevel() yalnızca seviye 0 ile kullanılabilir ve slowms, sampleRate ile filter yalnızca diagnostic logu yapılandırır. Sharded bir kümede profilleme için her mongod üzerinde ayrı ayrı açmanız gerekir. Log dosyasının yeri ve ayarları için mongod.conf, sunucunun genel izlenmesi için production notları yazısına bakabilirsiniz.
Ek yük, disk ve güvenlik
Belgeler profiler hakkında üç ayrı risk sıralar. Performans: özellikle seviye 2'de ya da seviye 1'de çok düşük bir eşikle profilleme veritabanı performansını etkiler. Disk: profiler hem system.profile koleksiyonuna hem de log dosyasına yazdığı için disk alanı kullanır. Güvenlik: profiler ve log, sorgu verisini şifrelenmemiş olarak açığa çıkarabilir; örneğin bir filtredeki e-posta veya telefon numarası profil belgesinin command alanında görünür. Bu yüzden belgeler profiler'ı üretimde açmadan önce performans, depolama ve güvenlik etkilerini değerlendirmenizi ister ve alternatif olarak $queryStats aggregation aşamasını da listeler.
system.profile koleksiyonuna erişimi de kimlik doğrulama ve rollerle sınırlamak gerekir; kullanıcı ve rol yönetimi için kullanıcı ve rol yönetimi yazısına bakın.
system.profile boyutunu değiştirmek
1 megabaytlık varsayılan boyut yoğun bir sistemde kısa bir zaman aralığını kapsayabilir. Primary üzerinde boyutu değiştirmek için profiler'ı kapatır, koleksiyonu siler, istediğiniz boyutta capped koleksiyon olarak yeniden oluşturur ve profiler'ı tekrar açarsınız. Belgelerdeki örnek 4 MB içindir:
db.setProfilingLevel( 0 )
db.system.profile.drop()
db.createCollection( "system.profile", { capped: true, size: 4000000 } )
db.setProfilingLevel( 1 )Bir secondary üzerinde aynı işlem için belgeler, üyeyi durdurup standalone olarak başlatmayı, adımları uygulamayı ve ardından replica set üyesi olarak yeniden başlatmayı söyler.
Sık yapılan hatalar

- Profiler'ı seviye 2'de açık bırakmak: Her işlem yazılır; kısa süreli teşhis dışında kullanmayın.
- slowms değerinin yalnızca bir veritabanını etkilediğini sanmak: Eşik globaldir ve logu da etkiler.
- Ayarın yeniden başlatmada korunacağını varsaymak: Kalıcılık için
mongod.confkullanın. - mongos üzerinde profiler açmaya çalışmak: Desteklenmez; her shard
mongod'unda açın veya logu kullanın. - Filtre varken slowms'in hâlâ işlediğini düşünmek: Filtre tanımlıyken
slowmsvesampleRatedevre dışıdır. - Profil verisindeki hassas bilgiyi unutmak: Komut içerikleri şifrelenmeden saklanır.
Sık Sorulan Sorular
Profiler varsayılan olarak açık mı?
Hayır. Varsayılan seviye 0'dır ve profiler veri toplamaz. Ancak slowms varsayılanı olan 100 ms'yi aşan işlemler yine de diagnostic loga yazılır.
setProfilingLevel neden eski değerleri döndürüyor?
Metot tasarım gereği yeni değil önceki ayarları döndürür. Güncel durumu görmek için db.getProfilingStatus() kullanın.
Profiler ile explain arasındaki fark nedir?
Profiler, gerçek trafikte hangi işlemlerin yavaş olduğunu bulur; explain ise tek bir sorgunun neden yavaş olduğunu, hangi planla çalıştığını gösterir. İkisi birlikte kullanılır: önce profiler ile aday sorguyu bulur, sonra explain ile teşhis edersiniz.
Hangi slowms değerini seçmeliyim?
Belgeler sabit bir değer önermez; eşiğin uygulamanızın ve veritabanınızın ihtiyacını yansıtması gerektiğini söyler. Varsayılan 100 ms'dir; daha düşük değerler daha çok kayıt ve daha çok ek yük demektir.
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 · explain() ile sorgu planı · MongoDB index oluşturma · mongod.conf yapılandırma · Production notları ve performans · Compound index ve ESR kuralı