PostgreSQL痛点的解决方案

PostgreSQL痛点的解决方案

时间:2015-06-14 11:22来源:网络整理 作者:KKWL 点击:
内核必须为广泛的工作负载而工作;它并不总是执行得象一些用户社区所希望的那么好,这可以说不足为奇。PostgreSQL关系数据库管理系统项目是一个有时感到有些冷落的社区。在响应

内核必须为广泛的工作负载而工作;它并不总是执行得象一些用户社区所希望的那么好,这可以说不足为奇。PostgreSQL关系数据库管理系统项目是一个有时感到有些冷落的社区。在响应 2014年 “Linux 存储,文件系统,和内存管理”峰会组织者的邀请时,PostgreSQL 开发商 Robert Haas,Andres Freund 和 Josh Berkus 到场来讨论了他们最痛苦的问题和可能的解决方案。

PostgreSQL是一个很老的系统,可以追溯到1996;它被很多用户在多种操作系统上运行。因此,PostgreSQL开发商被他们可以添加的Linux指定代码的数量所限制。它是基于合作进程的,没使用线程。系统 V 共享内存用于进程间通信。重要的是,PostgreSQL维护它自己的内部缓冲区,但也使用 I/O 缓冲来读写磁盘数据。这种缓冲的组合导致了 PostgreSQL 用户所经历的一些问题。

 

同步缓慢

第一个被描述的问题是关于数据如何从缓冲区高速缓存保存到磁盘上。PostgreSQL 使用了一种形式的日志记录,他们称之为“预写式日志”。变化之处首先写入到日志中;一旦日志安全的保存在磁盘上,主要的数据库块就能被回写。这个工作中很多都通过一个“检查点”进程来完成;它写入日志条目,之后将一批数据写回到磁盘上的各种文件中。这种带有日志能力的写操作相对而言小而连续;他们的工作效果不错,并且,据 Andres 所说,PostgreSQL 的开发者对系统这部分在 Linux 上的运行情况足够满意。[Robert Haas]

数据的写入则是另一回事。检查点进程调节这些写操作,从而避免 I/O 系统压倒其它一切。但是,当它开始考虑调用 fsync() 来确保数据被安全的写入,并且所有这些被调节后的写操作被立即推送到请求队列时,就导致了 I/O 风暴。据他们说,问题不是因为 fsync() 太慢,而是它太快了。它导出如此多的数据到 I/O 系统,以至于其它任何事情,包括应用程序的读请求等,都被阻塞住。这为用户带来了痛苦,同样也为 PostgreSQL 的开发者带来了痛苦。

Ted Ts'o 提问,将检查点进程限定到 I/O 可用带宽的特定百分比,是否能有帮助。但 Robert 回应说,I/O 优先级应该更好一些;检查点进程,在其它进程不需要带宽时,应该更够 100% 的使用它。使用 I/O 友好的机制(它会在 CFQ 调度器中控制 I/O 优先级)被提出,但这也有问题:它对 fsync() 调用发起的 I/O 操作不起作用。即使来自检查点进程的数据被写入(并非总是如此),当 fsync() 开始真正进行 I/O 操作时,优先级没有实施上。

Ric Wheeler 建议,PostgreSQL 开发者需要更好的控制他们写入数据的速度;Chris Mason 补充说,当产生 I/O 请求时,O_DATASYNC 选项可以用来给以更好的控制。这里的问题是,这种方式的实现要求 PostgreSQL 知道存储设备的速度。

让我们把讨论的话题放回到I/O优先。由于请求队列的维护是通过I/O调度器实现的,大部分被PostgreSQL用户所青睐的调度器都倾向于避免使用CFQ调度器(Completely Fair Queueing绝对公平调度器),或者说根本就没有实现I/O优先机制。这还不是最糟的,甚至,那些提供了I/O优先的地方还限制了请求队列的长度。一个大数据flush操作将会快速填满队列,这个时候I/O优先就会失去大部分的效应。如果没有空间去容纳这些请求队列,一个高优先级的请求将会失活,无法达到预期的高优先。看来,I/O优先并不能解决问题。

正确的解决之道看起来仍然是那样的模糊和不着边际。Ted说如果PostgreSQL的开发者能提供那种通过运行着的数据库来构建这种I/O模式的小程序,给出一种方法简单地去复现这些问题,那么,内核开发者就能尝试多种不同的方式去寻求解决之道。这样的程序可能类似于PostgreSQL的初始化配置脚本,但是一个单独的小程序是内核开发者社区更想要看到的。

双缓冲技术

PostgreSQL需要去做属于它自己的缓冲技术,因为其有很多情况下由于各种原因会使用I/O缓冲。这就会导致一个问题:数据库的数据往往会在内存中被存储两次,一次是在PostgreSQL的缓冲区,另一次是在页高速缓冲存储器(page cache)。PostgreSQL在一定程度上极大地增加了内存的使用次数,对于一个完整的系统是有害的。

大量的内存浪费行为应该被有效地消除。考虑这样一个例子,在PostgreSQL的cache上有一个脏数据(dirty buffer),它比内核所拥有的在页高速缓冲存储器上的数据要新。当PostgreSQL刷新这个脏数据时,页高速缓冲存储器被重写的这一重要过程将不会发生,因此,数据也就不同步了。在这种情况下,PostgreSQL要是能告诉内核去移除在页高速缓冲存储器上相应的页就能好了,可是,现实就是,现在没有好的API能做这件事。据安德鲁(Andres)说调用fadvise()函数的FADV_DONTNEED参数是可以的,实际上,这将引发指定的页被读出,几乎没人能很好地理解这种行为,但他们都赞成它不应该用这种方式去工作。他们也不可以在没有映射到文件处理前就使用madvise()函数,这样做的话,可能大量正在工作着的进程就会变得非常慢。

------分隔线----------------------------