Question

我执行了以下查询

select employee_name, max(employee_dept) as dept
from employeeDB 
where employee_name is not null and employee_name != ''
group by employee_name
order by employee_name asc
limit 1000

并收到错误ERROR: XX000: Disk Full。

通过执行以下查询进行调查后发现我有941 GB的可用空间和5000 GB的已用空间。

select
  sum(capacity)/1024 as capacity_gbytes, 
  sum(used)/1024 as used_gbytes, 
  (sum(capacity) - sum(used))/1024 as free_gbytes 
from 
  stv_partitions where part_begin=0;

有人可以建议如何减轻这一挑战，以便我能获得理想的结果吗？

Answer 1

可用磁盘空间对于Redshift上的查询执行非常重要。这就是VACUUM流程很重要并且应该定期执行的原因，特别是对于经常发生删除的表。

你最近有没有对你的桌子进行过预览？

检查VACUUM documentation并查看StackOverflow上的Amazon Redshift at 100% disk usage due to VACUUM query问题。

Answer 2

+-------+              +-------+
|-------|              |-------|
||10 kb||              ||25 kb||
+-------+              +-------+
|xxxxxxx|              |xxxxxxx|
|xxxxxxx|              |xxxxxxx|
|xxxxxxx+------------->+xxxxxxx|
+-------+              |xxxxxxx|
||10 kb||              |xxxxxxx|
+-------+              |xxxxxxx|
|xxxxxxx|              |xxxxxxx|
|xxxxxxx|              |xxxxxxx|
+-------+              |xxxxxxx|
||05 kb||              |xxxxxxx|
+-------+              +-------+

看看上面的表示。我们假设xxxxxxx表示磁盘上的占用空间，而数字表示可用的空白空间。

两种情景均代表25 kb的空置空间。但是在 case 1 中，如果你必须插入（或执行操作）需要连续的内存分配，比如说15 kb，你就不可能做到这一点。尽管可以使用25 kb的空间，但由于这不是连续的，因此可能会得到Memory / Disk Full Error，因此空间将浪费或将分配给内存要求非常低的任务。

在案例2 中，可以使用一块连续内存。需要~25kb内存的任务可以轻松执行，

这不仅适用于Redshift或DBMS;任何远程涉及内存管理的东西都适用，包括操作系统。

导致此类内存分区的原因（称为碎片）？

碎片是由在磁盘上不断创建和删除（修改）文件引起的。当占用空间的文件被删除时，它会在那里创建一个间隙的内存孔。大小小于存储器孔的文件可占用该空间，或者空间将浪费。

应该做什么？

碎片整理！在您的特定情况下，Amazon Redshift会为VACUUM表和/或架构提供配置。您可能有足够的磁盘空间，但没有足够的连续内存，引擎可以分配给您执行的任务。

Redshift查询：错误xx000磁盘完全redshift

2 个答案: