Início / server / Perguntas / 1167981
Accepted
Codejoy
Asked: 2024-11-21 14:10:41 +0800 CST

Erro estranho ao usar du -h -d1

  • 772

Tenho um servidor de e-mail antigo... ele simplesmente executa o Courier Postfix e o SMTP. É uma VM KVM e tem duas unidades, uma para o sistema operacional e uma para dados. Tenho uma unidade de dados muito cheia (relata 100% cheia, embora o usado e o disponível tenham uma distribuição de cerca de 24 GB). Não tenho certeza do porquê ou o que está consumindo espaço e depois liberando-o. Um top mostra principalmente o imapd do Postfix fazendo coisas. Não consigo obter o iotop nesta máquina. Então, imaginei que para começar a liberar espaço nas caixas de correio dos usuários no servidor, eu faria um du -h -d1 para tentar descobrir quem são os maiores infratores. Bem, esse comando é executado LENTO mais lento do que nunca. Então, como ele era lento, imaginei que emitiria um comando de tela de:

du -h -d1 > caixasdecorreiotamanhos.txt

Então eu pude ir até ele de manhã e ver os usos. Ele escreveu cerca de 6 caixas de correio, a maior delas sendo 2,2 GB e depois nada. Então fui até a máquina real para ver o que o comando estava fazendo se ainda estivesse em execução e vi isso:

[root@xmail]# du -h -d1 > /root/mailboxsizes.txt
[14280.306953] INFO: task imapd:12559 blocked for more than 120 seconds.
[14280.307710] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[14280.309680] imapd           D ffff8800d3d9cd98     0 12559      1 0x00000080
[14280.310591]  ffff8800b17bbc20 0000000000000086 ffff880057bbce70 ffff8800b17bbfd8
[14280.310591]  ffff8800b17bbfd8 ffff8800b17bbfd8 ffff880057bbce70 ffff8800d3d9cd90
[14280.313532]  ffff8800d3d9cd94 ffff880057bbce70 00000000ffffffff ffff8800d3d9cd98
[14280.313532] Call Trace:
[14280.315669]  [<ffffffff8168d159>] schedule_preempt_disabled+0x29/0x70
[14280.316637]  [<ffffffff8168adb5>] __mutex_lock_slowpath+0xc5/0x1c0
[14280.316637]  [<ffffffff81208e17>] ? unlazy_walk+0x87/0x140
[14280.318543]  [<ffffffff8168a21f>] mutex_lock+0x1f/0x2f
[14280.319516]  [<ffffffff81683c93>] lookup_slow+0x33/0xa7
[14280.320690]  [<ffffffff8120c8f3>] path_lookupat+0x773/0x7a0
[14280.321718]  [<ffffffff81183775>] ? filemap_fault+0x215/0x410
[14280.321718]  [<ffffffff811de5e5>] ? kmem_cache_alloc+0x35/0x1e0
[14280.323363]  [<ffffffff8120f23f>] ? getname_flags+0x4f/0x1a0
[14280.324348]  [<ffffffff8120c94b>] filename_lookup+0x2b/0xc0
[14280.324348]  [<ffffffff81210367>] user_path_at_empty+0x67/0xc0
[14280.325307]  [<ffffffff811b1431>] ? handle_mm_fault+0x6b1/0xfe0
[14280.327150]  [<ffffffff812103d1>] user_path_at+0x11/0x20
[14280.327965]  [<ffffffff81203843>] vfs_fstatat+0x63/0xc0
[14280.328093]  [<ffffffff81203dae>] SYSC_newstat+0x2e/0x60
[14280.328093]  [<ffffffff81692875>] ? do_page_fault+0x35/0x90
[14280.330895]  [<ffffffff8168ea88>] ? page_fault+0x28/0x30
[14280.331790]  [<ffffffff8120408e>] SyS_newstat+0xe/0x10
[14280.331857]  [<ffffffff81697089>] system_call_fastpath+0x16/0x1b

Sou novo em administração de sistemas e não tenho a mínima ideia do que isso está me dizendo, exceto por algo a ver com o imapd? Eu reiniciei esta máquina várias vezes e ela mal liberou espaço em discos rígidos ou recursos aparentemente. Não consigo descobrir o que está acontecendo e por que o du falhou acima como falhou. Na maioria das vezes, estou aqui perguntando por onde começar? Embora esta máquina seja antiga e sempre tenha tido seus momentos, ela nunca fez isso antes (embora eu reconheça que a unidade de dados está com pouco espaço), mas se eu limpá-la, algo a consome.

Para completar:

df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        2.9G     0  2.9G   0% /dev
tmpfs           2.9G     0  2.9G   0% /dev/shm
tmpfs           2.9G   41M  2.8G   2% /run
tmpfs           2.9G     0  2.9G   0% /sys/fs/cgroup
/dev/vda3        21G   18G  2.1G  90% /
/dev/vdb        459G  435G  442M 100% /mail
/dev/vda1       976M  119M  790M  14% /boot
tmpfs           581M     0  581M   0% /run/user/0
tmpfs           581M     0  581M   0% /run/user/1000


