PostgreSQL 痛点的解决方案

PostgreSQL是一个很老的系统，可以追溯到1996；它被很多用户在多种操作系统上运行。因此，PostgreSQL开发商被他们可以添加的Linux指定代码的数量所限制。它是基于合作进程的，没使用线程。系统 V 共享内存用于进程间通信。重要的是，PostgreSQL维护它自己的内部缓冲区，但也使用 I/O 缓冲来读写磁盘数据。这种缓冲的组合导致了 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()函数，这样做的话，可能大量正在工作着的进程就会变得非常慢。

这种做法看起来不错，但同时也可能在反方向上移动了一些页，PostgreSQL可能想要从它自己的缓冲器中移除一个干净的页，但是却在页高速缓冲器里留下了一份拷贝。可能的情况，或许是一个实际上没有引发I/O的特殊的写操作，或许是一个将物理页面转换成页高速缓冲器的系统调用。这些在表面上的讨论是挺多的，但是却没有那一部分的讨论是能给出确切的结论的。

复归

对于PostgreSQL的用户来说另外一个问题是经常遇到的，在最近的一些内核特性可能造成了的执行性能上的问题。举个例子，透明大型分页（transparent Huge page）特性对于PostgreSQL的工作负载来说没有任何好处，而且它还明显地变慢了。显然，大量时间都被用在那些努力运行着的严密代码上了，但是它们却没有真正产生空闲大型分页（Huge page）。 于是，在许多的系统中，当透明大型分页（transparent Huge page）功能被关掉，可怕的性能问题就简单地消失了。

Mel Gorman回答：如果压缩正在损害性能，这将是一个缺陷。话虽如此，他在相当长的一段时间内没有发现任何透明大型分页的缺陷。还有就是，他说，已经发布了一个限制进程数量的补丁，该补丁能在任何给定的时间内执行压缩。不过，这个补丁的代码并没有被合并，因为没有人的工作负载曾经遇到因太多进程运行压缩而引发问题。他认为，也许是时候重新审视那个特定的补丁。

另一个痛点来源于区域回收功能，即使整个系统并不缺乏内存，该功能也将在内核中从一些区域回收页。区域回收减慢了PostgreSQL的工作负载。通常最好是在PostgreSQL服务器上简单的禁用此功能。Andres指出他已经作为顾问多次处理和区域回收有关的性能问题。这对他来说是一个很好的赚钱方式。不过如果能修复这些问题，这将是一件好事。

Mel 说，区域回收模式是在假设系统中所有进程都纳入到一个单一的NUMA节点下而写的。这个假设已经不再有意义了；它很过时了，他说，这个选项的默认值改为“off”。看起来房间里没人反对这个想法，所以可能会在不久的将来发生一点变化。

最后，PostgreSQL的开发者指出，在一般情况下，内核升级往往是可怕的。Linux内核的性能特点在一个发布版到下一个版本之间往往有很大的不同；这使升级成了一个不确定的事情。有些关于寻找运行PostgreSQL基准的新内核的讨论，但没有得到明确结论。作为一个整体，虽然，这两个项目的开发者高兴怎么谈话出来；如果没有其他的事，这代表了两个项目之间通信的一种新高度。