OB内存管理

内存结构

  • OBserver的内存,由两个参数共同决定,如果没有设置memory-limit参数,可使用内存为物理内存乘以memory-limit-percentage.反之由前一个参数的值决定.这两个参数可通过show parameters 参数查看
  • 在确定为0Bserver内存后,还需要去掉system_memory的值(500租户),才是Sys租户和普通租户可用的内存,租户使用内存可通过gv$unit视图查看.
  • 500租户内存包含所有真实组户都会共享的部分资源或公用功能的内存,比如多租户的管理、CLog写缓存、CLog管理、存储IO管理、Schema管理、分区GC、RPC buffer等,

租户内存

  • memstore 用于存储数据,memstore-limit-percentage参数值决定,默认为租户最小内存的50%
  • kvcache是由可动态伸缩内存组件组成,包括
  • 除此之外,还有很多内存组件,包括 Plan Cache(执行计划缓存)、SQL Area(SQL 执行期内存)、SQL AREA(SQL解析和优化使用的内存)、SQL AUDIT、Other AREA(分区事务管理等使用的内存)

memstore

  • memsore中存储了分区的增量数据
  • 有两种数据索引结构btree和hash
  • memtable 以MvccRow的形式来存储多版本数据,数据版本以TransNode的形式构成链表,其中锁和事务相关信息也存储在其中

分层转储机制

  • active memtable 冻结[freeze_trigger_percentage(70%)] frozen memtable 转储 mini sstable 压缩[minor_compact_trigger(2)] minor sstable 合并[major_compact_trigger(5)] major sstable
  • 转储可开启并发

enable_parallel_minor_merge 分区内并行转储,默认开启
_mini_merger_concurrency mini转储线程数
minor_merge_concurrency 通用转储线程数
merge_thread_count 合并线程数

  • 写入限流

writing_throttling_trigger_percentage 限流阀值,默认100不限流
writing_throttling_maximum_duration 限流后可提供服务的时间

KVCache

  • clog、location cache、scheme cache、stat cache 也是采用 kvcache ,而且是系统租户的?500|sys?
  • block cache

[user block cache] 类似于 Oracle 的 Buffer Cache,缓存具体的数据微块,每个微块都会解压后装载到 Block Cache 中, 因此每个 cache 大小都是变长的。
[Block Index Cache] 缓存微块的索引,因为每个 SSTable 虽然以宏块组织,但是 2M 的粒度对于用户查询来说往往粒度太大,因此需要根据用户查询的范围在宏块中定位实际需要的微块,微块索引就是描述对每个宏块中所有的微块的范围,当需要访问某个宏块的微块时,需要提前装载这个宏块的微块索引,因为进行了前缀压缩,因此大小通常较小,并且在 OceanBase 数据库内部给予其较高优先级,因此一般命中率较高。

  • row cache

[user row cache] 针对每个 SSTable 缓存具体的数据行,在进行 Get/MultiGet 查询时,可以将对应查到的数据行放入 Row Cache,这样在下次走到对应行查询时就可以避免多次二分定位对行的查找。
[fuser row cache] 在 LSM-Tree 架构中, 同一行的修改可能存在于不同的 SSTable 中,OceanBase 数据库为了进一步优化存储占用,每次用户的更新都只会存储增量数据,因此在查询时需要对各个 SSTable 查询的结果进行熔合,当用户不再触发新的更新时,这个熔合结果对查询都是一直有效的,因此 OceanBase 数据库也提供了对于熔合结果缓存的 Fuse Row Cache,更大幅度支持部分用户的热点行查询。

  • bloom filter cache

OceanBase 数据库的 BloomFilter 是构建在宏块上的,根据用户实际空查率按需自动构建,当一个宏块上的空查次数超过某个阈值时,就会自动构建 BloomFilter,并将 BloomFilter 放入 Cache。

  • tmp block cache
  • kvcache 淘汰

组合内存到达90%
cache_wash_threshold(4G)全局内存剩余

> alter system flush location cache;
> alter system flush kvcache tenant='';

SQL Work Area

  • 内存为 [min_memory] * [ob_sql_work_area_percentage]
  • 主要用于SQL执行算子处理的中间结果集

