You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

现有问题：

  1. 用户设置活跃的partition比较麻烦
  2. 有无乱序情况的最佳配置不一样
  3. PrimitiveArrayPool内存占用没考虑，容易爆内存
  4. 开启动态参数后创建时间序列经常失败
  5. 动态参数计算出的memtable偏小，chunk较小，影响查询性能
  6. 对象内存估计不准确
  7. 内存中一个时间序列点数过多，上1万，拷贝排序较慢


新策略：

目标（解决1-5）

尽量保证创建元数据成功，为保证内存不爆，可以拒绝写入

尽量在有无乱序情况下，iotdb参数不需要变化都能很好适应

让chunk大小最大化

尽量不阻塞写入

尽量不加入固定参数

RPC模块：

  • 一次请求的大小受限制 b.（防止许用户一条SQL写入1亿个点等场景；或者写了一个大于2GB的bytes[]).
  • 并发数受限制 c。


内存写入模块：

优点：

  1. 所有SG共享内存，不再对每个SG单独设置一个内存上限，因此创建序列（或今后改为序列活跃情况变化）时也不需要再更新SG；好处是内存利用率可以很高；

缺点：

  1. 部分步骤需要全局锁；目前看，假设array为k，SG info 写x延迟上报，则个memTable写入16MB后，会拿一次全局锁更新全局内存情况。


核心思想：

  • Schema和历史resource单独分配大小；下文仅考虑其余写数据部分大小。
  • 每个SG统计自身的chunk_metadata和unseal_resource大小；
  • 全局ArrayPool统计buffered和out of buffer的array大小
  • 系统统计总的大小


写入线程：

  1. 如果是非空的写入线程
    • 在 StorageEngine 中检查SystemInfo是否为reject状态；如果是，则该写入线程循环sleep 100ms（等待flush线程释放内存，system置回正常状态）再进行写入；如果等待6000ms后仍为reject状态，抛出写入异常；
    • 进入对应的StorageGroupProcessor，获取 writeLock
    • 进入对应分区的 TsFileProcessor：（1）获取已有的可写入的顺序或乱序 TsFileProcessor（2）如果没有可写入的TsFileProcessor，创建新的 TsFileProcessor
      • 统计当前写入计划新增的内存占用，增加至TspInfo和SgInfo中：（1）新测点增加 chunk_metadata（2）TEXT 类型数据（3）TVList 中增加的 PrimitiveArray（4）flush内存
      • 如果 SGInfo 增量超过阈值（storage_group_size_report_threshold=16M）
        • 向SystemInfo进行上报（将当前 TsFileProcessor 传入）；
          synchronized(SystemInfo) {
          • 更新 SystemInfo 内存占用。
          • 如果 SystemInfo 内存占用 < 总写入内存 * flush_proportion，返回 true。
          • 如果 总写入内存 * flush_proportion ≤ SystemInfo 内存占用 < 总写入内存 * reject_proportion, 执行 选择Memtable提交flush流程，返回 true。
          • 如果 总写入内存 * reject_proportion ≤ SystemInfo 内存占用, SystemInfo 置为 reject 状态， 执行 选择Memtable提交flush流程，记返回值为 flag
            • 如果 flag = true 
              • 如果 SystemInfo 内存占用 < 总写入内存，则返回 true
              • 如果 SystemInfo 内存占用 ≥ 总写入内存，直接抛 写入Reject 异常
            • 如果 flag = false，则返回 false
              }
        • 判断 向SystemInfo上报 的返回结果
          • 如果返回 false，则该写入线程循环 writeLock.condition.await(50ms) ，检查 SystemInfo 的 reject 状态如果不 reject，执行正常写入。如果等待 max_waiting_time_when_insert_blocked 后仍为reject状态，抛出写入异常
          • 如果返回 true，则执行正常写入
          • 如果捕获到 写入Reject 异常，reset SystemInfo，并继续向上抛
      • 检查 workingMemtable 的 shouldFlush，如果为true，提交 Flush 任务，并根据文件大小判断是否需要 close。
    • StorageGroupProsessor. 释放writeLock
  2. 如果是空的写入线程
    • 进入对应的 StorageGroupProcessor，获取 writeLock
    • 获取对应分区的 TsFileProcessor：如果（其 workingMemtable 不为空且 shouldFlush 为 true），则提交 flush 任务；否则直接返回。
    • StorageGroupProsessor. 释放writeLock


选择Memtable提交flush流程：

  1. 使用 PriorityQueue 对当前系统所有 memtable 按占用内存由大到小排序
  2. boolean flag = false
  3. 当前活跃内存 = SystemInfo 总内存 - SystemInfo flush内存
  4. 对 PriorityQueue 的每个 workingMemtable 逐个标记 shouldFlush，（直到标记的这些 TsFileProcessor 刷盘后 当前活跃内存 能降到 flush 阈值之下）
    1. 提交一个异步的空的写入线程（写入被标记的 Memtable 中）
    2. 判断此 workingMemtable 是否属于当前 TsFileProcessor，如果属于，flag = true
  5. 返回 flag


Flush 线程：

  1. 先更新 SystemInfo flush 内存
  2. 将 workingMemtable 移到 flushingMemtables 中


