带有MongoDB的Adobe Experience Manager

本文旨在了解有关使用MongoDB成功部署AEM (Adobe Experience Manager)所必需的任务和注意事项的知识。

有关与部署相关的更多信息，请查阅 部署和维护 部分。

何时将MongoDB与AEM一起使用

MongoDB通常用于支持满足以下条件之一的AEM创作部署：

• 每天超过1000个独特用户；
• 并发用户超过100个；
• 大量页面编辑；
• 大型转出或激活。

上述标准仅适用于创作实例，而不适用于所有应基于TarMK的发布实例。 用户数是指经过身份验证的用户，因为创作实例不允许进行未经身份验证的访问。

如果不满足标准，则建议使用TarMK活动/备用部署来解决可用性问题。 通常，在扩展要求超过单项硬件所能达到的要求时，应考虑使用MongoDB。

适用于AEM的最小MongoDB部署

以下是MongoDB上AEM的最低部署。 为简单起见，已推广SSL终止和HTTP代理组件。 它包含一个MongoDB副本集，包含一个主副本集和两个辅助副本。

最低的部署需要三个 mongod 配置为副本集的实例。 一个实例被选为初级实例，而其他实例被选为次级实例，选举由管理 mongod. 连接到每个实例的是本地磁盘。 因此，群集可以支持负载，建议最小吞吐量为每秒12 MB，并且每秒的I/O操作数(IOPS)超过3000个。

AEM作者已连接到 mongod 实例，每个AEM作者都连接到所有三个实例 mongod 实例。 写操作将发送到主数据库，并且可以从任何实例读取读取数据。 流量根据Dispatcher的负载分发到任何一个活动的AEM创作实例。 Oak数据存储是 FileDataStore和MongoDB监控由MMS或MongoDB Ops Manager提供，具体取决于部署的位置。 操作系统级别和日志监控由第三方解决方案（如Splunk或Ganglia）提供。

在此部署中，需要所有组件才能成功实施。 任何缺少的组件都会使实施无法正常运行。

操作系统

有关AEM 6支持的操作系统的列表，请参阅 “技术要求”页面.

环境

如果运行项目的不同技术团队之间通信良好，则支持虚拟化环境。 此支持包括运行AEM的团队、拥有操作系统的团队和管理虚拟化基础架构的团队。

有一些特定要求涵盖MongoDB实例的I/O容量，这些要求必须由管理虚拟化环境的团队来管理。 如果项目使用云部署(如Amazon Web Services)，则必须为实例配置足够的I/O容量和一致性，以支持MongoDB实例。 否则， MongoDB进程和Oak存储库会不可靠和不稳定地执行。

在虚拟化环境中，MongoDB需要特定的I/O和VM配置，以确保MongoDB的存储引擎不会受到VMWare资源分配策略的损害。 成功的实施可确保各个团队之间不存在障碍，并且所有团队都已注册以提供所需的性能。

硬件注意事项

存储

为了在不进行过早水平扩展的情况下实现最佳性能的读写吞吐量，MongoDB通常需要SSD存储或性能相当于SSD的存储。

RAM

使用MMAP存储引擎的MongoDB版本2.6和3.0要求数据库的工作集及其索引适应RAM。

RAM不足导致性能显着降低。 工作集和数据库的大小高度依赖于应用程序。 虽然可以做出一些估计，但确定所需RAM量的最可靠方法是构建AEM应用程序并对其进行负载测试。

为了帮助进行负载测试，可以假定工作集与数据库总大小的比率如下：

• 固态硬盘存储为1:10
• 硬盘存储为1:3

这些比率意味着，对于SSD部署，2 TB的数据库需要200 GB的RAM。

MongoDB 3.0中的WiredTiger存储引擎也存在同样的限制，但工作集、RAM和页面故障之间的相关性并不太强。 WiredTiger使用的内存映射与MMAP存储引擎不同。

数据存储

由于MongoDB工作集限制，建议独立于MongoDB维护数据存储。 在大多数环境中， FileDataStore 应使用可用于所有AEM实例的NAS。 对于使用Amazon Web Services的情况，还可以 S3 DataStore. 如果出于任何原因，数据存储在MongoDB中维护，则数据存储的大小应添加到总数据库大小中，并且工作集计算应进行适当的调整。 此大小调整可能意味着配置更多RAM以保持性能，而不会出现页面故障。

