技术文档 - PostgreSQL 性能优化之 fsync 参数

Posted 2023-04-23

参考技术A 目 录

总 结

PostgreSQL 通过调用系统 fsync() 或者其他使得事务内容写入到物理磁盘，这样可以保证操作系统或者数据库出现宕机后，仍然可以恢复到某一个一致性的状态。理论上讲 PostgreSQL 的 fsync 功能关闭，可以实现性能的提升，但是带来的影响就是需要承担数据的丢失，因为出现系统宕机或者数据库崩溃的时候有一些数据是没有落盘的。

本文将验证 fsync 参数的性能影响，以及参数关闭时数据库宕机后的影响。

数据量：1000W

fsync 参数：on

初始化表：user_info

pgbench 压测

pgbench 结果

pgbench 压测

pgbench 结果

数据量：1000W

fsync 参数：off

初始化表：user_info

pgbench 压测

pgbench 结果

pgbench 压测

pgbench 结果

通过对比发现，将 fsync 改为 off，对于读 TPS，参数 fsync 的影响不大，对于写 TPS，性能有一定提升。

现在验证参数关闭时数据库宕机后的影响

首先，使用将数据库性能跑起来

然后，模拟服务器断电

之后，启动数据库

提示信息：比致命错误还过分的错误。

结果：数据库无法启动，原因就是因为无法找到一个有效的 checkpoint 记录，这就是因为 fsync 设置为 off，由于数据库异常宕机导致。可以通过使用 pg_resetxlog 恢复数据库，但是会造成部分数据无法找回，数据丢失；也可以通过备份恢复，同样也会丢失部分数据。

fsync 参数对于读 TPS 的性能影响不大，对于写 TPS 的性能有一些影响，设置为 off，写 TPS 性能有一定提升，但是存在数据库宕机后无法正常启动，即使恢复后启动数据库，也会有数据丢失的很大风险。因此生产环境非必要时，不要将此参数设置为 off，还是使用默认的 on 比较稳妥。

web前端分享：性能优化之文档碎片处理

有不少同学在前端开发面试的时候会被问到性能优化的相关问题，做好优化是一件非常重要的事情，今天小千就来给大家介绍一下文档碎片的处理方式。

性能优化之文档碎片

一般情况下，在操作DOM结构的时候,经常会说非常消耗性能，原因是我们向DOM中添加新的元素，DOM会立刻更新。也就是添加一次更新一次，如果添加100个节点，那么就得更新100次，很浪费资源呀。

每次操作DOM节点插入时，浏览器会触发重排重绘，为了提高效率，要尽可能的减少重排重绘，即应该减少DOM节点的插入。有一种方法就是利用文档碎片去做。

文档碎片是一种虚拟的DOM节点，存在于内存中，跟实际的DOM节点之间没有关系，当我们需要给一个节点中插入多个子节点的时候，完全可以将多个子节点先插入到文档碎片中，所有子节点都放到文档碎片中后，再将文档碎片插入到实际的节点中，这样就减少了很多节点直接插入到父节点中的次数了，也就是本来多次触发重排重绘的操作，有了文档碎片中，只需要触发一次重排重绘了。

文档碎片创建：document.createDocumentFragment()

这个方法返回一个文档碎片，即虚拟DOM节点。对于文档碎片的插入操作，跟实际的DOM节点操作是一样的。

通过循环创建了5个p标签，每创建一个就将这个p标签。创建插入的节点较少时，页面会立马发生变化。但一旦创建插入的节点多了以后，这个过程就可能会十分缓慢，例如插入10000条。

当然也可以提前先创建一个空节点，将所有子节点插入到这个节点中，然后再将这个节点插入到目标节点中。

但这样会在list中多嵌套一个div标签。而文档碎片的意义跟这个div一样，但不会多嵌套标签。

经过测试，在各个浏览器下性能明显得到提高。

以上就是文档碎片处理的优化方案了，大家赶紧去自己的项目中测试一下吧。最后欢迎对web前端开发培训感兴趣的同学

本文来自千锋教育，转载请注明出处。