enable_sql_operator_dump 集群级配置,控制在SQL中间结果是否落盘,默认true
_has_area_size 租户配置 默认100M
_sort_area_size 租户配置 默认128M

WORK AREA

工作线程局部缓存[PM]

  • ObPageManager的数据结构,每个SQL工作线程都有,针对sql短生命周期
  • workarea_size_policy 默认开启,自动调整工作区内存参数

plan cache

  • 内存为 [min_memory] * ob_plan_cache_percentage
  • 计划缓存失效

schema变更
统计信息变化
outline 计划绑定变更
SPM计划演进

  • 刷新计划
#sys租户下
alter system flush plan cache global tenant='';
alter system flush plan cache sql_id='' databases='' tenant='' global;
#普通租户
alter system flush plan cache sql_id='' databases='' global;
  • 淘汰机制

plan_cache_evict_intervel 集群级配置项 默认30s
ob_plan_cache_evict_high_percentage 系统变量
ob_plan_cache_evict_low_percentage 系统变量

sql audit

记录sql运行信息,包括SQL请求来源、执行状态及统计信息等

  • 内存为 [min_memory] * ob_sql_audit_percentage
  • 控制开关

enable_sql_audit 集群级配置项
ob_enable_sql_audit 系统变量

sql_audit 淘汰机制

  • sql_audit 每隔 1s 会检测后台任务并根据以下标准决定是否淘汰:

    • sql_audit 内存最大可使用上限为 avail_mem_limit = min (OBServer 可使用内存 *10%,sql_audit_memory_limit)。

      • 当 avail_mem_limit 在 [64M, 100M] 范围内时, 内存使用值达到 avail_mem_limit-20M 时触发淘汰。
      • 当 avail_mem_limit 在 [100M, 5G] 范围内时, 内存使用值达到 availmem_limit*0.8 时触发淘汰。
      • 当 avail_mem_limit 在 [5G, +∞)范围内时, 内存使用值达到 availmem_limit-1G 时触发淘汰。
    • sql_audidt 记录数超过 900 万条时,触发淘汰。

  • sql_audit 根据以下标准决定是否停止淘汰:

    • 如果是达到内存上限触发的淘汰,则:

      • 当 avail_mem_limit 在 [64M, 100M] 时, 内存使用淘汰值达到 avail_mem_limit-40M 时停止淘汰。
      • 当 avail_mem_limit 在 [100M, 5G] 时, 内存使用淘汰值达到 availmem_limit*0.6 时停止淘汰。
      • 当 avail_mem_limit 在 [5G, +∞] 时, 内存使用淘汰值达到 availmem_limit-2G 时停止淘汰。
    • 如果是达到记录数上限触发的淘汰,则淘汰值达到 800 万行记录时停止淘汰。

系统表

  • gv$memory/__all_virtual_memory_info视图用于展示租户级别的内存统计信息
  • gv$memstore展示所有服务器上所有租户的Memtable内存情况
  • gv$memstore_info明细信息
  • gv$server_memstore每个server中memstore的内存使用情况
  • gv$tenant_memstore_allocator_info用于排查内存长时间未释放的问题
  • gv$table有所有包括virtual的表信
  • _all_virtual_kvcache_info kvcache内存使用情况
  • _all_virtual_sql_workeare_memory_info
  • _all_virtual_plan_cache_stat/gv$plan_cach_stat plan cache 系统表
  • gv$sql_audit/__all_virtual_sql_audit sql_audit系统表
  • gv$sysstat/_all_virtual_sysstat observer内存使用视图
  • _all_virtual_server_memory_info 内存使用情况
  • gv$tenant_memory_info / _all_virtual_tenant_memory_info 租户内存
  • _all_virtaul_tenant_ctx_memory_info 租户内ctx内存视图
  • gv$memory / _all_virtual_memory_info mod内存视图
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,830评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,992评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,875评论 0 331
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,837评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,734评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,091评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,550评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,217评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,368评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,298评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,350评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,027评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,623评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,706评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,940评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,349评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,936评论 2 341

推荐阅读更多精彩内容