监测

监测对于项目的成功实施至关重要。 在充分了解的情况下，可以在MongoDB上运行AEM而不进行监视。 但是，这些知识通常由专门负责部署每个部分的工程师来掌握。

这些专业知识通常涉及使用Apache Oak Core的研发工程师和MongoDB专家。

如果没有在所有级别进行监控，则需要具备代码库的详细知识才能诊断问题。 在主要统计数据上实施监测和提供适当指导后，实施团队可以对异常情况作出适当反应。

虽然可以使用命令行工具快速获取群集操作的快照，但几乎不可能在多台主机上实时执行此操作。 命令行工具很少在几分钟后提供历史信息，并且绝不允许不同类型的量度之间相互关联。 一段短暂的慢速背景 mongod 同步需要大量手动操作，才能将I/O等待或过多的写入级别与似乎未连接的虚拟机中的共享存储资源相关联。

MongoDB Cloud Manager

MongoDB Cloud Manager是MongoDB提供的免费服务，允许监控和管理MongoDB实例。 它实时提供MongoDB群集的性能和运行状况视图。 它同时管理云实例和私有托管实例，前提是实例可以访问Cloud Manager监控服务器。

它要求在MongoDB实例上安装连接到监控服务器的代理。 代理分为三个级别：

• 能够完全自动化MongoDB服务器上所有内容的自动化代理，
• 可以监视的监视代理 mongod 实例，
• 备份代理，可以对数据执行定时备份。

尽管使用Cloud Manager实现MongoDB群集的维护自动化使许多例行任务更加容易，但是它不是必需的，而且也没有将它用于备份。 但是，在选择Cloud Manager进行监视时，需要监视。

有关MongoDB Cloud 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部署而应执行的各种步骤。

网络

1. 首先，确保所有主机都有DNS条目
2. 所有主机应可由来自所有其他可路由主机的DNS条目解析
3. 所有MongoDB主机均可从同一群集中的所有其他MongoDB主机路由
4. MongoDB主机可以将数据包路由到MongoDB Cloud Manager和其他监控服务器
5. AEM Server可以将数据包路由到所有MongoDB服务器
6. 任何AEM服务器与任何MongoDB服务器之间的数据包延迟都小于2毫秒，没有数据包丢失，标准分发时间不超过1毫秒。
7. 确保AEM和MongoDB服务器之间的跃点数不超过两个
8. 两个MongoDB服务器之间最多只有两个跃点
9. 任何核心服务器(MongoDB或AEM或任何组合)之间都没有高于OSI级别3的路由器。
10. 如果使用VLAN中继或任何形式的网络隧道，则必须遵守数据包延迟检查。

AEM配置

节点存储配置

必须将AEM实例配置为将AEM与MongoMK一起使用。 AEM中MongoMK实现的基础是文档节点存储。

有关如何配置节点存储的详细信息，请参阅 在AEM中配置节点存储和数据存储.

以下是最小MongoDB部署的Document Node Store配置示例：

# org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
#MongoDB server details
mongodburi=mongodb://aem:aempassword@mongodbserver1.customer.com:27000,mongodbserver2.customer.com:27000

#Name of MongoDB database to use
db=aem

#Store binaries in custom BlobStore for example, FileDataStore
customBlobStore=true

cache=2048
blobCacheSize=1024

其中：

• mongodburi
  MongoDB服务器AEM必须连接到。 与默认副本集的所有已知成员建立连接。 如果使用MongoDB Cloud Manager，则启用服务器安全性。 因此，连接字符串必须包含合适的用户名和密码。 非企业版本的MongoDB仅支持用户名和密码身份验证。 有关连接字符串语法的更多信息，请参阅 文档.

• db
  数据库的名称。 AEM的默认值为 aem-author.

• customBlobStore
  如果部署将二进制文件存储在数据库中，则它们是工作集的一部分。 因此，建议不要在MongoDB中存储二进制文件，而是选择替代数据存储，如 FileSystem NAS上的数据存储。

