Temos um servidor Dell PE r740xd 'antigo' com especificações bastante altas, instalado com rhel 7 (mais recente). A execução de ls -l em / pode levar minutos.
Algumas especificações:
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 80
On-line CPU(s) list: 0-79
Thread(s) per core: 2
Core(s) per socket: 20
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
Stepping: 4
CPU MHz: 2400.000
BogoMIPS: 4800.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 28160K
NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40 ,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78
NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41 ,43,45,47,49,51,53,55,57,59,61,63,65,67,69,71,73,75,77,79
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1g b rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonst op_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 s sse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_dead line_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 invpcid_single intel_ppin intel_pt ssbd mba ibrs ibpb stibp tpr_shadow vnmi fle xpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_lo cal dtherm ida arat pln pts pku ospke md_clear spec_ctrl intel_stibp flush_l1d
# free -h
total used free shared buff/cache available
Mem: 376G 4.5G 371G 10M 342M 370G
Swap: 4.0G 0B 4.0G
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 17.5T 0 disk
└─sda1 8:1 0 17.5T 0 part
sdb 8:16 0 111.7G 0 disk
├─sdb1 8:17 0 1G 0 part /boot
└─sdb2 8:18 0 110.7G 0 part
├─rhel_lab110--16-root 253:0 0 50G 0 lvm /
├─rhel_lab110--16-swap 253:1 0 4G 0 lvm [SWAP]
└─rhel_lab110--16-home 253:2 0 56.7G 0 lvm /home
Apenas sdb está sendo usado agora, acabei de instalar o sistema operacional. O que pode estar afetando o desempenho de forma tão dramática?
Como você mencionou apenas
ls -l /levar muito tempo (e nem todos os diretórios, por exemplo), uma possibilidade é que seu inode raiz tenha ficado muito grande.Você pode verificar isso com
stat /e ver o tamanho relatado. Um inode raiz típico em um sistema de arquivos com blocos de 4K seria apenas 4K.O inode de um diretório pode ficar muito grande criando muitos nomes nele --- não importa se esses nomes são arquivos, diretórios, nós de dispositivo, etc. Sempre que os nomes não cabem nos blocos atuais do inode, ele tem a ser expandido.
Um diretório com um inode grande será lento para enumerar todos os nomes que ele contém, mesmo que a maioria dos nomes já tenha sido removida. Se esse for o inode raiz, ele pode afetar muitas operações do sistema de arquivos, como chamadas para
open(), etc.Infelizmente, a maioria dos sistemas de arquivos não reduz automaticamente os inodes quando os nomes são removidos.
Para grandes inodes não raiz, você pode criar um novo diretório, mover tudo do antigo para o novo, remover o antigo e renomear o novo.
Para inodes raiz grandes em um sistema de arquivos ext2/3/4, você pode executar
fsck -f -D /dev/...no dispositivo de bloco se puder conectá-lo a outro sistema. Se você não puder fazer isso, você pode tentarshutdown -r -F nowreiniciar o sistema e forçar um fsck na inicialização; ele pode otimizar e reduzir o diretório.Para outros sistemas de arquivos, a única solução sensata pode ser reconstruir o sistema de arquivos em um novo disco.
Para evitar um grande inode raiz no futuro, tente identificar em qual programa criou tantos nomes
/e evite que isso aconteça no futuro. É provável que um programa esteja armazenando seus arquivos temporários lá; configurá-lo para usar/tmpem vez disso; ou, melhor ainda, um subdiretório/tmpapenas para ele, para que você não precise interromper outros programas usando/tmpse quiser reconstruir o diretório temporário do programa incorreto novamente.Ao procurar esses arquivos, use
ls -a /para mostrar arquivos ocultos. Se isso não resultar em nada, você pode tentar percorrer a saída delsof / | grep -i del; pode haver arquivos que foram criados em /, abertos e desvinculados para que o nome não apareça mais.Acontece que essa era uma porta de uplink quebrada em um switch. Isso foi reparado e agora o desempenho é o que esperávamos.