top - 06:06:53 up  6:52,  3 users,  load average: 36.42, 36.64, 31.74
Tasks: 346 total,   8 running, 338 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.4 us,  1.2 sy,  0.0 ni,  0.0 id, 89.9 wa,  0.0 hi,  0.0 si,  1.5 st
KiB Mem :  5946284 total,   130280 free,  2278016 used,  3537988 buff/cache
KiB Swap:  2516988 total,  1906332 free,   610656 used.  3362528 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
19174 postfix   20   0   27028   5504   1488 R   8.3  0.1   0:38.53 imapd       
19586 postfix   20   0   27028   5504   1488 D   7.6  0.1   0:32.18 imapd       
19008 postfix   20   0   27028   5504   1488 R   7.0  0.1   0:48.61 imapd       
19372 postfix   20   0   27464   5872   1504 D   4.3  0.1   0:30.38 imapd       
20087 postfix   20   0   27028   5504   1488 D   4.3  0.1   0:23.27 imapd       
20188 postfix   20   0   27028   5504   1488 D   4.3  0.1   0:23.31 imapd       
20353 postfix   20   0   27028   5508   1488 D   4.3  0.1   0:23.05 imapd       
19963 postfix   20   0   27028   5508   1488 D   4.0  0.1   0:23.85 imapd       
20275 postfix   20   0   27028   5508   1488 D   4.0  0.1   0:22.56 imapd       
18460 postfix   20   0   29348   5748   1588 R   3.7  0.1   0:38.09 imapd       
20236 postfix   20   0   27028   5516   1488 D   3.7  0.1   0:22.86 imapd       
   32 root      20   0       0      0      0 S   1.7  0.0   5:57.44 kswapd0     
20079 postfix   20   0   32728   9152   1520 S   1.7  0.2   0:01.90 imapd       
19702 postfix   20   0   27028   5516   1488 D   1.3  0.1   0:27.77 imapd       
18575 postfix   20   0   30472   6848   1596 D   1.0  0.1   0:14.86 imapd       
19782 postfix   20   0   27028   5508   1488 D   1.0  0.1   0:27.02 imapd       
 1026 root      20   0 1174028  22616   8992 S   0.7  0.4   2:53.90 fail2ban-s+

Não tenho certeza do que procurar e tento descobrir onde posso colocar algumas pastas e saber de quais caixas de entrada antigas estamos mantendo para nos livrarmos, numa tentativa de liberar espaço e, quem sabe, fazer o servidor ter um desempenho melhor.

minha única ideia é executar systemctl stop postfix por um tempo e ver se du's e ls's funcionam melhor e verificar novamente se o top não está com ping desativado.

também caso seja relevante um iostat:

iostat
Linux 3.10.0-514.16.1.el7.x86_64 (xmail)    11/21/2024  _x86_64_    (3 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.95    0.01    1.29   88.86    0.65    3.24

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
vda              11.92       252.15        61.60    6335865    1547820
vdb            1517.62     62131.62        78.76 1561227117    1979120
linux

1 respostas

  1. Best Answer

    A mensagem no seu display é um aviso do kernel. Tais avisos normalmente são transmitidos para o console, gravados no kernel ringbuffer (normalmente exibido com command com o switch dmesgopcional ) e/ou copiados para arquivos de log em .-T/var/log

    Muitas vezes, os comandos que você está executando no console não são a causa do erro exibido.

    Neste caso, pode haver uma correlação.

    A maioria das implementações Open Source IMAP armazenam mensagens no Maildir/formato em que cada mensagem de e-mail é um arquivo individual. Em um sistema de arquivos com 450 GB de e-mail, haverá muitos diretórios, muitos com um grande número de e-mails e, portanto, muitos arquivos. Executar du nesse sistema de arquivos /mail provavelmente será (extremamente) ineficiente, dependendo do sistema de arquivos que ele usa. Você pode verificar qual sistema de arquivos está em uso com, por exemplo, cat /proc/mountse/ou em /etc/fstab. Alguns sistemas de arquivos têm melhor desempenho do que outros, mas várias dezenas de mil arquivos em um único diretório (em uma única caixa de entrada ou outra pasta de e-mail) podem ser problemáticos.

    Da mesma forma, também será trabalhoso quando o imapd precisar indexar uma caixa de entrada ou outra pasta de e-mail.

    Um sistema de arquivos cheio, como já exibido com o dfcomando, agrava o problema. Seus usuários provavelmente ainda estão recebendo mensagens, lendo-as e excluindo-as, então provavelmente há bastante carga.

    Também pode ser interessante executar df -ise você estiver ficando sem inodes.

    Em geral, sistemas de arquivos (quase) completos sofrem de todos os tipos de problemas de desempenho.

    Para uma VM, geralmente é possível e trivial simplesmente atribuir mais armazenamento do hipervisor para o disco virtual, então aumentar /mailo sistema de arquivos e muitos dos seus problemas devem desaparecer. Ambas são geralmente operações online que podem ser executadas com segurança durante o horário comercial.

    O oposto é encontrar armazenamento desperdiçado e recuperá-lo excluindo dados que não são mais necessários.

    Quanto à liberação de espaço:

    • Remova o Maildir e os dados das contas de usuários que não existem mais.

    • O protocolo IMAP requer que os clientes marquem mensagens individuais como excluídas, mas isso não exclui os arquivos ainda de um Maildir. Isso requer um comando EXPUNGE separado. Alguns clientes quebrados/legados não emitem esse comando expunge e as mensagens excluídas permanecerão indefinidamente em seus servidores de e-mail.

    • Outros clientes de e-mail "apagam" e-mails movendo as mensagens para uma Lixeira ou pasta com nome similar, onde elas também podem permanecer indefinidamente. Esvaziar a Lixeira para eles pode ser útil para liberar com segurança o espaço necessário.

    Dependendo dos servidores de e-mail que você estiver usando, pode haver ferramentas específicas para ajudar com essa limpeza, como a doveadm-expungeferramenta que pode procurar mensagens de e-mail com o sinalizador DELETED e excluí-las corretamente do seu sistema de arquivos.

    • 2

relate perguntas