如何解决Amazon RDS PostgreSQL实例的DiskFull错误？

本文介绍了如何解决Amazon RDS PostgreSQL实例的DiskFull错误？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我们有一个非常小的数据库，用于在Amazon RDS实例中存储一些关系数据。PostgreSQL引擎的版本为12.7。

在同一区域的AWS中有许多lambda函数，它们访问此实例以插入记录。在此过程中，还使用了一些联接查询。我们使用心理Copg2 Python库与数据库进行交互。由于数据量非常小，所以我们使用了一个t2的小实例，存储空间为20 GB，CPU为1。然而，在生产中，使用了t2.Medium实例。尚未启用弹性伸缩。

最近，我们开始遇到此数据库的问题。在lambda函数运行一段时间后，它们会在某一时刻超时。这是因为数据库返回响应的时间太长，或者有时会抛出磁盘已满错误，如下所示：

DiskFull could not write to file "base/pgsql_tmp/pgsql_tmp1258.168": No space left on device

我已经参考了本文档以确定原因。Troubleshoot RDS DiskFull error

以下是用于检查数据库文件大小的查询：

SELECT pg_size_pretty(pg_database_size('db_name'));

此查询的响应大小为35 MB。

SELECT pg_size_pretty(SUM(pg_relation_size(oid))) FROM pg_class; 上述查询的输出为33MB。 正如我们所看到的，DB文件大小非常小。但是，在检查临时文件的大小时，我们看到以下内容：

SELECT datname, temp_files AS "Temporary files",temp_bytes AS "Size of temporary files" FROM pg_stat_database;

如果我们查看临时文件的大小，它大约是18.69 GB，这就是数据库抛出DiskFull错误的原因。

为什么PostgreSQL实例在查询完成后不删除临时文件？即使重启实例，临时文件大小也是相同的(尽管这不是一个可行的解决方案，因为我们希望数据库自己删除临时文件)。另外，我如何避免DiskFull错误，因为我可能希望运行更多与数据库交互的lambda函数。

仅为了解更多信息，我提供了一些在CPU利用率和可用存储空间

数据库速度减慢时拍摄的RDS监控图表：

因此，我猜我们可能需要启用自动伸缩，因为CPU利用率达到83.5%。如果有人分享一些见解并帮助解决DiskFull错误并确定为什么不删除临时文件，我将不胜感激。

lambda函数对数据库运行的联接查询之一是：

SELECT DISTINCT scl1.*, scl2.date_to AS compiled_date_to FROM logger_main_config_column_name_loading JOIN column_name_loading ON column_name_loading.id = logger_main_config_column_name_loading.column_name_loading_id JOIN sensor_config_column_name_loading ON sensor_config_column_name_loading.column_name_loading_id = column_name_loading.id JOIN sensor_config_loading AS scl1 ON scl1.id = sensor_config_column_name_loading.sensor_config_loading_id INNER JOIN ( SELECT id, hash, min(date_from) AS date_from, max(date_to) AS date_to FROM sensor_config_loading GROUP BY id, hash ) AS scl2 ON scl1.id = scl2.id AND scl1.hash=scl2.hash AND scl1.date_from=scl2.date_from WHERE logger_main_config_loading_id = %(logger_main_config_loading_id)s;

如何优化此查询？在循环中运行较小的查询会更快吗？

推荐答案

pg_stat_database不显示当前临时文件的大小和数量，它显示累积的历史数据。因此，自上次重置统计数据以来，您的数据库有145个临时文件。

查询完成后，无论查询成功还是失败，都会立即删除临时文件。

您会收到该错误，因为您有一些恶意查询，这些查询会写入足够的临时文件来填充磁盘(可能是一些忘记的联接条件)。为避免空间不足，请将postgresql.conf中的参数temp_file_limit设置为合理的值，然后重新加载PostgreSQL。