PostgreSQL DirectIO开发实践

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: 在数据库开源的背景下,基于PG的DirectIO的研发方案分享。

分享人:唐成   中启乘数科技(杭州)有限公司联合创始人

正文:本文从五方面介绍了PostgreSQL DirectIO开发实践。

DirectIO的基本知识

为什么需要DirectIO?

实现DirectIO需要解决的一些问题

DirectIO和AIO的具体代码

DirectIO和AIO的使用


一、DirectIO的基本知识

image.png

DirectIO是绕过文件系统的缓存,直接把IO发到磁盘或底下,实现里有一个特点是打开一个文件的时候加一个O下划线Direct的标志。我们用代码打开这个文件,把标志加上是实现不了的。因为要求内存对齐,申请内存的虚地址要跟扇区的512的虚地址一致,如果中间开始程序就会是无效的参数,要实现DirectIO就要把IO的内存地址改到这里。

Direct IO中的一些疑问?

image.png

DirectIO有几个让人迷惑的地方:假设我们已经用了DirectIO是否还要fsync,其实很多时候还是需要的,比如文件的末尾写了一个东西文件就会变大了,

文件在原数据里面变大,如果没有fsync而只有DirectIO的话,原数据的大小没变。如果把大数据变回之前的小数据,后面的数据就会丢失。很多时候fsync是去不掉。

DirectIO对齐大小到底是有多大呢?有些人认为就是4k,但实际上是512个扇区的大小,但如果底下SID是4k要对齐,那对齐大小是多大?


二、为什么需要DirectIO?


image.png

在PG里有double buffering的问题,假设PG有共享内存的数据块做缓存,实际上PG是基于文件系统的cache,cache的数据块占两块内存,内存利用率不高。

如果一个机器是128G内存,给了buffering 64G,实际上64G在PG的共享内存有个cache,但文件系统也有cache。Linux操作系统的文件系统的缓存大小是无法控制的,有很多参数可以小,但是文件系统缓存不能超过总内存的10%,这是不好控制的。

在最佳实践PG的数据库如何配置呢?double buffering有两种方案:一种是把PG的buffering设的很小,比如16g以下,更多内存让文件系统去做。另一种是把buffering设置的很大,文件系统很小,文件系统会把剩余的内存给吃掉。

如果把PG内存数据化缓存的性能提高,文件系统的性能会变低,实测结果会高10%左右。如果把buffering设置的很小,更多的使用文件系统,稳定性会变差,对云厂商来说更严重。

DirectIO可以提高性能, bufferingIO用程序化内存把IO放在这里,发给操作系统后,操作系统拷贝到内核,内存会变慢。如果使用DirectIO后,可以直接把数据块以DMA的方式发送到存储设备中。

如果用操作系统的bufferingIO去写脏数据,有时候性能会大起大落太不稳定了,用DirectIO后就更平稳了。

还有潜在的实现了WAL的并发写。


三、实现DirectIO需要解决的一些问题


1)DirectIO的几座大山


image.png

如果把IO的模型直接换成DirectIO把内存对齐,通常会变慢,从快变慢就难以接受。以前大批量导数据的时候,数据给操作系统缓存来做会比较快,现在真实的落盘后就变慢了。

代码需要修改的地方还有很多,以前PG是基于bufferingIO设计的,有人做的补丁文件,是否合到社区主干版本里还没有定。对齐没做好会导致内存浪费。


2)使用AIO


image.png

在AIO没有返回前可以干一些其他的事情,过一会儿再看IO是否回到AIO模型了,以前在Linux里面有IO的模型,对PG来说可以自己实现。PG有了AIO后,就能专注干lO的现实进程,如果没有AIO,很多性能问题就比较难解决。


四、DirectIO和AIO的具体代码


1)一些链接

image.png

这里有一些链接给到大家,感兴趣的可以来看。


2)提供的内存对齐的函数

image.png

代码里除了palloc,现在加了两个对齐函数,底下lO对齐,在PG里面函数最多用的是申请一个块大小8k的内存,函数返回来指针边界对齐。下次发IO时,right函数就不会报无效参数,如果是点IO的模式就已经提供了这两个函数。


3)内存分配原理

image.png

在PG里有一个内存管理的Memorytext,用来防止内存泄露。只要SQL执行完相关的内存,Context每次申请一块内存时,又把前面八个字节指针,按照现在4k的内存搭起来对齐,增加了对齐的分配模式,它前面加的Context,从操作系统获得一个可能是没对齐的指针,再往后找一个位置对齐返回。这个代码是这样实现的。


4)代码修改: palloc内存对齐

image.png

这个地方要改的地方挺多的,把polloc跟IO相关的全改成对齐,否则IO就会报错。


5)代码修改:对齐内存的palloc_io_aligned的使用

image.png

这里就不详细介绍了。


6)代码修改:共享内存的对齐 buf_init.c

image.png

我们申请过共享内存8k缓存,缓存从8k直接写下去,边界内存也在对齐,在共享内存这里要改一下,在前面加一行对齐。这里比以前多加了一个块儿,因为要对齐又怕会浪费一个数据块,改一下共享内存就对齐了。


7)代码修改: 在md.c中加O_DIRECT

image.pngimage.png

