Como posso solucionar o uso excessivo ou o esgotamento de espaço em disco com o Amazon Redshift?

Resolução

Os altos erros de uso do disco podem depender de vários fatores, incluindo:

• Chave de distribuição e classificação
• Processamento de consultas
• Tabelas com colunas VARCHAR(MAX)
• Alta compressão de colunas
• Operações de manutenção
• Produtos cartesianos com uniões cruzadas
• Tamanho mínimo da mesa
• Blocos Tombstone
• Copiar um arquivo grande

Chave de distribuição e classificação

Examine o estilo de distribuição, a chave de distribuição e a seleção da chave de classificação da tabela. Tabelas com distorção de distribuição (em que mais dados estão localizados em um nó do que nos outros) podem causar um nó de disco cheio. Se você tiver tabelas com estilos de distribuição distorcidos, altere o estilo de distribuição para uma distribuição mais uniforme. Observe que a distribuição e a distorção da linha podem afetar a distorção do armazenamento e o conjunto intermediário de linhas quando uma consulta está em execução. Para mais informações sobre chaves de distribuição e chaves de classificação, consulteManual avançado de design de tabelas da engenharia do Amazon Redshift: preâmbulo, pré-requisitos e priorização.

Para determinar a cardinalidade da sua chave de distribuição, execute a seguinte consulta:

SELECT <distkey column>, COUNT(*) FROM <schema name>.<table with distribution skew> GROUP BY <distkey column> HAVING COUNT(*) > 1 ORDER BY 2 DESC;

Observação: para evitar uma etapa de classificação, use colunas SORT KEY na sua cláusula ORDER BY. Uma etapa de classificação pode usar memória excessiva, causando um vazamento de disco. Para obter mais informações, consulte Trabalhar com chaves de classificação.

No conjunto de resultados filtrado, escolha uma coluna com alta cardinalidade para ver sua distribuição de dados. Para mais informações sobre o estilo de distribuição da sua tabela, consulte Escolher o melhor estilo de distribuição.

Para ver como os blocos de banco de dados em uma chave de distribuição são mapeados para um cluster, use o utilitário table_inspector.sql do Amazon Redshift.

Processamento de consultas

Analise qualquer memória alocada a uma consulta. Enquanto uma consulta está sendo processada, seus resultados intermediários podem ser armazenados em blocos temporários. Se não houver memória livre suficiente, as tabelas causarão um vazamento de disco. Conjuntos de resultados intermediários não são compactados, o que afeta o espaço disponível em disco. Para mais informações, consulte Memória insuficiente alocada à consulta.

O Amazon Redshift usa como padrão uma estrutura de tabela com distribuição uniforme e sem codificação de coluna para tabelas temporárias. Porém, se você estiver usando a sintaxe SELECT...INTO, use uma instrução CREATE. Para obter mais informações, consulte As dez principais técnicas de ajuste de performance para o Amazon Redshift. Siga as instruções na Dica 6: Resolver o uso ineficiente de tabelas temporárias.

Se não houver memória suficiente alocada para sua consulta, você poderá ver uma etapa em SVL_QUERY_SUMMARY em que is_diskbased mostra o valor “true”. Para resolver esse problema, aumente o número de slots de consulta para alocar mais memória à consulta. Para obter mais informações sobre como aumentar temporariamente os slots de uma consulta, consulte wlm_query_slot_count ou ajustar o WLM para executar workloads mistas. Você também pode usar regras de monitoramento de consultas do WLM para combater cargas pesadas de processamento e identificar consultas com uso intenso de E/S.

Tabelas com colunas VARCHAR(MAX)

Verifique as colunas VARCHAR ou CHARACTER VARYING para ver os espaços em branco no final que podem ser omitidos quando os dados são armazenados no disco. Durante o processamento da consulta, os espaços em branco à direita podem ocupar todo o comprimento da memória (o valor máximo para VARCHAR é 65535). É uma prática recomendada usar o menor tamanho de coluna possível.

