|
|
|
@ -0,0 +1,85 @@ |
|
|
|
# 可以通过不同的配置选项来限制ArangoDB的内存使用并降低CPU使用率 |
|
|
|
storage engine |
|
|
|
edge cache |
|
|
|
server statistics |
|
|
|
background threads |
|
|
|
V8 (JavaScript features) |
|
|
|
operating system / memory allocator (Linux) |
|
|
|
|
|
|
|
# 有两个功能可能会占用大量内存 |
|
|
|
Buffers & Caches |
|
|
|
WAL(Write Ahead log) |
|
|
|
|
|
|
|
# WAL和写缓冲区 |
|
|
|
RocksDB首先写入 映射到磁盘块的内存缓冲区 在某些时候， 内存缓冲区将已满必须将其写入磁盘 |
|
|
|
为了支持高写入负载， RocksDB可能会打开许多此类内存缓冲区 |
|
|
|
|
|
|
|
在正常情况下， 写缓冲区将使用1GB的内存， 如果内存紧张， 可以设置RocksDB设置 |
|
|
|
--rocksdb.max-total-wal-size 1024000 byte |
|
|
|
--rocksdb.write-buffer-size 2048000 |
|
|
|
--rocksdb.max-write-buffer-number 2 |
|
|
|
--rocksdb.total-write-buffer-size 8192000 |
|
|
|
--rocksdb.dynamic-level-bytes false |
|
|
|
|
|
|
|
以上将设置 |
|
|
|
限制未完成的内存缓冲区数量 |
|
|
|
将内存使用量限制在100MBbyte |
|
|
|
在导入或者更新的过程中， 内存消耗可能仍会更大 |
|
|
|
另外一方面这些限制将影响最大写入性能，不应该设置低于上面的数字 |
|
|
|
|
|
|
|
# 读缓冲区 |
|
|
|
--rocksdb.block-cache-size 2560000 |
|
|
|
--rocksdb.enforce-block-cache-size-limit true |
|
|
|
一旦内存缓冲区一直保存在磁盘上， 回答读取查询就意味着将他们读回到内存中， |
|
|
|
上面的选项会将缓冲区数限制为几兆字节， |
|
|
|
如果可能应将此设置为与数据集的热设置大小一样大 |
|
|
|
这些限制可能会影响查询效率 |
|
|
|
|
|
|
|
# 索引和过滤器块缓存 |
|
|
|
索引和过滤器块默认情况下不缓存， 这意味他们不计入--rocksdb.block-cache-size限制 |
|
|
|
启用--rocksdb.cache-index-and-fliter-blocks 将其包括上限中的选项 |
|
|
|
|
|
|
|
您可以启用其他选项，以避免索引和过滤器块从缓存中逐出。 |
|
|
|
|
|
|
|
--rocksdb.cache-index-and-filter-blocks` |
|
|
|
--rocksdb.cache-index-and-filter-blocks-with-high-priority |
|
|
|
--rocksdb.pin-l0-filter-and-index-blocks-in-cache |
|
|
|
--rocksdb.pin-top-level-index-and-filter |
|
|
|
|
|
|
|
# 边缓存 |
|
|
|
--cache.size 10485760 |
|
|
|
此选项将ArangoDB边缘缓存限制为10 MB。如果您没有图的用例并且不使用边集合，则可以使用最小值而不影响性能。通常，这应与热定形的大小相对应。 |
|
|
|
|
|
|
|
|
|
|
|
# 其他缓存 |
|
|
|
除所有缓冲区外，查询在执行期间还将使用其他内存，以处理数据并建立结果集。与缓冲区保留的内存相反，该内存仅在查询执行期间使用，之后将被释放。 |
|
|
|
|
|
|
|
|
|
|
|
# 查询内存使用率固定链接 |
|
|
|
默认情况下，查询将在内存中建立其完整结果。您可以使用光标逐批获取结果，但每个查询都需要先计算整个结果，然后才能检索第一个批。服务器还需要将结果保存在内存中，直到相应的游标被完全消耗或超时为止。建立完整的结果可以减少服务器不得不花费时间处理主存储器的时间。 |
|
|
|
在ArangoDB 3.4版中，我们引入了 具有某些倒置属性的流游标：减少了峰值内存使用，对集合的访问时间更长。流可以在文档级别进行，这意味着不能将其应用于所有查询部分。例如，子查询的所有结果的MERGE（）不能流式传输（该操作的结果必须完全建立）。但是，周围的查询可能符合流式传输的条件。 |
|
|
|
除了流游标之外，ArangoDB还提供了指定查询不应超过的内存限制的可能性。如果是这样，查询将被中止。在执行块之间检查内存统计信息，这些块对应于说明输出中的行。这意味着需要功能的查询可能需要更多的内存来进行中间处理，但这不会因为内存而终止查询。 |
|
|
|
您可以在AQL查询中使用LIMIT操作来减少需要检查和处理的文档数量。然而，这并不总是在幕后发生。其他操作可能会导致在应用任何限制之前计算中间结果。最近，我们向优化器添加了一项新功能：AQL中的 排序限制优化。简而言之，将SORT与LIMIT操作结合使用时，在排序过程中只能将存储的文档数量保持为后续LIMIT所需的数量。从ArangoDB v3.5.0开始自动应用此优化。 |
|
|
|
|
|
|
|
# 统计的关闭开启选项 |
|
|
|
服务器会定期收集 统计信息，并在Web界面中向您显示。即使您的应用程序由于统计信息处于闲置状态，您的查询负载也很少。您可以根据需要禁用它们： |
|
|
|
--server.statistics false |
|
|
|
|
|
|
|
# JavaScript和Foxx固定链接 |
|
|
|
使用嵌入式V8引擎在ArangoDB进程中执行JavaScript： |
|
|
|
|
|
|
|
Web界面的后端部分 |
|
|
|
Foxx应用 |
|
|
|
Foxx队列 |
|
|
|
GraphQL |
|
|
|
基于JavaScript的交易 |
|
|
|
用户定义的AQL功能 |
|
|
|
有几个V8上下文可以并行执行。您可以将它们视为线程池。它们也称为隔离株。默认情况下，每个隔离区都有几GB的堆。如果不使用JavaScript或使用很少的JavaScript，则可以限制V8： |
|
|
|
|
|
|
|
--javascript.v8-contexts 2 |
|
|
|
--javascript.v8-max-heap 512 |
|
|
|
这会将V8隔离株的数量限制为两个。所有与JavaScript相关的请求都将排队，直到其中一个隔离可用于新任务为止。它还将堆大小限制为512 MB，因此在最坏的情况下，两个V8上下文组合使用的内存不能超过1 GB。 |
|
|
|
|
|
|
|
# V8 for the Desperate |
|
|
|
|
|
|
|
|
maike
4 jaren geleden