最重要的是打开文件的时候要把O_DIRECT加上,对PG还有PG_O_DIRECT,它和标志位是一样的。


五、DirectIO和AIO的使用


1)配置参数

image.png

在使用实现时加了一些参数,第一个参数是io_data_direct,默认设置成off,如果把它设置成on,就开启功能了。最重要的参数io_method,默认是worker,io_wal_concurrency默认是32,如果用这个刷日志最多是32个,io_wal_direct默认值是off,如果想使用就设置成on,日志初始化块,把参数可以设置成on,后面还有参数要填,比如worker线程的个数。


2)配置参数之 io_method

image.png

以前内核没有这些代码时,要处理单线程百万的这个IO时,对CPU占用率比较高,每个核能处理百万是达不到的。以前英特尔黑科技叫DVDK,它实现的存储层叫SPDK,SPDK把不要的操作系统内核绕过去叫kernel by pass,现在的内核io_uring也有赶超的架势了。io_uring 和 SPDK 的性能非常接近,它的通用性比较好,同时完爆 liba_io。


3)异步IO的worker进程

image.png

打开后可以看到八个io worker在后台进程里,看起来有点像MySQL的数据库,MySQL有io线程的,但这个版本是否合进去社区还在讨论。

 

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
3月前
|
存储 SQL Cloud Native
深入了解云原生数据库CockroachDB的概念与实践
作为一种全球领先的分布式SQL数据库,CockroachDB以其高可用性、强一致性和灵活性等特点备受关注。本文将深入探讨CockroachDB的概念、设计思想以及实践应用,并结合实例演示其在云原生环境下的优越表现。
|
3月前
|
Cloud Native 关系型数据库 大数据
CockroachDB:云原生数据库的新概念与实践
本文将介绍CockroachDB,一种先进的云原生数据库,它具备分布式、强一致性和高可用性等特点。我们将探讨CockroachDB的基本原理、架构设计以及在实际应用中的种种优势和挑战。
|
4月前
|
存储 关系型数据库 MySQL
存储成本最高降至原来的5%,PolarDB分布式冷数据归档的业务实践
国内某家兼具投资理财、文化旅游、票务为一体的大型综合型集团公司,2015年成立至今,由于业务高速发展,业务数据增长非常快,数据库系统屡次不堪重负。该公司数据库运维总监介绍,他们目前业务压力比较大的是票务和订单系统,他们的平台每天新增几千万的订单数据,订单的数据来自于各个终端,近几年每个月以300G的数据规模在高速增长,由于数据不断增加,数据库系统迄今为止迭代过了3次。
|
6月前
|
SQL 缓存 关系型数据库
PolarDB-X 混沌测试实践:如何衡量数据库索引选择能力
随着PolarDB分布式版的不断演进,功能不断完善,新的特性不断增多,整体架构扩大的同时带来了测试链路长,出现问题前难发现,出现问题后难排查等等问题。原有的测试框架已经难以支撑实际场景的复杂模拟测试。因此,我们实现了一个基于业务场景面向优化器索引选择的混沌查询实验室,本文之后简称为CEST(complex environment simulation test)。
|
7月前
|
存储 SQL 关系型数据库
AnalyticDB PostgreSQL构建一站式实时数仓实践
本文介绍通过 AnalyticDB PostgreSQL 版基于实时物化视图,构建流批一体的一站式实时数仓解决方案,实现一套系统、一份数据、一次写入,即可在数仓内完成实时数据源头导入到实时分析全流程。
1885 5
AnalyticDB PostgreSQL构建一站式实时数仓实践
|
8月前
|
分布式数据库 调度 数据库
直播预告 | PolarDB-X 备份恢复原理与实践
备份恢复是生产级数据库必不可少的功能,而PolarDB-X 作为一款分布式数据库,备份数据的全局一致也是最基本的要求。本期分享将介绍PolarDB-X 开源版备份恢复功能的背景与原理,以及如何使用 PolarDB-X Operator 实现备份调度。
直播预告 | PolarDB-X 备份恢复原理与实践
|
8月前
|
关系型数据库 测试技术 分布式数据库
PolarDB | PostgreSQL 高并发队列处理业务的数据库性能优化实践
在电商业务中可能涉及这样的场景, 由于有上下游关系的存在, 1、用户下单后, 上下游厂商会在自己系统中生成一笔订单记录并反馈给对方, 2、在收到反馈订单后, 本地会先缓存反馈的订单记录队列, 3、然后后台再从缓存取出订单并进行处理. 如果是高并发的处理, 因为大家都按一个顺序获取, 容易产生热点, 可能遇到取出队列遇到锁冲突瓶颈、IO扫描浪费、CPU计算浪费的瓶颈. 以及在清除已处理订单后, 索引版本未及时清理导致的回表版本判断带来的IO浪费和CPU运算浪费瓶颈等. 本文将给出“队列处理业务的数据库性能优化”优化方法和demo演示. 性能提升10到20倍.
597 4
|
10月前
|
存储 SQL 运维
亿视电子基于PolarDB-X打造能源数字基座实践
本文整理自浙江亿视电子技术有限公司的技术总监韩毅在ScaleFlux × PolarDB 线下meetup中的分享。
|
11月前
|
存储 关系型数据库 API
|
11月前
|
存储 关系型数据库 Linux