Adobe Experience Manager與MongoDB

MongoDB作業管理員

MongoDB Ops Manager與MongoDB Cloud Manager是相同的軟體。 註冊後，Ops Manager即可下載並安裝在本機私人資料中心或任何其他筆記型電腦或桌上型電腦上。 它使用本機MongoDB資料庫來儲存資料，並以與Cloud Manager相同的方式與受管理伺服器通訊。 如果您的安全性原則禁止監控代理程式，則應使用MongoDB Ops Manager。

作業系統監視

執行AEM MongoDB叢集需要作業系統層級監視。

Ganglia就是這類系統的好例子，它提供超越基本健康量度(例如CPU、平均負載和可用磁碟空間)所需的資訊範圍和詳細資訊。 若要診斷問題，需要較低層級的資訊，例如平均資訊量集區層級、CPU I/O等待、FIN_WAIT2狀態的通訊端。

記錄彙總

如果叢集內有多部伺服器，生產系統需要集中記錄彙總。 Splunk等軟體支援記錄彙總，可讓團隊分析應用程式的行為模式，而不需手動收集記錄。

檢查清單

本節說明您應採取的各種步驟，以確保在實作專案前已正確設定AEM和MongoDB部署。

網路

AEM設定

節點存放區設定

AEM執行個體必須設定為搭配MongoMK使用AEM。 AEM中MongoMK實施的基礎是檔案節點存放區。

如需如何設定節點存放區的詳細資訊，請參閱在AEM中設定節點存放區和資料存放區。

以下是最小MongoDB部署的檔案節點存放區設定範例：

其中：

資料存放區設定

資料存放區是用來儲存大小大於臨界值的檔案。 低於該臨界值時，檔案會儲存為檔案節點存放區中的屬性。 如果使用MongoBlobStore，則會在MongoDB中建立專用集合以儲存Blob。 此集合貢獻了mongod執行個體的工作集，並要求mongod擁有更多的RAM以避免效能問題。 因此，建議的設定是為生產部署避免MongoBlobStore，並使用由所有AEM執行個體共用的NAS支援的FileDataStore。 因為作業系統層級快取在管理檔案時很有效率，所以磁碟上的檔案大小下限應該設定為接近磁碟的區塊大小。 如此可確保檔案系統有效率地使用，而且許多小檔案不會對mongod執行個體的工作集產生過多的影響。

以下是使用MongoDB進行最低AEM部署的典型資料存放區設定：

其中：

停用查詢提示

當您啟動AEM時，建議您新增屬性-Doak.mongo.disableIndexHint=true，以停用與所有查詢一併傳送的查詢提示。 如此可確保MongoDB會根據內部統計資料，計算最適合使用的索引。

如果未停用查詢提示，則索引的任何效能調整都不會影響AEM的效能。

啟用MongoMK的永久性快取

建議為MongoDB部署啟用持續快取設定，以針對具有高I/O讀取效能的環境最大化速度。 如需詳細資訊，請參閱Jackrabbit Oak檔案。

壓縮

使用WiredTiger時，MongoDB支援所有集合和索引的壓縮。 壓縮可儘量減少儲存空間的使用量，但需額外付費CPU。

根據預設，WiredTiger使用區塊壓縮，針對所有集合使用snappy壓縮程式庫，針對所有索引使用首碼壓縮。

集合也可使用zlib的區塊壓縮。 若要指定替代壓縮演演算法或不壓縮，請使用storage.wiredTiger.collectionConfig.blockCompressor設定。

對於索引，若要停用首碼壓縮，請使用storage.wiredTiger.indexConfig.prefixCompression設定。

壓縮設定也可以在集合和索引建立期間根據每個集合和每個索引進行配置。 請參閱指定儲存引擎選項和db.collection.createIndex() storageEngine選項。

對於大部分的工作負載，預設的壓縮設定可平衡儲存效率與處理需求。

預設也會壓縮WiredTiger日誌。 如需日誌壓縮的資訊，請參閱日誌。

記憶體使用率

使用WiredTiger時，MongoDB會同時使用WiredTiger內部快取和檔案系統快取。

從3.4版開始，WiredTiger內部快取預設會使用以下兩者中較大的一個：

根據預設，WiredTiger會針對所有集合使用Snappy區塊壓縮，針對所有索引使用前置詞壓縮。 壓縮預設值可在全域層級設定，也可在集合和索引建立期間根據集合和索引進行設定。

WiredTiger內部快取與磁碟格式中的資料使用不同的表示方式：

載入到WiredTiger內部快取的索引與磁碟上的格式具有不同的資料表示方式，但是仍然可以利用索引首碼壓縮來減少RAM使用量。

索引首碼壓縮會從索引欄位中去除重複的通用首碼。

WiredTiger內部快取中的集合資料會解壓縮，並使用與磁碟格式不同的表示方式。 區塊壓縮可大幅節省磁碟上的儲存空間，但資料必須解壓縮才能由伺服器操作。

透過檔案系統快取，MongoDB會自動使用WiredTiger快取或其他處理程式未使用的所有可用記憶體。

若要調整WiredTiger內部快取的大小，請參閱storage.wiredTiger.engineConfig.cacheSizeGB和—wiredTigerCacheSizeGB。 請避免增加WiredTiger內部快取大小，使其超過預設值。

NUMA

NUMA （非統一記憶體存取）可讓核心管理記憶體對應到處理器核心的方式。 雖然此程式會嘗試讓核心的記憶體存取速度更快，以確保他們能夠存取所需的資料，但NUMA會干擾MMAP，導致無法預測讀取的額外延遲。 因此，必須在所有支援的作業系統上為mongod處理序停用NUMA。

實質上，在NUMA架構中，記憶體會連線至CPU，而CPU會連線至匯流排。 在SMP或UMA架構中，記憶體會連線至匯流排並由CPU共用。 執行緒在NUMA CPU上分配記憶體時，會根據原則進行分配。 預設會分配附加到執行緒本機CPU的記憶體，除非沒有可用空間，否則會使用來自可用CPU的記憶體，但成本較高。 配置之後，記憶體不會在CPU之間移動。 配置是由從父系對話串繼承的原則執行，該對話串最終是啟動程式的對話串。

在許多將電腦視為多核心統一記憶體架構的資料庫中，此情況會導致初始CPU先變滿，而次要CPU稍後變滿。 如果中央執行緒負責配置記憶體緩衝區，就特別正確。 解決方案是執行下列命令，變更用來啟動mongod處理序之主要執行緒的NUMA原則：

此原則會以循環配置方式將記憶體分配給所有CPU節點，以確保所有節點的均等分佈。 它不會產生記憶體的最高效能存取，如同具有多個CPU硬體的系統。 大約一半的記憶體操作速度較慢，而且會超出匯流排，但mongod並未以最佳方式寫入目標NUMA，所以這是合理的折衷方式。