总的来说,Big Memory 方法对于开发人员和企业来说是有益的,因为它改变了. NET 平台上的高性能计算模式。 传统的 Big Memory 系统是以 C/C ++ 风格的语言构建的,主要处理字符串和字节数组。 但是当专注于底层数据结构时,就很难解决实际的业务问题了,所以我们要专注于 CLR 对象。 内存堆允许开发人员根据对象实例进行思考,并与具有属性、编码、继承和其他 CLR 原生功能的数亿个实例配合工作。
与语言无关的对象模型不同,就像一些软件供应商(如支持 Java 和. NET 的供应商)所提出的那些,它们引入额外的变换以及需要额外流量 / 上下文切换 / 序列化的所有进程外解决方案。相反,我们将讨论进程内的本地堆或类 "堆" 对象,或者是在托管代码中的大型字节数组中的对象。这些对象对于 GC 来说是不可见的。
为什么有人会使用几十或几百 GB 的 RAM 呢?以下是 Big Memory Pile 技术的一些已验证过的用例。
首先是缓存。在电子商务后端,存储着数十万种用来显示为详细目录列表的产品。每种产品可能有数十种变体。当在单个屏幕上构建一个展示 30 多个产品的目录视图时,即使是单个用户使用渐进式加载滚动页面,也需要很快速地获取到这些对象。为什么不使用 Redis 或 Memcached?因为在同一个进程中做相同的事情,可以节省网络流量和序列化开销。将网络数据包转换成对象可能是非常昂贵的操作过程。如果要持有数十万种产品及其变体,您是否会使用字典
另一个缓存用例是 REST API 服务器,可以将约 5000 万个很少更改的 JSON 向量序列化为 UTF8 编码的字节数组。大约 1024 字节的数组可以直接发送到 Http 流中,使得网络瓶颈处在 80,000 req / sec 左右。
使用复杂对象图是 Pile 的另一个完美案例。在社交应用中,需要遍历 Twitter 上的对话线程。当追踪谁在社区媒体网站上什么时候说了什么时,在内存中持有数亿个小向量的价值是无法估量的。也可以选择使用 graph DB,而在这个案例中,在同一个进程中(它是由 web MVC 应用程序托管的组件),正是使用了 graph DB。我们现在正在处理每秒 100K 以上的 REST API 调用,这受限于我们的网络连接数,并且我们将 CPU 使用率保持在较低的水平。
在这个和其他用例中,后台工作人员随着变化而异步地更新社交图表。在许多情况下,如前面提到的产品目录,它可被优先完成。但是你不应该使用只持有数据子集的普通缓存来完成更新。
Big Memory Pile 通过在大型字符数组中使用 CLR 对象图的透明序列化来解决 GC 问题,有效地 "隐藏" 了 GC 可获取范围内的对象。然而并不是所有的对象类型都需要完全序列化, 字符串和字节数组对象会被写入堆中,因为缓冲区会绕过所有的序列化机制,在 6 核主机上每秒可完成超过 6 百万次 64 字的字符串插入。
这种方法的主要优点是其实用性。现实生活中的案例,在使用原生 CLR 对象模型时已显示出惊人的整体性能,因为不需要创建专用 DTO,这样可以节省开发时间,而且因为不需要创建中间过程所需的额外副本,运行速度也会更快。
总的来说,Pile 将大部分 I/O 绑定代码转换成 CPU 限制代码。通常情况下,异步(具有 I/O 绑定)实现的典型案例是 100%的同步线性代码,这种代码更加简单,并且在单个服务器上执行多个 100K 操作 / 秒时性能更好,因为 Task 和其他异步 / 等待的实现有隐藏开销(参见这里和这里)。
内存中的处理过程是快速和容易实现的,但是当进程重新启动时,数据集会丢失,这个数据集通常(几十到几百 GB)是很大的。从原始数据源拉出所有数据可能是非常耗时的,那是在重新启动后无法承受的时间开销。
为了解决这个问题,我们添加了内存映射文件(MMF)来支持使用标准的. NET 类:MemoryMappedFile 和 MemoryMappedViewAccessor。现在,我们使用 MemoryMappedViewAccessor 实例和一些低级技巧来直接使用指针访问数据,而不是使用字节数组作为内存段的后备存储,所有这些操作都使用标准的 C#来完成,不需要 C ++ 参与,以保持一切简单,特别是构建链。
通过 MemoryMappedViewAccessor(MMFMemory 类)写入内存直接修改 OS 层中的虚拟内存页面。如果操作系统不能将这些页面交换到磁盘中,便会尝试将这些页面放在物理 RAM 中。将 Pile 写入 MMF 的一个很好的功能是,进程在关闭后马上重启则不需要从磁盘重新读取所有内容。即使在进程终止之后,操作系统仍将映射到进程地址空间的页面保留。启动时,MMFPile 可以以比从磁盘重新读取更快的方式访问 RAM 中的页面。
请注意,由于在 MMFMemory 类中完成了非托管代码的上下文切换,MMFPile 的性能会比 DefaultPile 慢(基于字节数组)。
以下是一些测试结果:
基准测试插入 200,000,000 字符串 [32] 12 个线程:
(机器:Intel Core I7 3.2 Ghz,6 Core,Win 7 64bit,VS2017,.NET 4.5)
DefaultPile
24 秒 @ 8.3 百万次插入 / 秒 = 8.5 Gb 内存; 全 GC <8 ms
MMFPile
正如你所看到的,MMF 解决方案确实有额外的开销。由于非托管的 MMF 转换,吞吐量较低,并且一旦从磁盘安装 Pile,则耗时与使用磁盘数据预先分配给 RAM 的内存量成比例。然而,你不需要等待加载整个工作集,因为 MMFPile 在 Pile.Start() 之后立即可用于写入和读取,数据的全部负载将需要时间开销,在上面的示例中 8.5 GB 数据集需要 48 秒的时间才能在中档 SSD 的 RAM 中预热。
基准测试插入 200,000,000 个 Person 对象(具有 7 个字段)12 个线程:
DefaultPile
85 秒 @ 2.4 百万次插入 / 秒 = 14.5 Gb 内存; 全 GC <10ms
MMFPile
其他改进
从上一次在 InfoQ 上发表文章以来,我们对 NFX.Pile 做了很多改进:
原始分配器 / 分层设计
Pile 的实现可以更好地分层,从而可以将字符串和字节数组直接从 RAM 的较大的连续块中直接写入 / 读取。整个序列化机制完全绕过字节数组,从而可以使用 Pile 作为一个原始的字节数组分配器。
- var ptr = pile.Put("abcdef"); //这将绕过所有序列化程序
- //并使用UTF8Encoding代替
- var original = pile.Get(ptr)as string;
性能提升
由于引入了试图避免多线程竞争的滑动窗口优化实现,段分配逻辑已经被修改,并且在多线程插入期间提高了 50%以上的性能。此外,在大多数情况下字符串和字节数组完全绕过串行器会提高速度近 5 百万次插入 / 秒(200%以上的改进)。
枚举
利用 IEnumerable <PileEntry> 接口实现,可以获得整个堆的内容。 PileEntry 结构体如下:
- foreach(var entry in pile){
- Console.WriteLine("{0} points to
- {1} bytes".Args( entry.Pointer,
- entry.Size));
- var data = pile.Get(entry.Pointer);
- …
- }
缓存持久化
出于性能原因,缓存的默认模式是 "推测的"。在这种模式下,即使存在足够的内存,散列码冲突也可能导致较低的优先级项从高速缓存中弹出。
缓存服务器可以以 "持久" 模式存储数据,工作方式更像普通的字典。因为持久化模式需要在 bucket 中进行重新排列,所以相比推测模式会慢 5-10%。对于大多数应用程序来说是难以察觉的。但是需要根据特定的情况进行测试从而确定最佳实现方式。
- //为所有表指定TableOptions,将表持久化
- cache.DefaultTableOptions = new TableOptions("*")
- {
- CollisionMode = CollisionMode.Durable
- };
原地对象突变和预分配
可以在现有 PilePointer 地址改变对象。新的 API Put(PilePointer ...)允许在现有位置放置不同的有效载荷。如果新的有效载荷不适合现有的块,那么 Pile 将创建一个内部链接到新位置(* nix 系统中的一个文件系统链接),有效地使原始指针指向新的位置。删除原始指针将删除链接及其所指向的内容。别名是完全透明的,并在读取时产生目标有效载荷。
还可以通过在调用 Put()时指定 preallocateBlockSize,为有效负载预分配更多的 RAM。
- //堆中存储链表的实现
- public class ListNode {
- public PilePointer Previous;
- public PilePointer Next;
- public PilePointer Value;
- }...private IPile m_Pile; //big memory pile
- private PilePointer m_First; //list head
- private PilePointer m_Last; //list tail
- ...
- //将Person实例追加到堆中存储的人员链接列表
- //返回最后一个节点
- public PilePointer Append(Person person) {
- var newLast = new ListNode {
- Previous = m_Last,
- Next = PilePointer.Invalid,
- Value = m_Pile.Put(person)
- };
- var existingLast = m_Pile.Get(m_Last);
- existingLast.Next = node;
- m_Pile.Put(m_Last,existingLast); //在现有的ptr m_Last中进行编辑
- m_Last = m_Pile.Put(newLast); //向尾部添加新节点
- return m_Last;
- }
更多信息,请参阅我们的视频:.NET Big Memory Object Pile - 在 RAM 中使用数百万个对象
来源: http://www.infoq.com/cn/articles/Big-Memory-Part-3