Postgresql IO 对于PG的 过去，现在 ， 未来 （3--直面问题与结果展示和PG16新东西）

此文来自于Andres Freund,PG社区资深开发，探讨IO对于PG方面的问题。此翻译和文字来自于视频，因为部分英文听的比较费劲，所以可能有失误的地方，尽请见谅。

——————————————————————————————

正文

接上期

说到 checkpoint 这里有很大一部分使用了AIO，这是一个非常容易就能转换到background writer的部分，但是这里有一个难啃的骨头就是wal的写部分，在这个部分我们还是用了非常正统的kernel方式需要在写完成后进行确认，确认数据已经re-flush到磁盘，这里是不能f-sync or f-data以及更有效利用现代存储设备的方式，因为使用O_DSYNC的方式，有点像一点数据就要通过cache进行操作并进行确认，而f_data sync或者fsync的方式就如同告知立即将脏数据写到磁盘的cache中，然后就操作完毕了，没有确认的过程。

然后我们的vacuum,这里有顺序扫描BITMAPINDEX扫描。

我们来说说改进的结果，这里有趣的是我们之前的WALWRITE是1.5G每秒的写入速度，现在经过改进后，在我的桌面电脑上4个PCIE设备我可以达到硬件的极限，12G每秒，但是实际上是我不能产生超过这个数字的wal 数据了。

在我们改进后，顺序扫描也比以前要快，因为我们不在需要内存的COPYING的工作了从kernel page cache中，并且我们可以用dma直连的方式从驱动器到shared buffer,节省了更多的CPU资源，并且有2.5倍的提高。这意味着我们可以有更多的扩展性，尤其在使用并行后的顺序扫描。

我们有并行COPYING ，如数据加载在并行的方式将会非常的快，实际上我并没有非常高的预期在我们的高压力下的写操作的OLTP，但实际上还是不错的，主要得原因是我们可以同时写wal的多个部分，同时采用了并发的去刷新数据到磁盘。但不足的是buffer刷新的部分，我们在同一时间只能写一个页面，让我们有一个比较奇怪的性能魔咒，新能的提升非常的缓慢，因为每次间隔写入数据页面只能部分被填充，只有当写入的数据量足够多的情况下，并发才有效，同时写入页面的不能被拆分，可能如果我们能像别的数据库填充一部分数据就可以刷新，或者这里如果我们能将每个页面能从8KB到4KB的化，当然这是一个自欺欺人的方案。或者我们将空余的部分都填充成0 从后台来完成这个任务。

另外一个人提出问题，不知道是通过什么方式，反正听不大清楚，回答的部分我挑拣一些对读者有用的部分。

回答：我希望我有更好的方法但是截至到目前为止我没有，另外在使用压缩日志的方式进行的时候，出现了问题，让情况更糟糕了

下面我们来说说什么还没有在POSTGRESQL 中进行工作，我们还没有合并在大多数场合下不会引起性能问题的部分，但是他们已经到了需要被重视的角度，举个例子，文件的扩展很难不产生问题，postgres 被设计成一个表一个文件的模式而不是众多表在一个文件的模式，现在的模式对比其他数据库存成一个文件的模式有很多优势，如速度优势，和扩展的优势，但是也意味着我们在处理这些表的时候，要获知那些表的数据文件需要进行扩展了，但这就产生了一些延迟的问题，我们称之为扩展延迟（操作系统称之为），因为我们都使用缓冲，而实际数据在写入文件是是不知道缓冲或内存中有多少数据的，尤其在我们直接去扩展文件的时候。同时在一个新表的建立后，bluk 插入大量的数据的情况下，可能仅仅如需要几个KB，但是我们确分配了更大的空间，但这样操作增加了访问的开销。

同时在很多情况下，并没有为DIO 写进行优化，尤其在做异步回写的情况下，另外还有一些问题是需要在操作系统层面进行潜在的优化和调整的。举例在你使用IO 缓冲区的情况下你可能会感觉很慢，这是因为有上下文的切换造成的，这很容易让你的CPU 达到100的使用率，因为一部分CPU在做切换的操作，如果你有很大的吞吐量的情况下，突然有轻微的性能下降的情况，就是上面提到的，所以需要操作系统或者特定的操作系统的版本上进行调优，还有一个问题就是我们的缓冲区替换了算法的问题，包含 ring buffer 在使用dio的时候也都显示出来一些需要注意的地方。

另一种问题是相关性的问题，单独一个事情不是问题，而将其混合后就产生了弱点，举例我们在进行VACUUM的情况下是不会产生IO瓶颈的，但是我在处理VACUUM的同时，有事务需要进行COMMITTED，如果此时没有足够的缓冲和内存，那么这两个任务会频繁的进行加载和卸载，这就产生了性能的问题，很可能你CPU 90% 的时间都在干无用功。

下一步中我们需要优化的我们的文档，因为实际的原型设计和我们实现后的有一定的差距的，终究实际工作和学术研究之间有很大的不同。更大的问题在于我们需要在算法的基础上做一些东西，目前最主要的一个算法是关于预取数据的部分，但我们需要更多的时间来进行取样和做一些适应性的工作，通过使用预取算法用更短的时间用通过真实的硬件的方式来解决，而不是去调整参数。

另外在索引的部分也需要进行优化，我们不知道优先去读那些索引的页面所以这部分也需要优化，同时我们也需要更好的buffer交换的算法，关于预取数据我们可能需要启发式的算法的方式来进行数据的处理，尤其是对周边数据的预取当我们做index scan 像取 heapdata或者表数据，当然我知道这些是有缺点的，以上是我认为我们需要尽快要做的，OK 我说完了。

——————————————————————————————

基于部分硬件，系统，和数据库核心知识的缺失，以上的翻译一定有不完善，甚至是错误的部分，有一部分是听不清，或不理解，或者按照字面的意思去翻译的，如有问题请联系我，帮助我。感谢您的帮助。

另后面还有一些提问的环节，基于印度味道的英语的提问，这边就暂时不翻译了，尽请见谅。