MongoDB'de çok fazla kesici uç varsa ne olur? Tüm verilerin depolandığından nasıl emin olunur?

MongoDB'yi periyodik olarak ölçülen değerleri saklamak için kullanıyorum. Her ~ 100 msn'de bir demet değer belge olarak eklenir. İyi çalışıyor, ancak performans sorunları hakkında endişeliyim. (Güvenli ekler kullanıyorum, PyMongo'da sanki varsayılan bu gibi görünüyor.)

Mongod'un sabit diske kaydedebildiğinden saniyede daha fazla kesici uç varsa ne olur? Herhangi bir uyarı olacak mı ya da sessizce başarısız mı olacak?

Yazma yükünü izlemek için herhangi bir yöntem var mı? Sadece aradığımda db.serverStatus().writeBacksQueuedher zaman false olarak ayarlanmış olduğunu buldum. Yazma sırasını doldurmak için ne kadar veri girmem gerektiğini nasıl test edebilirim?

mongostatkilitleri gösterir. Endişelenmem gereken bir şey mi var?

insert  query update delete getmore command flushes mapped  vsize    res faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
  *117     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:6.5%          0       0|0     0|0   124b     6k     2  SLV   09:58:10 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:0.8%          0       0|0     0|0   124b     6k     2  SLV   09:58:11 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:4.2%          0       0|0     0|0   124b     6k     2  SLV   09:58:1

Yazma kilitleri hakkında endişelenmeli miyim? Yazma kilitli bir süre zarfında eke ne olur? Daha sonra sıraya alınmış ve depolanmış mı?

Bir ana ve bir köle kullanarak basit bir çoğaltma kurulumunu düşünüyorum. İlk senkronizasyon veya bir resync işlemi veritabanlarını kilitler mi?

(2.4.3 sürümünü kullanıyorum.)

Güncelleme: Sanırım kendi soruma kısmen cevap verdim. Küçük bir test dökümanı eklerken basit bir süre kullanarak saniyede 12.000 eklemeye başladım. Fakat qr | qw hala okuma ve yazma kuyruğunun hala boş olduğunu gösteriyor:

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
 11234     *0      2     *0    1563     1|0       1  21.9g  44.3g  1.22g      0    testdb:58.9%          0       1|0     1|1   797k   980k     6  PRI   10:26:32 
 12768     *0      2     *0    1284     1|0       0  21.9g  44.3g  1.22g      0    testdb:58.0%          0       0|0     0|1   881k     1m     6  PRI   10:26:33 
 12839     *0      2     *0    1231     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.3%          0       0|0     0|1   883k     1m     6  PRI   10:26:34 
 12701     *0      2     *0     910     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   858k     1m     6  PRI   10:26:35 
 12241     *0      2     *0    1206     1|0       0  21.9g  44.3g  1.22g      0    testdb:56.7%          0       0|0     0|0   843k     1m     6  PRI   10:26:36 
 11581     *0      2     *0    1406     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   811k     1m     6  PRI   10:26:37 
  8719     *0      2     *0    1210     1|0       0  21.9g  44.3g  1.22g      0    testdb:43.8%          0       0|0     0|1   618k   762k     6  PRI   10:26:38 
 11429     *0      2     *0    1469     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.6%          0       0|0     0|1   804k   993k     6  PRI   10:26:39 
 12779     *0      2     *0    1092     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.2%          0       1|0     0|1   872k     1m     6  PRI   10:26:40 
 12757     *0      2     *0     436     1|0       0  21.9g  44.3g  1.22g      0    testdb:59.7%          0       0|0     0|1   838k   432k     6  PRI   10:26:41 

Sanırım bu, eklerin tek başına çok fazla sıkıntıya neden olmayacağı anlamına geliyor: “Büyük aralıklı kaldırımlar gibi diğer yazma ağır operasyonlarının yanında çok fazla yazma işlemi yapıyorsanız sıralar yükselir”. ( burada bulundu ]

Açık sorum: Yazma kuyruğu uzun vadede artarsa ​​verilerime ne olur?

Burada bazı sorularınızı cevapladınız, özellikle denklemin yazma kilidi yönü hakkında iyi bir fikriniz var - 12.000 ekleme / sn ~% 60 yazma kilidine götürür. Tutarlı bir performans elde etmek için bu makul bir seviyedir - biraz çekişme yaşayacaksınız ve bazı operasyonlar biraz daha yavaş olacak, ama gerçekten% 80’de endişelenmeye başlamak isteyeceksiniz - mevcut olan% 80’i geçtiğinizde Kapasite, sorunları daha çok vurmaya başlayacaksınız.

Diğer darboğazlar ve özellikle diske ne kadar hızlı yazabildiğiniz konusunda - bu sorunlara yol açabilir, ancak zaman içinde ilgili istatistiklere bakmak için size donanım ve IO istatistiklerini vermek için munin-node eklentisi ile MMS kurmanızı tavsiye ederim . MongoDB istatistiklerine eklenir.

Buna sahip olduğunuzda, dikkat etmek isteyeceğiniz metrikler:

• Ortalama Yıkama süresi (MongoDB'nin periyodik senkronizasyonu diske ne kadar zaman alıyorsa)
• Donanım sekmesindeki IOStats (özellikle IOWait)
• Sayfa Hataları (diskiniz yazma ile meşgulse ve verileri okumanız gerekiyorsa, kıt bir kaynak için rekabet edeceklerdir)

O zaman biraz karışık, ama işte temel bir fikir:

• Ortalama yıkama süresi artmaya başladığında, endişelenmek
• Birden fazla ikinci aralığa girerse, muhtemelen sınırın üzerindesiniz (bu, yazılı veri hacmine ve disk hızına bağlı olmasına rağmen)
• 60 saniyeye yaklaşırsa performansın ciddi şekilde düşeceğini göreceksiniz (yıkama her 60 saniyede bir gerçekleşir, bu nedenle bunlar sıraya girer)
• Yüksek IOWait, özellikle herhangi bir noktada diskten okumak zorunda kalırsanız performansı da engelleyecektir
• Dolayısıyla sayfa arıza seviyelerine bakmak da önemli olacaktır.

Henüz bahsetmediğimiz bu yapbozun diğer parçası dergi. Bu, verileri diske de sürecek (varsayılan olarak her 100ms'de bir olacak) ve böylece aynı birimdeyse diskin yüküne eklenecek. Bu nedenle, yüksek disk kullanımı görüyorsanız, günlüğü başka bir diske çıkarmak iyi bir fikirdir.

Altında kalacak gerçek bir "sihirli sayı" yoktur, çoğu durumda hepsi görecelidir, bu nedenle normal trafiğiniz için iyi bir başlangıç ​​yapın, işlerin gidişat olup olmadığını kontrol edin ve sınırlarınızın ne olduğunu ve ne zaman olduğunu görmek için test uygulayın bozulmaya başladığınızda iyi durumda olacaksınız.

Tüm bu ön-amble'dan sonra, bazı sorularınız üzerine:

Mongod'un sabit diske kaydedebildiğinden saniyede daha fazla kesici uç varsa ne olur? Herhangi bir uyarı olacak mı ya da sessizce başarısız mı olacak?

Diski yukarıda açıklanan seviyelere zorlamaya başlarsanız, sonunda her şey yavaşlayacak ve bir noktada (ve bu zaman aşımına bağlı olacaktır, donanımınızın ne kadar becerikli olduğu, istisnaları nasıl idare edeceğinize bağlı olacaktır) yazmalarınız başarısız olacaktır - pymongo'nun yeni bir sürümünü kullanıyorsanız, varsayılan olarak güvenli yazma kullanıyor olacaksınız ve bunlar daha sonra başarısız olacaktır. Eğer biraz daha paranoyak olmak istiyorsanız, bazen j: true ile ilgili bir yazı yazabilirsiniz; Bu, elbette normal bir güvenli yazıma göre daha yavaş olacaktır, ancak disk kapasitesiyle ilgili sorunların hemen bir göstergesi olacak ve diğer işlemleri engellemek / sıraya koymak ve esasen veritabanınızın kullanılmasını önlemek için bir gaza benzemek için kullanabilirsiniz. boğulmuş.

Bir ana ve bir köle kullanarak basit bir çoğaltma kurulumunu düşünüyorum. İlk senkronizasyon veya bir resync işlemi veritabanlarını kilitler mi?

Başta genel olarak kilitlemeyi düşündüğümü düşünüyorum, ancak bu parçayı özel olarak cevaplamak için: İlk önce, ana / köle değil, bir kopya seti kullandığınızdan emin olun . Master / Slave uygulaması kullanımdan kaldırılmıştır ve genel olarak kullanılması önerilmez. İlk eşitleme gelince, birinciye okumalar açısından bir miktar yük ekleyecektir, ancak yazma açısından değil, bu yüzden kilitleme açısından iyi olmalısınız.

Yazma kuyruğu uzun vadede artarsa ​​verilerime ne olur?

Muhtemelen yukarıdaki açıklamadan anlayabileceğiniz gibi, cevap, başvurunuzu nasıl yazdığınıza, yazmalarınızın nasıl onaylanacağını ve ne kadar kapasiteye sahip olduğunuzu seçmenize bağlıdır. Esasen, MongoDB üzerinde diske yazmaya geldiğinde istediğiniz kadar güvenli olabilirsiniz, ancak j:trueyukarıdaki tartışmada belirtildiği gibi bir performans düşmesi var .

Genel olarak, sınırlama faktörünüzü bulmak istersiniz - kilitleme, disk hızı vb.

Sonuncusu db.serverStatus().writeBacksQueued, aslında sadece keskin bir ortamda hiç sıfır olmayan bir metriktir ve bir göç sırasında bir öbeğe yazma işlemlerinin uygun bir şekilde ele alındığından emin olmak zorundadır (yazı dinleyicisi tarafından işlenir ). Bu nedenle, esasen burada kırmızı bir ringa balığı - genel yazma hacmiyle ilgisi yok.