• cache
  缓存大小（以MB为单位）。 此空间分布在 DocumentNodeStore. 默认值为256 MB。 但是，Oak读取性能受益于较大的缓存。

• blobCacheSize
  AEM可能会缓存常用的Blob，以避免从数据存储中重新获取它们。 这样做对性能的影响更大，尤其是在MongoDB数据库中存储Blob时。 所有基于文件系统的Data Stores都受益于操作系统级别的磁盘缓存。

数据存储配置

数据存储用于存储大于阈值的文件。 低于该阈值时，文件将作为属性存储在文档节点存储中。 如果 MongoBlobStore 之后，将在MongoDB中创建专用收藏集来存储Blob。 此收藏集对的工作集有 mongod 实例，并要求 mongod 具有更多内存以避免性能问题。 因此，推荐的配置是避免 MongoBlobStore 用于生产部署和使用 FileDataStore 由在所有AEM实例之间共享的NAS作为后盾。 由于操作系统级别的缓存可以高效地管理文件，因此磁盘上文件的最小大小应设置为接近磁盘的块大小。 这样做可确保文件系统得到有效使用，并且许多小文档不会过度贡献的工作集 mongod 实例。

以下是使用MongoDB进行最低AEM部署的典型数据存储配置：

# org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
# The minimum size of an object that should be stored in this data store.
minRecordLength=4096
path=/datastore
maxCachedBinarySize=4096
cacheSizeInMB=128

其中：

• minRecordLength
  大小（字节）. 小于或等于此大小的二进制文件存储在文档节点存储中。 存储的是二进制文件的内容，而不是存储blob的ID。 对于大于此大小的二进制文件，二进制文件的ID作为文档的属性存储在节点集合中。 而且，二进制文件的正文存储在 FileDataStore 在磁盘上。 4096字节是典型的文件系统块大小。

• path
  数据存储根的路径。 对于MongoMK部署，此路径必须是所有AEM实例都可用的共享文件系统。 通常使用网络连接存储(NAS)服务器。 对于Amazon Web Services等云部署， S3DataFileStore 也可用。

• cacheSizeInMB
  二进制缓存的总大小（以MB为单位）。 它用于缓存小于以下值的二进制文件 maxCacheBinarySize 设置。

• maxCachedBinarySize
  二进制缓存中缓存的二进制文件的最大大小（字节）。 如果使用基于文件系统的数据存储，则建议不要为数据存储缓存使用高值，因为操作系统已缓存二进制文件。

禁用查询提示

建议您通过添加属性来禁用随所有查询一起发送的查询提示 -Doak.mongo.disableIndexHint=true 启动AEM时。 这样做可以确保MongoDB根据内部统计信息计算使用的最合适的索引。

如果未禁用查询提示，则索引的任何性能调整都不会影响AEM的性能。

为MongoMK启用永久缓存

建议为MongoDB部署启用永久缓存配置，以便最大化具有高I/O读取性能的环境的速度。 欲知更多详情，请参见 Jackrabbit Oak文档.

MongoDB操作系统优化

操作系统支持

MongoDB 2.6使用内存映射存储引擎，该引擎对RAM和磁盘之间操作系统级别管理的某些方面很敏感。 MongoDB实例的查询和读取性能依赖于避免或消除通常称为页面故障的缓慢I/O操作。 这些问题属于页面错误，适用于 mongod 尤其是流程。 不要与操作系统级别的页面错误混淆。

为了快速操作，MongoDB数据库应仅访问RAM中已有的数据。 它必须访问的数据由索引和数据组成。 此索引和数据集合称为工作集。 如果工作集大于可用的RAM，则MongoDB必须从磁盘中分页该数据，从而产生I/O开销，收回内存中已有的其他数据。 如果逐出导致从磁盘重新加载数据，则页面故障会占主导地位，性能会降低。 如果工作集是动态的、可变的，则会产生更多的页面错误来支持操作。