Para gerar uma lista de tabelas com larguras máximas de coluna, execute a seguinte consulta:

SELECT database, schema || '.' || "table" AS "table", max_varchar FROM svv_table_info WHERE max_varchar > 150 ORDER BY 2;

Para identificar e exibir as larguras reais das colunas largas da tabela VARCHAR, execute a seguinte consulta:

SELECT max(octet_length (rtrim(column_name))) FROM table_name;

Na saída dessa consulta, valide se o tamanho é apropriado para seu caso de uso. Se as colunas tiverem o comprimento máximo e excederem suas necessidades, ajuste o comprimento para o tamanho mínimo necessário.

Para obter mais informações sobre design de tabelas, consulte as Práticas recomendadas do Amazon Redshift para criar tabelas.

Alta compressão de colunas

Codifique todas as colunas (exceto a chave de classificação) usando ANALYZE COMPRESSION ou o recurso de otimização automática de tabelas no Amazon Redshift. O Amazon Redshift fornece codificação de colunas. A prática recomendada é usar esse recurso, mesmo que ele aumente a performance de leitura e reduza o consumo geral de armazenamento.

Operações de manutenção

Certifique-se de que as tabelas do banco de dados do Amazon Redshift sejam analisadas e limpas regularmente. Identifique todas as consultas que estão sendo executadas em tabelas que não possuem estatísticas. Evitar que consultas sejam executadas em tabelas que não possuem estatísticas impede que o Amazon Redshift escaneie linhas de tabelas desnecessárias. Isso também ajuda a otimizar o processamento das suas consultas.

Observação: operações de manutenção, como VACUUM e DEEP COPY, usam espaço de armazenamento temporário para suas operações de classificação. Portanto, espera-se um aumento no uso do disco.

Por exemplo, a consulta a seguir ajuda a identificar estatísticas desatualizadas no Amazon Redshift:

SELECT * FROM svv_table_info WHERE stats_off > 10 ORDER BY size DESC;

Além disso, use o comando ANALYZE para visualizar e analisar estatísticas da tabela.

Para mais informações sobre operações de manutenção, consulte o utilitário de esquema Analyze & Vacuum do Amazon Redshift.

Produtos cartesianos com uniões cruzadas

Use o plano EXPLAIN da consulta para procurar consultas com produtos cartesianos. Produtos cartesianos são uniões cruzadas que não estão relacionadas e podem produzir um número maior de blocos. Essas uniões cruzadas podem resultar em maior utilização da memória e em mais tabelas espalhadas no disco. Se as uniões cruzadas não compartilharem uma condição JOIN, elas produzirão um produto cartesiano de duas tabelas. Cada linha de uma tabela é então unida a todas as linhas da outra tabela.

Uniões cruzadas também podem ser executadas como uniões de loops aninhados, que levam mais tempo para serem processadas. Uniões de loops aninhados resultam em picos no uso geral do disco. Para mais informações, consulte Identificar consultas com loops aninhados.

Tamanho mínimo da mesa

A mesma tabela pode ter tamanhos diferentes em grupos diferentes. O tamanho mínimo da tabela é então determinado pelo número de colunas e se a tabela tem uma SORTKEY e o número de fatias preenchidas. Se você tiver redimensionado recentemente um cluster do Amazon Redshift, poderá ver uma mudança no seu armazenamento geral em disco. Isso é causado pela alteração no número de fatias. O Amazon Redshift também conta os segmentos de tabela usados por cada tabela. Para obter mais informações, consulte Por que uma tabela em um cluster do Amazon Redshift consome mais ou menos espaço de armazenamento em disco do que o esperado?

Blocos Tombstone

Blocos Tombstone são gerados quando ocorre uma transação WRITE em uma tabela do Amazon Redshift e há uma leitura simultânea. O Amazon Redshift mantém os blocos antes da operação de gravação para manter a consistência de uma operação simultânea de leitura. Os blocos do Amazon Redshift não podem ser alterados. Cada ação de Inserir, Atualizar ou Excluir cria um novo conjunto de blocos, marcando os blocos antigos como lápides.

