昨天的案例讲了PG的DOUBLEBUFFERING导致SQL执行快慢的问题。有朋友在问除了OracleDatabases之外是否还有很多类似的方式读取文件。这种DoubleBuffering技术是不是很落后，必须改进？其实只要使用文件系统，数据库在读取数据时不使用DIO，就会存在DOUBLEBUFFERING的问题，早期的Oracle也有类似的问题。上图很清楚的说明了DOUBLEBUFFERING的问题。对于写入，因为是先写入缓存，然后OS再将缓存写入磁盘，中间会有一定的性能损失，但是对于现代数据库来说，只有REDO/WAL是需要强一致性写入的，而写入的数据文件不会阻塞数据库的读写访问，所以这种性能损失是可以接受的。而且在现代硬件上，IO延迟已经大大降低，这个损失不是什么大问题。对于读操作，涉及到我们的数据库共享缓冲池如何设计。较新的MySQL版本在支持DIO的操作系统上默认使用DIO读取文件，所以设置足够大的innodbbuffer就可以了。使用默认配置不存在类似DoubleBuffering的PG问题。PG数据库用户对此争论不休，PG官方文档也建议shared_buffers不要太大，留出足够的内存给OS优化IO。为什么PG还坚持这种模式来实现数据库缓冲呢？事实上，维护一个巨大的共享缓冲区并保持并发读写性能是非常困难的。针对不同的应用场景，缓冲策略会有所不同。如果数据经常被一些大表扫描访问，数据就不会被重复访问。这种情况下如果加载到sharedbuffer中再访问，会增加sharedbuffer的latch（对于PG来说是轻量级锁）争用导致数据库性能问题，增加热块冲突的延迟，这得不偿失。Oracle在处理此类问题时，也是采用直接路径读取的方式来解决的。目前使用MySQL的大型数据库比较少。即便一些MySQL库的总容量达到了数TB，但被频繁访问的数据实际上只有几百M，所以不容易遇到共享缓冲区性能带来的整体性能问题。问题。在一些比较大的PG数据库上，我们遇到过很多高并发读写场景下LWLOCK带来的性能问题。在我之前的文章中提到过，从算法的角度来看，PGsharedbuffers的算法效率会略低于Oracle的DBCACHE，而这些现象似乎就是对此的一种佐证。在某些场景下，不将sharedbuffer设置的过大，使用OSFILECACHE作为辅助，也是一种优化策略。就像前几天讨论的数据库，它可以处理一些复杂的事情，不容易做好。交给操作系统去做。在一些应用系统中，将大部分OS内存配置为sharedbuffer也很好，但这种方式访问??冷数据的性能会有所打折扣。使用pgfincore等工具进行预热，可以大大提高一些大表扫描的常规分析任务的执行效率。今天不讨论sharedbuffer配置策略的问题。我以前写过几篇关于这方面的文章。有兴趣的可以上公众号搜索。今天我们讨论一个由于双缓冲机制导致多个PG指标指示失败的问题。在PG的sharedbuffer的不同配置策略下，物理读在某些情况下可能不是真正的物理读，而是“假物理读”。所以对于PG数据库来说，sharedbufferpool命中率和物理读这两个指标会有严重的误解。在Oracle数据库中，我们会对物理读突然增加产生性能告警。因为这可能意味着某些SQL执行异常，或者IO负载突然增加，这可能会导致一些不确定的数据库性能问题。这个故障模型在D-SMART中也复制到PG数据库中，但是这个故障模型的告警在PG数据库中可能不如在Oracle中有效。因为不同的sharedbuffer配置策略可能会导致物理读有时并不是真的从存储设备中读取数据，而是从FILECACHE中读取数据。很有可能这种物理读的突然增加并不是需要告警的故障，而是一种预先设计好的正常现象。如果不分青红皂白地报警，就会不准确。作为一个通用的运维工具产品，我们无法预测用户的应用场景和设计理念，所以这个故障模型必须要修改。数据库缓存命中率指标也有类似的问题。在某些场景下，数据库缓存命中率低可能是PG数据库设置的场景，不需要报警。如果还是模仿Oracle的预警方式，可能会产生大量的误报。如果新增的“数据库物理读”大部分都产生了操作系统的物理读，那么就需要告警，如果新增的“数据库物理读”没有大幅度增加操作系统的物理IO，那么这种现象可能这是数据库参数配置的正常现象，应该自动排除。数据库缓冲区命中率的理解也是如此。当数据库缓冲区的命中率较低时，我们不需要直接报警，而是看操作系统的总IO是否有明显增加。如果操作系统的总IO没有明显增加，那么数据库缓存命中率下降应该是正常的。这两种可以在Oracle中使用的故障模型必须进行优化，以增加实际物理读会显着增加的条件。但是如何描述大量增加呢？这里需要用到异常检测算法。在D-SMART中，指标1000105的含义是关键指标异常。这是一个复合指标，是对基础指标进行异常检测生成的。例如30000100是操作系统的IOPS指标。当该指标急剧上升时，说明IO异常增加。因此，在两种故障模型中，可以加入规则1000105[30000100]=4，使告警更加准确。
