MongoDb Mmap引擎分析

版權聲明：本文由孔德雨原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/137

來源：騰雲閣 https://www.qcloud.com/community

 

MongoDB在3.0以前一直使用mmap引擎做爲默認存儲引擎，本篇從源碼角度對mmap引擎做分析，業界一直以來對10gen用mmap實現存儲引擎褒貶不一，本文對此不做探討。

存儲按照db來分目錄， 每一個db目錄下有 .ns文件 {dbname}.0, {dbname}.1 等文件。journal 目錄下存放的是WAL（write ahead log) 用於故障恢復。 目錄結構以下：

db
|------journal
           |----_j.0
           |----_j.1
           |----lsn
|------local
           |----local.ns
           |----local.0
           |----local.1
|------mydb
           |----mydb.ns
           |----mydb.0
           |----mydb.1

這三類文件構成了mmap引擎的持久化單元。本文主要從代碼層次分析每類文件的結構。

Namespace元數據管理

.ns文件映射

mmap引擎加載某個database時，首先初始化namespaceIndex，namespaceIndex至關於database的元數據入口。
mongo/db/storage/mmap_v1/catalog/namespace_index.cpp

89    DurableMappedFile _f{MongoFile::Options::SEQUENTIAL};      
 90    std::unique_ptr<NamespaceHashTable> _ht;               
154    const std::string pathString = nsPath.string(); 
159    _f.open(pathString);
232    p = _f.getView();
242    _ht.reset(new NamespaceHashTable(p, (int)len, "namespace index"));

如上，建立對.ns文件的mmap，將內存的view直接映射到hashtable上(不不進行任何解析)。所以.ns文件是一個hashtable的內存鏡像。

hashtable的key-value關係string->NamespaceDetails(namespace_details.h)，採用的是開放尋址hash。

39 int NamespaceHashTable::_find(const Namespace& k, bool& found) const {        
46     while (1) {        
47         if (!_nodes(i).inUse()) {        
48             if (firstNonUsed < 0)
49                 firstNonUsed = i;        
50         }       
51        
52         if (_nodes(i).hash == h && _nodes(i).key == k) {        
53             if (chain >= 200) 
54                 log() << "warning: hashtable " << _name << " long chain " << std::endl;        
55             found = true; 
56             return i;        
57         }        
58         chain++;        
59         i = (i + 1) % n; 
60         if (i == start) {        
62             log() << "error: hashtable " << _name << " is full n:" << n << std::endl;        
63             return -1;
64         }       
65         if (chain >= maxChain) {        
66             if (firstNonUsed >= 0)        
67                 return firstNonUsed;
68             log() << "error: hashtable " << _name << " max chain reached:" << maxChain << std::endl;
69             return -1;
70         }       
71     }       
72 }

上述過程是開放式尋址hash的經典的查找過程，若是有衝突，向後跳一格，若是跳到查找的起點依然沒有找到可用的空槽，則說明hashtable滿了。

元數據內容窺探

一個NamespaceDetails對象對應該db下的某張表的元數據(namespace_index.h)，大小爲496bytes，mongod默認爲.ns文件分配16MB的空間，且.ns文件惟一且不可動態伸縮空間，能夠推斷出一個mongod實例至多可建表大概30000個。該類有22個字段，重要字段有以下6個。

struct NamespaceDetails {
// extent對應於一個內存連續塊，因爲mmap，也是文件連續區域。一張表有多個extent。
// 以雙向鏈表的形式組織，firstExtent和lastExtent分別對應extent的首尾指針
DiskLoc firstExtent;  
DiskLoc lastExtent;
// 有若干種（26種）按照最小尺寸劃分的freelist，
// 表中刪除掉的行對應的數據塊放到freelist中，按照數據塊的尺寸劃分爲若干規則的freelist。
DiskLoc deletedListSmall[SmallBuckets];
// 兼容舊版本mmap引擎的廢棄字段
DiskLoc deletedListLegacyGrabBag;
// 該表是不是capped，capped-table是ring-buffer類型的table，MongoDB中用來存放oplog
int isCapped;
// 和deletedListSmall字段同樣，都是freelist的一部分，只是大小不一樣
DiskLoc deletedListLarge[LargeBuckets];
}

爲了便於下文闡述，結合上述對namespaceIndex構建過程的描述與對元數據的註解，筆者先勾勒出以下的元數據結構。

單表結構

上文咱們討論了單表元數據(NamespaceDetails)中重要字段的含義，接下來進行深刻探討。

Extent的組織形式

每張表由若干extent組成，每一個extent爲一塊連續的內存區域(也即連續的硬盤區域)，由firstExtent 和 lastExtent 記錄首尾位置，每一個extent的結構爲

