我正在研究与 Java 中编写的应用程序的性能相关的一系列问题，其中包含 每天100,000次点击 ，平均每次访问2个原则数据库表（平均分配）上的5到10个读数/写作，其基数为 1到300万条记录< / strong>（我通过hibernate访问数据库）。
我的两个主表存储用户信息（大约60列varchar，integer和timestamptz），另一个链接到要显示的数据（这里有大约30列，主要是varchar，integer，timestamptz）。
我遇到的主要问题可能是我网站的 性能降低 （让我们谈谈时间加载超过5秒，显然 确实不仅仅依赖于数据库性能 ），是使用 FillFactor ，它当前是默认值100 （它始终用于数据不变......）。
显然填充因子在索引上是相同的（btree类型每2个表有10个）
目前在我的主要桌子上我做
我的数据库也由其他40个不太重要的表组成（其他3个表的用户基数相同）。
我的问题是：
数据库位于服务器专用（16GB Ram，8 Core）上，存储在SSD磁盘上（数据全天备份并在另一个存储上移动）
答案 0 :(得分：0)
您可能已经达到了内存使用量的“下降”，其中大量使用的表的整个索引不再适合共享内存，因此磁盘I / O正在减慢它的速度。通过检查磁盘I / O是否高于正常值来确认。如果是这样，请尝试增加共享内存（shared_buffers），或者如果已经达到最大值，请调整系统共享内存大小或添加更多系统内存，以便将其提高。您可能还必须开始调整临时缓冲区，工作内存和维护内存以及checkpoint_segments等WAL参数。
PostgreSQL.org上有一些性能调整提示，谷歌是你的朋友。
编辑：（解决第一条评论）内存不足的第一个症状是性能大幅下降，其他一切都是相同的。如果你在内存使用方面遇到困难，改变表填充因子不会产生影响，如果有什么事情会使w.r.t更糟。加载时间（我假设这意味着“db读取”）因为行信息将在磁盘上的更多页面上扩展，每页中都有空白空间，因此表扫描需要更多的磁盘I / O.但填充因子小于100％可以帮助UPDATE操作，但我发现调整WAL参数可以在使用索引时补偿大部分时间（除非你已经优化了这些）。最重要的是，您需要使用EXPLAIN来分析所有繁重的查询以查看有用的内容。但乍一看，我很确定这是内存问题，即使是SSD上的数据库也是如此。我们谈论了很多随机读取和随机写入，并且在经过大量随机小写操作后，很多SSD实际上比硬盘驱动器更差。