MongoDB运行在多种操作系统上，包括各种Linux®版本、Windows和macOS。 参见 https://docs.mongodb.com/manual/installation/#supported-platforms 以了解更多详细信息。 根据您选择的操作系统，MongoDB有不同的操作系统级别建议。 记录在 https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration 为了方便起见，在此处进行了总结。

Linux®

• 关闭透明的拥抱和碎片整理。 参见 透明的巨大页面设置 了解更多信息。

• 调整预读设置 在存储数据库文件的设备上，以便适合您的用例。

  • 对于MMAPv1存储引擎，如果您的工作集大于可用的RAM，并且文档访问模式是随机的，请考虑将预读数降低到32或16。 评估不同的设置，以便找到最大化驻留内存并降低页面故障数的最佳值。
  • 对于WiredTiger存储引擎，无论存储介质类型（旋转、SSD等）如何，都将预读设置为0。 通常，使用推荐的预读设置，除非测试显示可在更高的预读值中获得可衡量、可重复和可靠的好处。 MongoDB专业支持 可以为非零预读配置提供建议和指导。

• 如果在虚拟环境中运行RHEL 7 / CentOS 7，请禁用优化工具。

• 当RHEL 7/CentOS 7在虚拟环境中运行时，优化工具会自动调用从性能吞吐量派生的性能配置文件，这会自动将预读设置设置为4 MB。 此设置可能会对性能产生负面影响。

• 对SSD驱动器使用noop或deadline磁盘调度程序。

• 对来宾虚拟机中的虚拟化驱动器使用noop磁盘调度程序。

• 禁用NUMA或设置 vm.zone_reclaim_mode 到0并运行 mongod 具有节点交错的实例。 请参阅： MongoDB和NUMA硬件 了解更多信息。

• 调整硬件上的限制值，使其适合您的使用案例。 如果多个 mongod 或 蒙古人 实例在同一用户下运行，请相应地缩放极限值。 请参阅： UNIX® ulimit设置 了解更多信息。

• 使用noatime进行 数据库路径 装入点。

• 为部署配置足够的文件句柄(fs.file-max)、内核pid限制(kernel.pid_max)和每个进程的最大线程数(kernel.threads-max)。 对于大型系统，以下值提供了一个良好的起点：

  • fs.file-max值98000，
  • 64000的kernel.pid_max值，
  • andkernel.threads-64000的最大值

• 确保系统已配置交换空间。 有关适当大小的详细信息，请参阅操作系统的文档。

• 确保正确设置了系统默认的TCP keepalive。 值为300通常为副本集和共享群集提供更好的性能。 请参阅： TCP keepalive时间是否影响MongoDB部署？ ，以了解更多信息。

Windows

• 请考虑禁用NTFS“上次访问时间”更新。 此设置类似于在类似Unix的系统上禁用atime。

WiredTiger

从MongoDB 3.2开始，MongoDB的默认存储引擎是WiredTiger存储引擎。 此引擎提供了一些强大且可扩展的功能，使其更适合全面的一般数据库工作负载。 以下各节介绍了这些功能。

文档级别并发

WiredTiger使用文档级并发控制执行写入操作。 因此，多个客户端可以同时修改收藏集的不同文档。

对于大多数读写操作， WiredTiger使用乐观的并发控制。 WiredTiger仅使用全局、数据库和收集级别的意图锁定。 当存储引擎检测到两个操作之间的冲突时，其中一个操作发生写入冲突，导致MongoDB透明地重试该操作。 某些全局操作（通常涉及多个数据库的短期操作）仍需要全局“实例范围”锁。

某些其他操作（如删除集合）仍需要独占数据库锁定。

快照和检查点

WiredTiger使用MultiVersion Concurrency Control (MVCC)。 在开始操作时， WiredTiger为事务提供数据的时间点快照。 快照呈现内存中数据的一致视图。

在写入磁盘时， WiredTiger以一致的方式将所有快照中的数据写入磁盘。 现在 — 耐用 数据充当数据文件中的检查点。 检查点确保数据文件与上一个检查点（包括上一个检查点）保持一致。 也就是说，检查点可以充当恢复点。

MongoDB将WiredTiger配置为以60秒或2 GB的日志数据为间隔创建检查点（即，将快照数据写入磁盘）。

