Kendi sunucunuzdaki testlerde MongoDB Community search index'i %89 disk kullanımının üzerinde PENDING'te takıldı

Ne yaşandı

MongoDB Search ve Vector Search'ün Community Edition sürümü 30 Haziran 2026'da genel kullanıma açıldı ve daha önce yalnızca Atlas'e özgü bir bileşen olan mongot search süreci, ayrı bir motor üzerinde değil mongod ile yan yana çalışan self-managed dağıtımlara geldi. dev.to'daki ayrıntılı bir yazı, MongoDB'nin Docker kurulum rehberinin harfiyen izlenmesini anlatıyor: mongod container'ı (Community Server 9.0.2) ve mongot-community container'ı (mongot 1.70.5), gRPC üzerinden bağlanmış; searchCoordinator rolüne sahip bir SCRAM kullanıcı, tek üyeli bir replica set ve 50.000 dokümanlık bir test koleksiyonuna karşı createSearchIndex. Index PENDING döndü ve bir daha o durumdan çıkmadı.

Gönderiye göre kısa bir PENDING aşaması normaldir. Beklenmeyen ise beş dakika sonra da durumun aynı olması; mongot geçici senkronizasyon hataları logluyor, her 30 saniyede bir yeniden deniyor ve ilk senkronizasyon duraklatılmış halde kalıyordu.

Yapımı durduran disk eşiği

Yazar, nedeni mongot'un 9946 portunda sunduğu Prometheus metriklerinde buldu: 270.6 GB'ın 28.7 GB'ı boş, yani %89.4 kullanımda. MongoDB'nin kendi self-managed sorun giderme sayfası, disk kullanımı kabaca %90'ı geçtiğinde replikasyonun durduğunu ve kabaca %85'in altına inince yeniden başladığını, ayrıca disk baskısı bu koruyucu çizgiyi zaten aşmışsa index tanımının kabul edileceğini ama yapımının bekletileceğini belirtiyor.

Teşhisi zorlaştıran bir ölçüm uyumsuzluğuydu. Aynı path üzerinde df -h %28 kullanım bildirdi, yaklaşık 60 puan daha düşük; çünkü df, kota sınırlı bir ayırma içinde ölçüm yaparken mongot, altta yatan cihazin bildirdiği tam kapasiteye bölüyordu. Blokajla ilgili hiçbir şey istemci tarafında görünmüyordu: createSearchIndex normal döndü ve $listSearchIndexes sadece PENDING raporladı.

Yazar, mongot'un veri dizinini yer açmak için tmpfs'e taşıdıktan sonra aynı index ilk senkronizasyonunu 4.85 saniyede tamamlayıp kararlı duruma geçti; bu da tek engelleyicinin disk boşluğu olduğunu doğruladı.

Durum alanları ve sessiz arıza biçimleri

Gönderi, operatörlerin bilmesi gereken iki raporlama sorunu belgeliyor. mongot container'ı yeniden oluşturulduktan sonra $listSearchIndexes, üzerindeki sorgular çalışsa bile index'i PENDING olarak raporlamaya devam etti. Toplanan üst düzey durum, artık var olmayanlar dahil kaydedilmiş her host'taki en kötü durumu yansıtıyor; bu yüzden host başına statusDetail dizisi güvenilir görünümdür.

Arıza davranışı da asimetrik. Var olan ama henüz hazır olmayan bir index'i sorgulamak NOT_STARTED durumu belirterek 8 kodlu sert bir OperationFailure fırlatıyor. Hiç var olmayan bir index adını sorgulamak ise sessizce sıfır sonuç döndürüyor ve yalnızca mongot'un kendi logunda bir uyarı satırı bırakıyor; yani yazım hatası yapılmış bir index adı ile gerçekten boş bir sonuç kümesi uygulama tarafından aynı görünüyor.

Performans ve maliyet bulguları

Index devreye girdikten sonra yazar, aynı koleksiyon üzerinde tek kelimelik ve iki kelimelik sorguların her birini 15 kez tekrarladı. mongot üzerinden $search 9.36ms medyan sundu; klasik bir $text index'i için 0.67ms, büyük-küçük harfe duyarsız bir regex taraması için 0.79ms ile karşılaştırıldığında düz terim aramalarında kabaca 10 ila 14 kat yavaştı; gönderi bunu gRPC gidiş-dönüşüne bağlıyor. Ayrı sürecin karşılığını verdiği yer bulanık eşleştirme: tek harflik bir yazım hatası olan "backpak" sorgusu, maxEdits 1 olarak ayarlandığında beş sonuç döndürürken $text, regex ve fuzzy olmayan $search hepsi sıfır döndürdü.

Vektörler tarafında, 32 boyutlu kosinüs benzerliği index'i üzerinde $vectorSearch 15.52ms medyanla çalıştı; tüm embedding'leri Python ile kaba kuvvetle taramanın 134.89ms'sine karşı yaklaşık 8.7 kat daha hızlıydı ve karşılaştırma kaba kuvvete cömertti, çünkü 50.000 vektörün tamamının aktarım katmanından çekilmesi hariç tutulmuştu.

Eşzamanlılık throughput'u artırdı ama kuyrukları kötüleştirdi: on istemci 20 sorguyu art arda 180.7ms'ye karşı duvar saatinde 98.6ms'de tamamladı; medyan gecikme 8.41ms'den 28.77ms'ye, en kötü durum ise 13.07ms'den 83.40ms'ye yükseldi. Boştayken mongot 1.033GiB resident tuttu, mongod'un 229.5MiB'sine karşı; küçük koleksiyonlar için küçülmeyen, JVM ölçeğinde bir ayak izine sahip ikinci bir süreç. $search sonrası $match, $project, $sort, searchScore metadata ve $limit zincirlemek özel bir işlem gerektirmeden çalıştı. Gönderi bir ölü sokağı da kaydediyor: yazar, tek düğümlü bir sette belgelenen secondaryPreferred okuma tercihinden şüphelenerek ikincil bir replica set üyesi ekledi ama index yine kımıldamadı.

Neden önemli

Yeni GA olan yığının kendi sunucusunda barındıran kullanıcıları, yalnızca mongod'a değil mongot'a yönelik izleme gerektiriyor. Kabaca %90'lık disk tavanı istemciden görünmez ve kota destekli mount'larda df gibi standart araçlar mongot'un kendi hesabıyla onlarca puan farklılık gösterebilir; dolayısıyla bir kapasite sorunu tam olarak bozuk bir özellik gibi görünür. Kapasite planlaması da önemli, çünkü search artık boşta mongod'un ayak izinin dört katından fazlasını kaplayan gigabayt ölçeğinde bir yardımcı süreç taşıyor. Özelliği yayına almadan önce pratik çıkarımlar şunlar: özet status yerine host başına statusDetail'i okumak ve mongot'un Prometheus metriklerini izlemek.