PostgreSQL痛点的解决方案

***痛点的解决方案

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

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

同步缓慢

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

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

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

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

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

双缓冲技术

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

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

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

复归

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

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

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

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

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

英文原文：*** pain points

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。