在写入新检查点期间，上一个检查点仍然有效。 因此，即使MongoDB在写入新检查点时终止或遇到错误，在重新启动时，MongoDB也可以从最后一个有效的检查点恢复。

当WiredTiger的元数据表自动更新以引用新检查点时，新检查点将变为可访问且永久性的。 一旦新检查点可以访问，WiredTiger就会从旧检查点中释放页面。

使用WiredTiger，即使没有 日志，MongoDB可以从上一个检查点恢复；但是，要恢复在上一个检查点之后所做的更改，请使用 日志.

日志

WiredTiger使用预写事务登录组合 检查点 以确保数据持久性。

WiredTiger日志保留检查点之间的所有数据修改。 如果MongoDB在检查点之间退出，则它会使用日志重播自上次检查点以来修改的所有数据。 有关MongoDB将日志数据写入磁盘的频率的信息，请参见 日志记录过程.

WiredTiger日志使用 快速响应 压缩库。 要指定替代压缩算法或不压缩，请使用 storage.wiredTiger.engineConfig.journalCompressor 设置。

参见 使用WiredTiger进行日记.

压缩

使用WiredTiger时，MongoDB支持对所有集合和索引进行压缩。 压缩以牺牲额外的CPU为代价将存储使用降至最低。

默认情况下，WiredTiger使用块压缩 快速响应 所有收藏集和的压缩库 前缀压缩 用于所有索引。

对于收藏集，使用进行块压缩 zlib 也可用。 要指定替代压缩算法或不压缩，请使用 storage.wiredTiger.collectionConfig.blockCompressor 设置。

对于索引，禁用 前缀压缩，使用 storage.wiredTiger.indexConfig.prefixCompression 设置。

压缩设置也可以在集合和索引创建期间按集合和按索引进行配置。 参见 指定存储引擎选项 和 db.collection.createIndex() storageEngine 选项。

对于大多数工作负载，默认压缩设置可平衡存储效率和处理要求。

默认情况下，WiredTiger日志也会被压缩。 有关日记帐压缩的信息，请参阅 日志.

内存使用

使用WiredTiger时，MongoDB同时使用WiredTiger内部缓存和文件系统缓存。

从3.4开始，默认情况下，WiredTiger内部缓存使用以下两者中较大的一个：

• 50%的RAM减去1 GB，或
• 256兆字节

默认情况下，WiredTiger对所有集合使用Snappy块压缩，对所有索引使用前缀压缩。 压缩默认值可在全局级别进行配置，还可在集合和索引创建期间基于集合和索引进行设置。

WiredTiger内部缓存中的数据与磁盘格式的数据使用不同的表示形式：

• 文件系统缓存中的数据与磁盘上的格式相同，包括对数据文件进行任何压缩的好处。 操作系统使用文件系统缓存来减少磁盘I/O。

加载到WiredTiger内部缓存中的索引与磁盘格式的数据表示不同，但仍然可以利用索引前缀压缩来减少RAM使用量。

索引前缀压缩从索引字段中删除重复的公共前缀。

WiredTiger内部缓存中的收集数据是未压缩的，使用与磁盘格式不同的表示形式。 块压缩可以显着节省磁盘上的存储空间，但是数据必须解压缩才能由服务器操作。

通过文件系统缓存， MongoDB自动使用WiredTiger缓存或其他进程未使用的所有可用内存。

要调整WiredTiger内部缓存的大小，请参见 storage.wiredTiger.engineConfig.cacheSizeGB 和 —wiredTigerCacheSizeGB. 避免将WiredTiger内部缓存大小增加到超过其默认值。

NUMA

NUMA（非统一内存访问）允许内核管理如何将内存映射到处理器内核。 尽管此过程尝试使内核访问内存的速度更快，以确保他们能够访问所需数据，但NUMA会干扰MMAP，引入额外的延迟，因为无法预测读取次数。 因此，必须为 mongod 会在所有具备能力的操作系统上处理。