/*extents are datafile regions where all the records within the region belong to the same namespace.*/
struct Extent {
    DiskLoc myLoc;
    DiskLoc xnext; //雙向鏈表中前節點指針
    DiskLoc xprev; //雙向鏈表中後節點指針
    Namespace nsDiagnstic;
    int length;
    // 一個Record對應表中的一行，每一個extent在物理上由若干地址連續的
    // Record組成，可是這些record在邏輯上的先後關係並不等價於物理上
    // 的先後關係，first/last Record維護了邏輯上的前後關係，在維護遊
    // 表迭代時使用
    DiskLoc firstRecord;
    DiskLoc lastRecord;
    char _extentData[4];
}

上述描述的組織結構以下圖所示：

Extent 的分配與回收由ExtentManger管理，ExtentManager 首先嚐試從已有文件中分配一個知足條件的連續塊，若是沒有找到，則生成一個新的{dbname}.i 的文件。

143 void DataFile::open(OperationContext* txn,                                                       
144                     const char* filename,                                                         
145                     int minSize,                                                                 
146                     bool preallocateOnly) {                                                       
147     long size = _defaultSize();                                                                   
148                                                                                                   
149     while (size < minSize) {                                                                     
150         if (size < maxSize() / 2) {                                                               
151             size *= 2;                                                                           
152         } else {                                                                                 
153             size = maxSize();                                                                     
154             break;                                                                               
155         }                                                                                         
156     }                                                                                             
157                                                                                                   
158     if (size > maxSize()) {                                                                       
159         size = maxSize();                                                                         
160     }                                                                                             
161                                                                                                   
162     invariant(size >= 64 * 1024 * 1024 || mmapv1GlobalOptions.smallfiles);

文件的大小 {dbname}.0的大小默認爲64MB。 以後每次新建會擴大一倍，以maxSize(默認爲2GB)爲上限。

一個extent被分爲若干Records，每一個Record對應表中的一行(一個集合中的文檔），每一張表被RecordStore類封裝，並對外提供出CRUD的接口。

Record分配

首先從已有的freelist(上文中提到的deletedBuckets)中分配，每張表按照內存塊尺寸維護了不一樣規格的freelist，每一個freelist是一個單向鏈表，當刪除Record時，將record放入對應大小的freelist中。
以下按照從小到大的順序遍歷DeletedBuckets，若是遍歷到有空閒且符合大小的空間，則分配：

107         for (myBucket = bucket(lenToAlloc); myBucket < Buckets; myBucket++) {
108             // Only look at the first entry in each bucket. This works because we are either
109             // quantizing or allocating fixed-size blocks.
110             const DiskLoc head = _details->deletedListEntry(myBucket);
111             if (head.isNull())
112                 continue;
113             DeletedRecord* const candidate = drec(head);
114             if (candidate->lengthWithHeaders() >= lenToAlloc) {
115                 loc = head;
116                 dr = candidate;
117                 break;
118             }
119         }

上述代碼分配出一塊尺寸合適的內存塊，可是該內存塊依然可能比申請的尺寸大一些。mmap引擎在這裏的處理方式是：將多餘的部分砍掉，並歸還給freelist。

133     const int remainingLength = dr->lengthWithHeaders() - lenToAlloc;
134     if (remainingLength >= bucketSizes[0]) {
135         txn->recoveryUnit()->writingInt(dr->lengthWithHeaders()) = lenToAlloc;
136         const DiskLoc newDelLoc = DiskLoc(loc.a(), loc.getOfs() + lenToAlloc);
137         DeletedRecord* newDel = txn->recoveryUnit()->writing(drec(newDelLoc));
138         newDel->extentOfs() = dr->extentOfs();       
139         newDel->lengthWithHeaders() = remainingLength;
140         newDel->nextDeleted().Null();
141         
142         addDeletedRec(txn, newDelLoc);
143     }

上述分片內存的過程以下圖所示：

如若從已有的freelist中分配失敗，則會嘗試申請新的extent,並將新的extent加到尺寸規則最大的freelist中。並再次嘗試從freelist中分配內存。

59 const int RecordStoreV1Base::bucketSizes[] = {
  ...
 83     MaxAllowedAllocation,      // 16.5M
 84     MaxAllowedAllocation + 1,  // Only MaxAllowedAllocation sized records go here.
 85     INT_MAX,                   // "oversized" bucket for unused parts of extents.
 86 };
 87

上述過程爲mmap引擎對內存管理的概況，可見每一個record在分配時不是固定大小的，申請到的內存塊要將多出的部分添加到deletedlist中，record釋放後也是連接到對應大小的deletedlist中，這樣作時間久了以後會產生大量的內存碎片，mmap引擎也有針對碎片的compact過程以提升內存的利用率。

碎片Compact

compact以命令的形式，暴露給客戶端，該命令以collection爲維度，在實現中，以extent爲最小粒度。

compact總體過程分爲兩步，如上圖，第一步將extent從freelist中斷開，第二步將extent中已使用空間copy到新的extent,拷貝過去保證內存的緊湊。從而達到compact的目的。

1. orphanDeletedList 過程
   將collection 對應的namespace 下的deletedlist 置空，這樣新建立的record就不會分配到已有的extent。

   443         WriteUnitOfWork wunit(txn);
   444         // Orphaning the deleted lists ensures that all inserts go to new extents rather than
   445         // the ones that existed before starting the compact. If we abort the operation before
   446         // completion, any free space in the old extents will be leaked and never reused unless
   447         // the collection is compacted again or dropped. This is considered an acceptable
   448         // failure mode as no data will be lost.
   449         log() << "compact orphan deleted lists" << endl;
   450         _details->orphanDeletedList(txn);

2. 對於每一個extent，每一個extent記錄了首尾record，遍歷全部record，並將record插入到新的extent中,新的extent在插入時因爲空間不足而自動分配（參考上面的過程），extent從新設置從最小size開始增加。

   452     // Start over from scratch with our extent sizing and growth
   453     _details->setLastExtentSize(txn, 0);
   454
   455     // create a new extent so new records go there
   456     increaseStorageSize(txn, _details->lastExtentSize(txn), true);
   467     for (std::vector<DiskLoc>::iterator it = extents.begin(); it != extents.end(); it++) {
   468         txn->checkForInterrupt();
   469         invariant(_details->firstExtent(txn) == *it);
   470         // empties and removes the first extent
   471         _compactExtent(txn, *it, extentNumber++, adaptor, options, stats);
   472         invariant(_details->firstExtent(txn) != *it);
   473         pm.hit();
   474     }

3. 在_compactExtent的過程當中，該extent的record逐漸被插入到新的extent裏，空間逐步釋放，當所有record都清理完後，該extent又變成嶄新的，沒有使用過的extent了。以下圖
   

   324         while (!nextSourceLoc.isNull()) {
   325             txn->checkForInterrupt();
   326
   327             WriteUnitOfWork wunit(txn);
   328             MmapV1RecordHeader* recOld = recordFor(nextSourceLoc);
   329             RecordData oldData = recOld->toRecordData();
   330             nextSourceLoc = getNextRecordInExtent(txn, nextSourceLoc);
   371             CompactDocWriter writer(recOld, rawDataSize, allocationSize);
   372             StatusWith<RecordId> status = insertRecordWithDocWriter(txn, &writer);
   398             _details->incrementStats(txn, -(recOld->netLength()), -1);
             }

   上述便是_compactExtent函數中遍歷該extent的record，並插入到其餘extent，並逐步釋放空間的過程（398行）。

mmap數據回寫

上面咱們介紹.ns文件結構時談到.ns文件是經過mmap 映射到內存中的一個hashtable上，這個映射過程是經過DurableMappedFile 實現的。咱們看下該模塊是如何作持久化的
在mmap 引擎的 finishInit中

252 void MMAPV1Engine::finishInit() {

253     dataFileSync.go();

這裏調用 DataFileSync類的定時任務，在backgroud線程中按期落盤

67     while (!inShutdown()) {
 69         if (storageGlobalParams.syncdelay == 0) {
 70             // in case at some point we add an option to change at runtime
 71             sleepsecs(5);
 72             continue;
 73         }
 74
 75         sleepmillis(
 76             (long long)std::max(0.0, (storageGlobalParams.syncdelay * 1000) - time_flushing));

 83         Date_t start = jsTime();
 84         StorageEngine* storageEngine = getGlobalServiceContext()->getGlobalStorageEngine();
 85
 86         dur::notifyPreDataFileFlush();
 87         int numFiles = storageEngine->flushAllFiles(true);
 88         dur::notifyPostDataFileFlush();
 97         }
 98     }

flushAllFiles最終會調用每一個memory-map-file的flush方法

245 void MemoryMappedFile::flush(bool sync) {                                                         
246     if (views.empty() || fd == 0 || !sync)                                                       
247         return;                                                                                   
248                                                                                                   
249     bool useFsync = !ProcessInfo::preferMsyncOverFSync();                                         
250                                                                                                   
251     if (useFsync ? fsync(fd) != 0 : msync(viewForFlushing(), len, MS_SYNC) != 0) {               
252         // msync failed, this is very bad                                                         
253         log() << (useFsync ? "fsync failed: " : "msync failed: ") << errnoWithDescription()       
254               << " file: " << filename() << endl;                                                 
255         dataSyncFailedHandler();                                                                 
256     }                                                                                             
257 }

fsync vs msync

無論調用fsync 仍是msync落盤，咱們的預期都是內核會高效的查找出數據中的髒頁執行寫回，可是根據https://jira.mongodb.org/browse/SERVER-14129 以及下面的代碼註釋中
在有些操做系統上（好比SmartOS與 Solaris的某些版本)， msync並不能高效的尋找髒頁，所以mmap引擎在這裏對操做系統區別對待了。

208         // On non-Solaris (ie, Linux, Darwin, *BSD) kernels, prefer msync.
209         // Illumos kernels do O(N) scans in memory of the page table during msync which
210         // causes high CPU, Oracle Solaris 11.2 and later modified ZFS to workaround mongodb
211         // Oracle Solaris Bug:                                                                   
212         //  18658199 Speed up msync() on ZFS by 90000x with this one weird trick
213         bool preferMsyncOverFSync;