struct dicentry void *key next void *val
struct dict type private dicth[2] ;
内存管理三种层次
用户管理层 运行时库管理 操作系统层(结构图)
操作系统层:
SMP(UMA) NUMA
SMP受制内存扩展 NUMA 受制与远端访问
虚拟地址空间的两种结构
Old && new 32 64 新
mmap && brk
do_mmap_pgoff do_brk 类似
brk : 线性的增加
运行时库: OOM系统
几种主流内存分配方法
C pool 引用计数 垃圾回收
C :通用性强,问题明显
pool : 优:
分配回收飞快,基本不会主动OOM,符合标准
劣:
明确可知的分配模式,第三方库兼容性差,通用性差
引用计数:优:
实现简单,易于使用
劣:
循环数据结构难已处理,减缓分配,额外处理引用。占用数据结构比较靠前的位置,这个地方价值非常高
垃圾收集:
优:永远不必担心双重释放之类的问题
劣:比其他形式的内存分配更慢
另:TCmalloc 小内存 8 整数倍 大内存4K对齐 线程友好 每个线程缓存一些存储块
引出CSAPP上的一个例子blblblblblblblblblblbbl
1.首先数据结构
使用块 和 空闲块
2.整个容器的组织形式,画结构图
bins fast_bins unsorted_bin top_chunk mmaped_chunk
3.分配响应的具体步骤
@首先获取锁,其中一个分配区,默认先主
@对齐处理用户的需求
@如果小于64 从small bins 中获取,否则先找fast bins
@合并fast 中能合并的,进unsorted, 然后整合到small | large
@然后在large 中按照“smallest-first,best-bins",最好有合适的不然就切割,边角料回炉
@如果翻遍了所有的bin都没有找到,那就结束bin的想法,直接从top chunk 想办法。
@最终直接使用mmap
4.回收内存的基本流程
@首先获取分配区的锁
@判断空指针与否,空:直接返回
@是否是mumap 的结果,是则直接释放,判断下动态机制是否需要调整
@小与64B放到fast bins 中去,如果与top 相邻,则还有后文,否则直接返回
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@判断前一个chunk 的大小,和使用情况,合并之
@判断后一个是否top chunk 否,则判断使用情况合并之,如果大与64KB则触发fast bin 的合并机制,开始合并。放进unsorted bins 然后判断top chunk 是否可以合并。
@如果后一个直接是top chunk 就合并,然后企图收缩大小。收缩阀值128KB
5.使用mmap 的一些好与不好之处。
好:独立从系统中分配和释放。对与常生命周期的东西就很好用,不会被锁
不好:内存不可回收再利用,默认清0,页对齐很低效
6.使用注意事项
@top chunk 之前的块可能被卡死,然后内存暴增
@最好不要管理长生命周期的对象
@不要关闭分配阀值动态调整机制,不然多线程,各种缺页机制,被玩死
@多线程其实是不适合ptmalloc 的
@尽量减少程序的线程数量,避免频繁释放内存(锁,分配区)
@内存泄漏是一个非常非常可怕的问题
@调整虚拟存储子系统,防OOM
源码赏析:
结构体:1121
分配区实例:1684
一些宏定义:
获取块的大小:1310
设置标志位:1326
bins 数组分配: 1454 1477
ACID SQL NOSQL
ACID :原子 一致 隔离 持久
异常类型:
服务器宕机,网络异常,磁盘故障,超时问题,通过ACK等一些问题解决等
性能分析:
一般通过系统的吞吐能力,系统响应的时间,常用每秒的操作次数来评测性能。
可用性:99.99 52.56
一致性:越强的一致性。用起来往往稳定,
可扩展性: 可以方便,遍历的增加容量
数据分布:
哈希分布:一致性哈希环
顺序分布:类似B树,复杂度增加
数据的复制与迁移:
多个副本的存在,切换副本,读写分离。
CAP :
一致性,可用性:最大保护模式,强同步;最大性能模式,有危险;最大可用性模式,根据网络;
分区可容忍性
容错机制的设计
故障检测:
心跳方式,租约方式
故障恢复:切换副本
可扩展性
查看原文:http://zmrlinux.com/2016/03/13/%e5%86%85%e5%ad%98%e7%9b%b8%e5%85%b3%e8%ae%b2%e5%ba%a7%e5%a4%a7%e7%ba%b2/