实质上，在NUMA体系结构中，存储器连接到CPU，CPU连接到总线。 在SMP或UMA体系结构中，内存连接到总线并由CPU共享。 当线程在NUMA CPU上分配内存时，它会根据策略进行分配。 缺省值是分配连接到线程的本地CPU的内存，除非没有可用内存，否则此时它会以较高的成本使用可用CPU的内存。 分配后，内存不会在CPU之间移动。 分配由从父线程（最终是启动进程的线程）继承的策略执行。

在许多将计算机视为多核统一内存体系结构的数据库中，这种情形会导致初始CPU先被占满，而次要CPU稍后被占满。 如果中心线程负责分配内存缓冲区，则尤其如此。 解决方案是更改用于启动 mongod 通过运行以下命令来处理：

numactl --interleaved=all <mongod> -f config

此策略以循环方式为所有CPU节点分配内存，确保在所有节点上均匀分布。 与具有多个CPU硬件的系统不同，它不会产生对内存的最高性能访问。 大约一半的内存操作速度较慢，而且是在总线上执行的，但是 mongod 并未以最佳方式针对NUMA，因此这是一种合理的折衷。

NUMA问题

如果 mongod 进程从非以下位置启动： /etc/init.d 文件夹，可能未使用正确的NUMA策略开头。 根据默认策略的不同，可能会出现问题。 原因是用于MongoDB的各种Linux® Package Manager安装程序也安装了包含配置文件的服务 /etc/init.d ，以执行上述步骤。 如果直接从存档安装和运行MongoDB ( .tar.gz)，您必须手动运行 numactl 进程。

MongoDB进程在不同的分配策略下的行为不同：

• -membind=<nodes>
  仅在列出的节点上分配。 Mongod不会在列出的节点上分配内存，并且可能无法使用所有可用内存。

• -cpunodebind=<nodes>
  仅在节点上运行。 Mongod只在指定的节点上运行，并且只使用这些节点上可用的内存。

• -physcpubind=<nodes>
  仅在列出的CPU（内核）上运行。 Mongod只在列出的CPU上运行，并且只使用这些CPU上可用的内存。

• --localalloc
  始终在当前节点上分配内存，但使用线程运行的所有节点。 如果一个线程执行分配，则仅使用该CPU可用的内存。

• --preferred=<node>
  与节点相比，优先分配，但如果首选节点已满，则回退到其他节点。 可以使用用于定义节点的相对表示法。 此外，线程在所有节点上运行。

某些策略可能导致分配给的所有可用RAM不足 mongod 进程。 与MySQL不同，MongoDB主动避免操作系统级别分页，因此 mongod 进程可能获得更少的可用内存。

交换

由于数据库的内存密集特性，必须禁用操作系统级别交换。 MongoDB进程在设计上避免了交换。

远程文件系统

不建议将NFS等远程文件系统用于MongoDB的内部数据文件（mongod处理数据库文件），因为它们会引入太多延迟。 不要混淆Oak Blob (FileDataStore)的存储所需的共享文件系统，这里建议使用NFS。

预读

预调读取，以便当使用随机读取分页页时，不从磁盘读取不必要的块。 这样的结果意味着不必要的I/O带宽消耗。

Linux®要求

最小内核版本

• 2.6.23 对象 ext4 文件系统

• 2.6.25 对象 xfs 文件系统

数据库磁盘的建议设置

关闭时间

建议 atime 对于包含数据库的磁盘，将关闭。

设置NOOP磁盘调度程序

执行以下操作：

首先，检查通过运行以下命令设置的I/O调度程序：

cat /sys/block/sdg/queue/scheduler

如果响应为 noop，您无需执行其他操作。

如果NOOP不是所设置的I/O调度程序，可以通过运行以下命令来更改它：

echo noop > /sys/block/sdg/queue/scheduler

调整预读值

建议对运行MongoDB数据库的磁盘使用值32。 该值相当于16 KB。 您可以通过运行以下命令来设置它：

sudo blockdev --setra <value> <device>

启用NTP

确保在托管MongoDB数据库的计算机上安装并运行了NTP。 例如，您可以使用yum包管理器在CentOS计算机上安装它：

sudo yum install ntp

在安装NTP守护程序并成功启动后，您可以检查漂移文件以了解服务器的时间偏移。

禁用透明超大页面

