Como posso remover a dedução do meu pool sem ficar sem RAM?

Question

Eu tenho um servidor com 8 compartimentos de disco cheios de discos de 3 TB. Usando 4 vdevs espelhados de 2 discos cada, isso me dá 12 TB de armazenamento redundante.

Aqui está o problema - eu li em algum lugar que eu precisava "x GBs de RAM para cada TB de dados deduzidos" (paráfrase). Eu estupidamente aceitei isso como significando que se o meu pool contivesse principalmente dados que não poderiam ser deduzidos, ele não usaria muita memória RAM. Para meu espanto, parece que, por "dados deduzidos", ele quis dizer que todos os dados no pool que tiveram dedup foram ativados.

O resultado é que meu sistema recentemente começou a travar, presumivelmente devido à falta de memória RAM, e precisou ser redefinido. Quando percebi meu erro, achei que poderia corrigi-lo criando um novo conjunto de dados com dedução desativada, copiando todos os meus dados para o novo conjunto de dados e destruindo o conjunto de dados antigo. Por sorte, eu só enchi 35% da minha piscina. Antes de tentar isso, desativei a dedução em todos os meus conjuntos de dados.

Infelizmente, toda vez que eu tento excluir algo do conjunto de dados antigo, todos os 16 segmentos do meu sistema vão para 100% e todos os 24 GB de RAM são preenchidos de repente (vejo isso em htop ) e meu sistema é bloqueado .

Existe alguma maneira de eu sair desse buraco sem destruir minha piscina inteira e começar de novo?

    

Answer 1

Eu realmente descobri isso sozinho apenas me atrapalhando. Meu sistema estava montando automaticamente volumes ZFS no momento da inicialização. Se eu inicializasse meu sistema normalmente, ele congelaria durante a inicialização com o texto "Um trabalho de início está sendo executado para conjuntos de dados Mount ZFS ..." ou algo nesse sentido. Se eu inicializasse no modo de recuperação, ele seria inicializado corretamente e me levaria a um prompt, mas o ZFS tentaria silenciosamente montar meus conjuntos de dados em segundo plano, eventualmente, travando minha máquina após 10 a 15 minutos. Além disso, isso me impediu de fazer alterações no meu pool.

Eu superei isso desativando a tarefa do systemd zfs-mount.service e reinicializando no modo de recuperação. Agora eu poderia montar conjuntos de dados seletivamente e fazer alterações no meu pool sem bloquear a máquina.

Ainda não resolvi meu problema. Mesmo que eu tenha desabilitado a dedução, copiei todos os dados do meu conjunto de dados deduzido para um novo e deletei o conjunto de dados antigo, ainda tenho um DDT enorme:

 dedup: DDT entries 29022001, size 975 on disk, 315 in core

bucket              allocated                       referenced
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    27.7M   2.78T   2.78T   2.78T    27.7M   2.78T   2.78T   2.78T
     2    1.65K    191M    191M    191M    3.30K    382M    382M    383M
     4       71   4.27M   4.27M   4.39M      310   19.4M   19.4M   19.8M
     8      132   16.3M   16.3M   16.3M    1.18K    149M    149M    149M
    16        3   32.5K   32.5K     36K       51    537K    537K    600K
    4K        1     16K     16K     16K    6.61K    106M    106M    106M
  128K        1    128K    128K    128K     146K   18.3G   18.3G   18.3G
 Total    27.7M   2.78T   2.78T   2.78T    27.8M   2.80T   2.80T   2.80T

No entanto, desde que eu descobri a parte de "esgotamento de RAM" eu considerarei este problema resolvido e postarei uma nova pergunta mais tarde, se necessário.

Edição rápida: Meu DDT parece estar encolhendo e bastante rápido. Talvez ela murche e desapareça no devido tempo. Nós veremos.

Outra edição rápida: impressionante! O DDT encolheu mais rápido e mais rápido até que finalmente o comando zpool status -D tank retornou dedup: no DDT entries .