Warning: file_get_contents(/data/phpspider/zhask/data//catemap/5/sql/75.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
优化PostgreSQL以实现快速测试_Sql_Database_Performance_Postgresql_Database Tuning - Fatal编程技术网

优化PostgreSQL以实现快速测试

优化PostgreSQL以实现快速测试,sql,database,performance,postgresql,database-tuning,Sql,Database,Performance,Postgresql,Database Tuning,对于一个典型的Rails应用程序,我正在从SQLite切换到PostgreSQL 问题是PG的运行速度变慢了。 在SQLite上大约需要34秒,而在PG上大约需要76秒,这比SQLite慢了2倍多 P> >现在我想应用一些技巧来使规范的性能与SQLite 一致,没有代码修改(最好是通过设置连接选项,这可能是不可能的)。 从我的头脑中可以明显看出以下几点: RAM磁盘(OSX上RSpec的良好设置将很好地显示) 未标记的表(是否可以应用于整个数据库,这样我就不必更改所有脚本?) 正如您所理解

对于一个典型的Rails应用程序,我正在从SQLite切换到PostgreSQL

问题是PG的运行速度变慢了。
在SQLite上大约需要34秒,而在PG上大约需要76秒,这比SQLite慢了2倍多

<> P> >现在我想应用一些技巧来<强>使规范的性能与SQLite 一致,没有代码修改(最好是通过设置连接选项,这可能是不可能的)。 从我的头脑中可以明显看出以下几点:

  • RAM磁盘(OSX上RSpec的良好设置将很好地显示)
  • 未标记的表(是否可以应用于整个数据库,这样我就不必更改所有脚本?)
正如您所理解的,我不关心可靠性和其他方面(DB在这里只是一个一次性的东西)。
我需要最大限度地发挥PG的作用,并尽可能快地使其

最佳答案理想情况下会描述实现这一点的技巧、设置以及这些技巧的缺点

更新:
fsync=off
+
full\u page\u writes=off
仅将时间减少到约65秒(~-16秒)。良好的开端,但远未达到34岁的目标

更新2:I但性能增益在误差范围内。所以这似乎不值得

更新3: 我发现了最大的瓶颈,现在我的规范运行得和SQLite规范一样快

问题是执行截断的数据库清理。显然SQLite的速度太快了

为了“修复”它,我在每次测试之前打开一个事务,并在测试结束时回滚它

大约700次测试的一些数字

  • 截断:SQLite-34s,PG-76s
  • 事务处理:SQLite-17s,PG-18s
SQLite的速度提高了2倍。
速度提高4倍。首先,始终使用最新版本的PostgreSQL。性能的提高总是会到来,所以如果您正在调整旧版本,那么您可能是在浪费时间。例如,当然还添加了仅索引扫描。即使是很小的发布也应始终遵循;看

不应该做的

如果丢失一个表空间,整个数据库可能会被损坏,如果不做大量工作,就很难使用。与仅使用
未标记的
表并使用大量RAM进行缓存相比,这几乎没有什么优势

如果您真的想要一个基于ramdisk的系统,
initdb
通过在ramdisk上添加一个新的PostgreSQL实例,在ramdisk上创建一个全新的集群,这样您就拥有了一个完全可丢弃的PostgreSQL实例

PostgreSQL server配置 测试时,您可以为配置服务器

这是PostgreSQL中设置的唯一可接受用途之一。这个设置告诉PostgreSQL不要为有序写入或任何其他令人讨厌的数据完整性保护和崩溃安全问题而烦恼,允许它在断电或操作系统崩溃时完全丢弃数据

不用说,除非您将Pg用作可从其他地方重新生成的数据的临时数据库,否则绝不应在生产中启用
fsync=off
。当且仅当您正在关闭fsync时,也可以关闭fsync,因为它不再有任何好处。请注意,
fsync=off
full\u page\u写入操作
在集群级别应用,因此它们会影响PostgreSQL实例中的所有数据库

对于生产使用,您可以使用
synchronous\u commit=off
并设置
commit\u delay
,因为您将获得与
fsync=off
相同的许多好处,而不会带来巨大的数据损坏风险。如果启用异步提交,您确实有一个丢失最近数据的小窗口,但仅此而已

如果您可以选择稍微更改DDL,还可以使用第9.1+页中的
unlocked
表,以完全避免WAL日志记录,并在服务器崩溃时以删除表为代价获得真正的速度提升。没有使所有表取消标记的配置选项,必须在
创建表期间设置该选项。除了用于测试之外,如果数据库中的表中充满了生成的或不重要的数据,而这些数据中包含了安全所需的内容,那么这种方法也很方便

检查日志,查看是否收到过多检查点的警告。如果你是,你应该增加你的收入。您可能还希望调整检查点\完成\目标以平滑写操作

调整
shared_buffers
以适应您的工作负载。这取决于操作系统,取决于机器的其他情况,需要一些尝试和错误。违约率极为保守。如果在PostgreSQL 9.2及以下版本上增加
共享_缓冲区
,则可能需要增加操作系统的最大共享内存限制;9.3和更高版本改变了他们使用共享内存的方式以避免这种情况

如果您使用的是一对只做大量工作的连接,请增加
work\u mem
,以便为排序等提供更多的RAM。请注意,过高的
work\u mem
设置可能会导致内存不足问题,因为它是按排序的,而不是按连接的,因此一个查询可以有多个嵌套排序。如果可以在
EXPLAIN
中看到排序溢出到磁盘或使用(推荐)记录,则只需增加
work\u mem
,但更高的值也可能让Pg选择更智能的计划

正如另一张海报所说,如果可能的话,最好将xlog和主表/索引放在单独的硬盘上。分开的分区是毫无意义的,你真的需要分开的驱动器。如果使用
fsync=off
运行,这种分离的好处要小得多;如果使用
未标记的表,这种分离几乎没有好处

最后,调整查询。确保您的
随机页面成本
s