Red Hat® Linux®使用称为Transparent Great Pages (THP)的内存管理算法。 如果您使用操作系统处理数据库工作负载，建议您禁用此功能。

您可以按照以下步骤禁用它：

1. 打开 /etc/grub.conf 文件中的文本编辑器。

2. 将以下行添加到grub.conf文件中：

   transparent_hugepage=never
   

3. 最后，通过运行以下命令，检查设置是否已生效：

   cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
   

   如果禁用了THP，则上述命令的输出应为：

   always madvise [never]
   

禁用NUMA

在启用了NUMA的大多数安装中，如果MongoDB守护程序作为服务运行，则会自动禁用它。 /etc/init.d 文件夹。

如果不是这种情况，您可以在每个进程级别上禁用NUMA。 要禁用此功能，请运行以下命令：

numactl --interleave=all <path_to_process>

位置 <path_to_process> 是通往魔鬼的道路。

然后，通过运行以下命令禁用区域回收：

echo 0 > /proc/sys/vm/zone_reclaim_mode

调整mongod进程的ulimit设置

Linux®允许通过 ulimit 命令。 此配置可以按用户或按进程完成。

建议您根据以下规则为mongod进程配置ulimit MongoDB建议的ulimit设置.

测试MongoDB I/O性能

MongoDB提供了一个名为 mongoperf 旨在测试I/O性能。 建议使用它来测试组成基础架构的所有MongoDB实例的性能。

有关如何使用的信息 mongoperf，查看 MongoDB文档.

在构成部署的虚拟机上测试读取性能

安装该工具后，切换到MongoDB数据库目录以运行测试。 然后，通过运行来开始第一次测试 mongoperf使用此配置：

echo "{nThreads:32,fileSizeMB:1000,r:true}" | mongoperf

对于所有MongoDB实例，所需的输出应高达每秒2 GB (2 GB/s)和500.000 IOPS，在32个线程下运行。

再次运行测试，这次使用内存映射文件，通过设置 mmf:true 参数：

echo "{nThreads:32,fileSizeMB:1000,r:true,mmf:true}" | mongoperf

第二次测试的输出应比第一次测试高很多，这表示内存转移性能。

测试主MongoDB实例的写入性能

接下来，通过运行检查主MongoDB实例的I/O写入性能 mongoperf 从MongoDB数据库目录中使用相同的设置：

echo "{nThreads:32,fileSizeMB:1000,w:true}" | mongoperf

所需的输出应为12 MB/秒，达到3000 IOPS左右，线程数之间几乎没有变化。

虚拟化环境的步骤

VMWare

如果您使用WMWare ESX来管理和部署虚拟化环境，请确保从ESX控制台执行以下设置以适应MongoDB操作：

1. 关闭内存膨胀

2. 为托管MongoDB数据库的虚拟机预分配和保留内存

3. 使用存储I/O控制将足够的I/O分配给 mongod 进程。

4. 通过设置来保证托管MongoDB的计算机的CPU资源 CPU保留

5. 考虑使用ParaVirtual I/O驱动程序。 参见 知识库文章.

Amazon Web Services

有关如何使用Amazon Web Services设置MongoDB的文档，请查看 配置AWS集成 MongoDB网站上的文章。

部署前保护MongoDB

查看此帖子的日期 安全部署MongoDB 以获取有关如何在部署之前保护数据库配置安全的建议。

Dispatcher

为Dispatcher选择操作系统

要为MongoDB部署正确提供服务，托管Dispatcher的操作系统必须正在运行 Apache httpd 版本2.4或更高版本。

此外，请确保内部版本中使用的所有库都是最新的，以最大限度地减少安全影响。

Dispatcher配置

典型的Dispatcher配置提供的请求吞吐量是单个AEM实例的10到20倍。

由于Dispatcher是无状态的，因此它可以轻松地水平缩放。 在某些部署中，必须限制作者访问某些资源。 建议您将Dispatcher与创作实例一起使用。

在不使用Dispatcher的情况下运行AEM需要由其他应用程序执行SSL终止和负载平衡。 此为必填字段，因为会话必须与创建会话的AEM实例具有相关性，这个概念称为粘性连接。 原因是要确保对内容的更新显示最小的延迟。