Às vezes, os tombstones não são limpos na fase de confirmação devido a transações de mesa de longa duração. Tombstones também podem falhar quando há muitas cargas de ETL em execução ao mesmo tempo. Como o Amazon Redshift monitora o banco de dados desde o início da transação, qualquer tabela gravada no banco de dados também retém os blocos tombstone. Se transações de tabela de longa duração ocorrerem regularmente e com várias cargas, poderão se acumular tombstones suficientes para resultar em um erro de disco cheio.

Você também pode forçar o Amazon Redshift a realizar a análise em relação aos blocos de lápide executando um comando commit.

Se houver consultas de longa duração ativas, encerre-as (e libere todos os blocos subsequentes) usando o comando commit:

begin;
create table a (id int);
insert into a values(1);
commit;
drop table a;

Em seguida, para confirmar os blocos tombstone, execute a seguinte consulta:

select trim(name) as tablename, count(case when tombstone > 0 then 1 else null end) as tombstones from svv_diskusage group by 1 having count(case when tombstone > 0 then 1 else null end) > 0 order by 2 desc;

Copiar um arquivo grande

Durante uma operação COPY, você pode receber um erro de disco cheio mesmo se houver armazenamento suficiente disponível. Esse erro ocorrerá se a operação de classificação for transferida para o disco, criando blocos temporários.

Se você encontrar uma mensagem de erro de Disco cheio, verifique a tabela STL_DISK_FULL_DIAG. Verifique qual ID de consulta causou o erro e os blocos temporários que foram criados:

select '2000-01-01'::timestamp + (currenttime/1000000.0)* interval '1 second' as currenttime,node_num,query_id,temp_blocks from pg_catalog.stl_disk_full_diag;

Para conhecer mais práticas recomendadas, consulte Práticas recomendadas do Amazon Redshift para carregamento de dados.

Solução de problemas adicionais

Verifique a porcentagem de espaço em disco na guia Performance do console do Amazon Redshift. Para cada nó do cluster, o Amazon Redshift fornece espaço em disco extra, que é maior do que a capacidade nominal do disco.

Se você notar um aumento repentino na utilização, use STL_QUERY para identificar as atividades e trabalhos em execução. Observe quais consultas estão sendo executadas no momento de um vazamento de disco:

select * from stl_query where starttime between '2018-01-01 00:30:00' and '2018-01-01 00:40:00';

Observação: atualize os valores com a hora em que o pico ocorreu.

Para identificar as 20 principais consultas de vazamento de disco, execute a seguinte consulta:

select A.userid, A.query, blocks_to_disk, trim(B.querytxt) text from stl_query_metrics A, stl_query B where A.query = B.query and segment=-1 and step = -1 and max_blocks_to_disk > 0 order by 3 desc limit 20;

Visualize o valor da coluna blocks_to_disk para identificar o vazamento de disco. Encerre consultas que estão vazando demais, se necessário. Em seguida, aloque memória adicional às consultas antes de executá-las novamente. Para obter mais detalhes, consulte STL_QUERY_METRICS.

Para determinar se suas consultas estão gravando corretamente em um disco, execute a seguinte consulta:

SELECT q.query, trim(q.cat_text)
FROM (
SELECT query,
replace( listagg(text,' ') WITHIN GROUP (ORDER BY sequence), '\\n', ' ') AS cat_text
FROM stl_querytext
WHERE userid>1
GROUP BY query) q
JOIN (
SELECT distinct query
FROM svl_query_summary
WHERE is_diskbased='t' AND (LABEL ILIKE 'hash%' OR LABEL ILIKE 'sort%' OR LABEL ILIKE 'aggr%' OR LABEL ILIKE 'save%' OR LABEL ILIKE 'window%' OR LABEL ILIKE 'unique%')
AND userid > 1) qs
ON qs.query = q.query;

Esse comando também identifica consultas que estão sendo transferidas para o disco.

---

Informações relacionadas

Performance

Visão geral do sistema Amazon Redshift