TsFile文件关闭逻辑：

  1. 一个insertPlan写入完成后，检查该TSP的 workingMemtable 的 shouldFlush 字段，如果为 true，再检查是否TsFile大小超过阈值，如果超过，flush memtable后将文件封口。
  2. TsFile关闭完成后，清空该TSPInfo，重置对应的 SGInfo 状态，并向SystemInfo报告重置后SGInfo
  3. 如果此时SystemInfo 为reject状态 且 `SystemInfo中统计的总内存 < 总写入内存 * reject_proportion`，将SystemInfo 置于正常状态

 

MTree内存控制：

注册时间序列时，如果总时间序列个数*estimate_series_size > 总内存*write_read_schema_free_memory_proportion:schema，此时拒绝注册，抛出异常。



细节：关于Array Pool中分类型的数组如何管理？

解法： 置换策略：

a. 按序列注册比例置换：

各类型数据在pool中的比例由schema中序列的数据类型比例决定。当pool中buffer已满，但是各类型的array的比例还未调整至schema中的比例时，申请（那些比例应该很高、但是buffer中还很少的）数据类型的size时，先当做OOP，待归还时逐渐将比例调好。另，为了加速比例调整，可以在此处触发flush；

按使用频度置换：

LRU缺点：有类型写入很快、有类型很慢，则抖动太厉害（慢速的加入池中，会踢出快类型的，然后还没被复用，就又被踢走了）；LFU：负载变化时适应太慢；2Q。


细节：为什么当SG的info变化超过一定阈值才向Sys汇报？

解法：为了减少全局锁。假设Sys预留1GB出来，有n个SG，那么每个SG info每增长1/n GB数据时，才需要跟全局同步一次。


细节：String/byte[] 不需要buffer池的原因。

解：当接收到客户端一个string/byte[]时，接收线程已经占用了这么多内存了，此时将该byte[]直接放到memtable里最合适（指针移动）。


细节：Array Pool中的字符型/byte[]如何管理？因为每个String的长度可能不同。

解法：Array Pool中有List<Binary[]> 用于做array的缓冲池，但是归还时，内部每个Binary均为null。此时有两种方法可选：

  1. 将String类型的数组申请每次都当做array Pool无法响应。缺点是每次都要触发2.2.2，带来全局锁。
  2. 在ArrayPool中虚拟地向Sys info汇报自身拥有不同大小的byte[] 若干个(即byte[][])，当plan中有string时，向arrayPool中申请一个可以容纳的byte[]， array Pool中有，则arrayPool做计数，认为该byte[]被借走。flush时在归还。优点是不会增加全局锁，缺点是byte[]长度变化严重时，这里内存利用率会降低。【该方法仍然需要每次都要全局锁。】
  3. 将该部分内存放入SG info中统计。


细节：TsFile什么时候关闭？

解法：指定TsFile的大小；或者由于SGInfo中Chunk_metadata过大导致刷磁盘时进行关闭。


在该方案中，只有图中红色部分是全局锁（ArrayPool， SysInfo，reject信号量）



详细计算公式：


    • WAL buffer: 一个存储组固定大小的buffer：b（永久）
    • PrimitiveArrayPool 原始类型数组缓存（永久）
      • memtable 写入数据使用
      • memtable 排序使用
      • String数组每次会清空（现状）。
    • TVListAllocator 中 TVList 对象头缓存（永久）
    • MemtablePool 中 Memtable 对象头缓存（永久）
    • flush 之后在内存中积累的 ChunkMetadata 缓存大小为 K（临时）
    • flush编码后的字节数组：一个Chunk编码后的大小（临时）


每个存储组维护 SGinfo: G

    • G=C + U + B + b (ChunkMetadata + UnsealedResources + Bytes[] + WAL)
    • 当前写入plan在该SG下的数据总内存占用为 T

当前注册的时间序列数量 N


ArrayPool维护 ArrayPoolInfo：A

    • Buffered Array 内存 B，已用B_u
    • OOP内存 O
    • A=B_u+O

系统级别维护SystemInfo：S

    • S=A+sum（G）
  1. 若写入正常，开始向working memtable中写入数据，当memtable中Array空间不足时，向Array Pool申请新的Array。array pool判断是否有已向系统报备过的该类型array（即Buffered array）
    1. 如果有Buffered array，向Array Pool申请Buffered array并写入数据；
    2. 如果没有，则需要申请OOB（out of buffered）的数组

SG个数：M

系统为delay上报预留的内存大小：R

SG上报阈值: R/M


条件：

    • available array：所有measurement都在memtable中有，且空间足够；
    • available buffered array：B > B_u && 相应数据类型的array存在；
    • 左下的update system info：G的增量大于R/M。
    • 生成reject：S>=可写入内存（或达到一定比例，如90%）
    • 左边的call for flush： S >=可写入内存*比例 （如50%）


当一个SG被拆分成多个时间分区时，将上文中的SG改为TSP。


当String类型的flush后，更新tsp中对应的内存统计量并上报给System

TsFile封口时，更新ChunkMetadata和Resource的内存统计并上报给System


文档原链接： https://shimo.im/docs/CWxXTDhvkRrHvXPx

  • No labels