查看 Dispatcher文档 了解有关如何配置的详细信息。

其他配置

粘性连接

粘性连接可确保同一个用户的个性化页面和会话数据全部在AEM的同一个实例上撰写。 此数据存储在实例上，因此来自同一用户的后续请求将返回到同一实例。

建议为将请求路由到AEM实例的所有内部层启用粘性连接，鼓励后续请求访问同一AEM实例。 这样做有助于最大限度地减少延迟，否则当内容在实例之间更新时，延迟会非常明显。

长过期

默认情况下，从AEM Dispatcher发送的内容具有Last-Modified和Etag标头，且没有指示内容已过期。 此流程可确保用户界面始终获得最新版本的资源。 它还意味着浏览器执行GET操作以查看资源是否已更改。 因此，它可能会导致HTTP响应为304（未修改）的多个请求，具体取决于页面加载。 对于未过期的资源，设置Expires标头并删除Last-Modified和ETag标头会导致缓存内容。 而且，在满足Expires标头中的日期之前，不会提出进一步的更新请求。

但是，使用此方法意味着在Expires标头过期之前，没有合理的方法导致资源在浏览器中过期。 要缓解此工作流，可以将HtmlClientLibraryManager配置为对客户端库使用不可变URL。

这些URL保证不会更改。 当URL中包含的资源正文更改时，更改将反映在URL中，以确保浏览器请求资源的正确版本。

默认配置向HtmlClientLibraryManager添加一个选择器。 作为选择器，资源将完整地缓存在Dispatcher中。 此外，此选择器还可用于确保正确的过期行为。 默认选择器遵循 lc-.*?-lc 模式。 以下Apache httpd配置指令可确保符合该模式的所有请求都以合适的过期时间提供。

Header set Expires "Tue, 20 Jan 2037 04:20:42 GMT" "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header set Cache-Control "public, no-transform, max-age=267840000" "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset ETag "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset Last-Modified "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset Pragma "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"

无嗅探

在发送内容时没有使用内容类型，因此许多浏览器尝试通过读取内容的前几个字节来猜测内容类型。 此方法称为“探查”。 探查会打开一个安全漏洞，因为可以写入存储库的用户可能会上传没有内容类型的恶意内容。

因此，建议添加 no-sniff 标头到Dispatcher提供的资源。 但是，Dispatcher不缓存标头。 因此，它意味着从本地文件系统提供的任何内容的内容类型由其扩展决定，而不是使用来自其原始AEM服务器的原始内容类型标头。

如果已知的Web应用程序从不提供没有文件类型的缓存资源，则无法安全地启用嗅探。

您可以启用“无探查”，包括：

Header set X-Content-Type-Options "nosniff"

它也可以有选择地启用：

RewriteCond %{REQUEST_URI} \.(?:js|jsonp)$ [OR]
RewriteCond %{QUERY_STRING} (callback|jsonp|cb)=\w+
RewriteRule .* - [E=jsonp_request:1]
Header set X-Content-Type-Options "nosniff"  env=jsonp_request
Header setifempty Content-Type application/javascript env=jsonp_request

内容安全策略

默认Dispatcher设置允许打开内容安全策略，也称为CSP。 这些设置允许页面从受浏览器沙盒的默认策略约束的所有域加载资源。

最好限制可从何处加载资源，以避免从不受信任或未验证的外部服务器将代码加载到JavaScript引擎中。

CSP允许对策略进行微调。 但是，在复杂的应用程序中，开发CSP标头时必须小心，因为过于受限的策略可能会破坏部分用户界面。

大小调整

有关大小调整的详细信息，请参见 硬件大小调整准则.

MongoDB性能优化

有关MongoDB性能的一般信息，请参见 分析MongoDB性能.

已知限制

并发安装

虽然MongoMK支持在单个数据库中并发使用多个AEM实例，但不支持并发安装。

要解决此问题，请确保先使用单个成员运行安装，然后在第一个成员完成安装后添加其他成员。

页面名称长度

如果AEM在MongoMK持久性管理器部署上运行， 页面名称限制为150个字符。