成都创新互联网站制作重庆分公司

关于mongodb的journal日志工作方式分析

1、journal目录结构
  1. [root@gog /backup/mongo/data/journal]#ll 
  2. total 3148816 
  3. -rw------- 1 root root 1073741824 May 23 19:54 j._2 
  4. -rw------- 1 root root         88 May 23 19:54 lsn 
  5. -rw------- 1 root root 1073741824 Mar 18 01:22 prealloc.1 
  6. -rw------- 1 root root 1073741824 Mar 18 01:22 prealloc.2 
 
j._2表示正在使用中的journal文件,当单个文件达到1GB的时候,就会创建一个新的文件,旧文件不会循环使用,自动删除。lsn保存最后使用的journal序列号,是个2进制文件,它实际保存的是系统启动到现在的一个时间戳。prealloc.2是还未使用的初始化的journal文件。使用db.shutdownServer()和kill -2关闭的系统,也就是clean shutdown,journal文件夹下除prealloc.*文件 都会被删除。 如果系统掉电或者运行时死机,再启动时,mongo就会使用journal进行恢复,不用运行repair。 
 
2、journal刷新频率
journal除了故障恢复的作用之外,还可以提高写入的性能,批量提交(batch-commit),journal一般默认100ms刷新一次,在这个过程中,所有的写入都可以一次提交,是单事务的,全部成功或者全部失败。
关于刷新时间,它是可以更改,范围是2-300ms,但是这并不是绝对的。MongoDB提供了journal延迟测试的函数,
 
  1. > db.runCommand("journalLatencyTest") 
  2.     "timeMillis" : { 
  3.         "8KB" : 19.74, 
  4.         "8KBWithPauses" : 20.31402, 
  5.         "1MB" : 25.2 
  6.     }, 
  7.     "timeMillisWithPrealloc" : { 
  8.         "8KB" : 4.13, 
  9.         "8KBWithPauses" : 4.51596, 
  10.         "1MB" : 11.4 
  11.     }, 
  12.     "onSamePartition" : true, 
  13.     "ok" : 1 
在实际运行中,刷新时间是--journalCommitInterval设置和延迟测试中较大的一个。
三、总结:
mongodb在启动时,专门初始化一个线程不断循环(除非应用crash掉),用于在一定时间周期内来从defer队列中获取要持久化的数据并写入到磁盘的journal(日志)和mongofile(数据)处,当然因为它不是在用户添加记录时就写到磁盘上,所以它不会造成性能上的损耗,当进行数据插入操作时,记录(Record类型)都被放入到defer队列中以供延时批量(groupcommit)提交写入,但相信其中时间周期参数是个要认真考量的参数,系统为100毫秒,如果该值更低的话,可能会造成频繁磁盘操作,过高又会造成系统宕机时数据丢失过多。
journal的刷新时间是可以改变的,2-300ms的范围,使用 --journalCommitInterval 命令
 
查看journal运行情况:
  1. "dur" : { 
  2.         "commits" : 25, 
  3.         "journaledMB" : 3.899392, 
  4.         "writeToDataFilesMB" : 38.269053, 
  5.         "compression" : 0.09879529488786379, 
  6.         "commitsInWriteLock" : 0, 
  7.         "earlyCommits" : 0, 
  8.         "timeMs" : { 
  9.             "dt" : 3131, 
  10.             "prepLogBuffer" : 47, 
  11.             "writeToJournal" : 349, 
  12.             "writeToDataFiles" : 43, 
  13.             "remapPrivateView" : 3 
  14.         } 
  15.     } 
commits:在journalCommitInterval时间内提交的操作数。 
journaledMB:在journalCommitInterval时间内写到journal文件中的数据量 。 
writeToDataFilesMB:在journalCommitInterval时间内从journal刷新到磁盘的数据量 。 
compression:v>2.0,表示客户端提交写入到journal的数据的压缩比率,注意,写入到journal的数据并不是全部的数据。( journaled_size_of_data / uncompressed_size_of_data ) 。 
commitsInWriteLock:在有写锁的情况下提交的数量,这表示写的压力很大。 
earlyCommits:表示在journalCommitInterval之前的时间,mongod请求提交的次数。用这个参数确定journalCommitInterval是不是设置的过长。 
dur.timeMS.prepLogBuffer:从privateView映射到Logbuffer的时间。
dur.timeMS.writeToJournal:从logbuffer刷新到journalfile 的时间。
dur.timeMS.writeToDataFiles:从journalbuffer映射到MMF,然后从MMF刷新到磁盘的时间,文件系统和磁盘会影响写入性能。 
dur.timeMS.remapPrivateView:重新映射数据到PrivateView的时间,越小性能越好
 
借鉴了http://www.cnblogs.com/daizhj/archive/2011/03/21/1990344.html这篇文章中对mongodb源码的分析部分
官方文档 http://docs.mongodb.org/manual/core/journaling/#journaling-internals

本文题目:关于mongodb的journal日志工作方式分析
转载来于:http://cxhlcq.com/article/ispsec.html

其他资讯

在线咨询

微信咨询

电话咨询

028-86922220(工作日)

18980820575(7×24)

提交需求

返回顶部