Shulou(Shulou.com)06/01 Report--

1. Journal directory structure [root@gog / backup/mongo/data/journal] # lltotal 3148816 RW-1 root root 1073741824 May 23 19:54 j.audio 2-rw- 1 root root 88 May 23 19:54 lsn-rw- 1 root root 1073741824 Mar 18 01:22 prealloc.1-rw- 1 root root 1073741824 Mar 18 01:22 prealloc.2 j.room2 indicates a journal file in use When a single file reaches 1GB, a new file is created, the old file is not recycled, and is automatically deleted. Lsn saves the last used journal serial number, which is a binary file, which actually saves a timestamp since the system was started. Prealloc.2 is an initialized journal file that has not yet been used. Systems that are shut down with db.shutdownServer () and kill-2, that is, prealloc.* files under the clean shutdown,journal folder, will be deleted. If the system loses power or crashes at runtime, mongo will recover using journal instead of running repair when it is rebooted. 2. Journal refresh frequency journal in addition to fault recovery, it can also improve the performance of writes. Batch commit (batch-commit). Journal generally defaults to 100ms refresh once. In this process, all writes can be committed at once, which is a single transaction, all successful or all failed. With regard to refresh time, it can be changed, with a range of 2-300ms, but this is not absolute. Mongodb provides functions for journal delay testing, > db.runCommand ("journalLatencyTest") {"timeMillis": {"8KB": 19.74," 8KBWithPauses ": 20.31402," 1MB ": 25.2}," timeMillisWithPrealloc ": {" 8KB ": 4.13," 8KBWithPauses": 4.51596, "1MB": 11.4}, "onSamePartition": true, "ok": 1} in actual operation Refresh time is the larger of the journalCommitInterval settings and latency tests. Summary: when mongodb starts, it initializes a thread that loops continuously (unless crash is applied), which is used to obtain persistent data from defer queue and write to disk journal (log) and mongofile (data) within a certain period of time. Of course, because it is not written to disk when the user adds records, it will not cause performance loss when data insertion operation is carried out. Records (Record type) are put into the defer queue for delay batch (groupcommit) to submit writes, but it is believed that the time period parameter is a parameter to be carefully considered, and the system is 100ms. If the value is lower, it may cause frequent disk operations, and too much data will be lost when the system is down. The refresh time of journal can be changed. 2-300ms range, use the-- journalCommitInterval command to check the journal operation: "dur": {"commits": 25, "journaledMB": 3.899392, "writeToDataFilesMB": 38.269053, "compression": 0.09879529488786379, "commitsInWriteLock": 0, "earlyCommits": 0, "timeMs": {"dt": 3131, "prepLogBuffer": 47, "writeToJournal": 349, "writeToDataFiles": 43 "remapPrivateView": 3}} commits: the number of operands submitted within journalCommitInterval time. JournaledMB: the amount of data written to the journal file in journalCommitInterval time. WriteToDataFilesMB: the amount of data flushed from journal to disk in journalCommitInterval time. Compression:v > 2.0 indicates the compression ratio of the data submitted by the client to write to journal. Note that the data written to journal is not all data. (journaled_size_of_data / uncompressed_size_of_data). CommitsInWriteLock: the number of commits with write locks, which means that writing is stressful. EarlyCommits: indicates the number of times mongod requests were submitted before journalCommitInterval. Use this parameter to determine if the journalCommitInterval is set too long. Dur.timeMS.prepLogBuffer: the time when the privateView was mapped to Logbuffer. Dur.timeMS.writeToJournal: time to refresh from logbuffer to journalfile. Dur.timeMS.writeToDataFiles: the time it takes to map from journalbuffer to MMF and then flush from MMF to disk, the file system and disk affect write performance. Dur.timeMS.remapPrivateView: the time it takes to remap data to PrivateView, the smaller the performance, the better. This article draws lessons from the analysis of mongodb source code in http://www.cnblogs.com/daizhj/archive/2011/03/21/1990344.html, part of the official document http://docs.mongodb.org/manual/core/journaling/#journaling-internals.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.