我在一个ubuntu盒子（natty）上的postgres 8.4上运行一些沉重的SQL脚本做一些性能基准testing。
我正在经历一些相当不稳定的性能，尽pipe我应该是机器上唯一运行的（相同的数据可能在20米，然后40米，无特定原因）。
所以，记住我的远程DBA培训，我决定我应该刷新postgrescaching，使用sudo /etc/init.d/postgresql restart ，但它仍然摇摇欲坠！
我的问题：也许我错过了我的磁盘/操作系统中的一些caching？ 我正在使用netapp设备作为我的存储空间。 我在正确的轨道上？ 在开始调整之前，我是否还想确保获得可重复的性能？
如果您的存储设备是networking挂载的，则networking和存储设备上的活动可能会改变您的结果。 在您正在使用的configuration中涉及多个caching层。
在你的情况下，我预计O / S和netappcaching可能是因素。 更有可能的是，它是从netapp设备访问数据。
其中许多难以冲洗。 这是我的经验，冲洗caching并不是真的有用。 除非您在其他未使用的数据库/服务器上运行查询，否则有很多因素会对您的结果产生较大的影响。
即使您是系统中唯一的用户，也有定期运行并使用资源的cron作业。 如果您在相同的小时数（9:15,10：15,11：15 …）下运行testing，看看您是否得到更稳定的结果。
您可能需要设置一个munin服务器来监视您的testing服务器，并在不同的运行过程中查看是否有类似的configuration文件。 在后台运行sar可以提供关于瓶颈的有用信息。 sar由atsar包提供。
在Linux上，您可以使用sync && sysctl vm.drop_caches=3来删除pagecache，dentries和inode。