Temos um sistema que é usado para um banco de dados GIS (com Postgres como o mecanismo subjacente) que está usando uma matriz RAID 5 de software de SSDs Samsung EVO870 SATA de 4x2 TB como unidade de banco de dados. Há um script de backup noturno que despeja as tabelas em um diretório temporário local, GZipa-as e as transfere para uma máquina separada (com mv). Normalmente o backup começa às 18h30 e vai até as 05h00; sim, é um backup grande. Há cerca de um mês, o sistema externo caiu e, portanto, omvstep parou de funcionar e a área de armazenamento temporário foi preenchida com arquivos não movidos. Depois que o sistema externo foi reparado, notamos que a área temporária estava cheia e excluímos tudo dela - cerca de 3,5 TB de arquivos. Cerca de duas semanas atrás, notamos que o backup diário não estava sendo concluído até 1000. Minha suspeita é que as coisas ficaram mais lentas porque o diretório temporário, embora apagado, não está sendo removido, então quando temos que escrever um novo arquivo temporário como parte do backup, temos que limpar os blocos SSD antes de reescrevê-los.
fstrim -avnão imprime nada, o que sugere que nenhum sistema de arquivos está dizendo que tem suporte para DISCARD.
Este sistema tem LVM no topo da matriz RAID. O banco de dados e os diretórios temporários estão em um sistema de arquivos ext4 (era ext2, mas coisas aconteceram) em seu próprio LV montado em /db; fstrim -v /dbrelatórios File system does not support DISCARD.
Versão do SO: Debian Linux 8 (jessie), Linux 3.16.0-4-amd64 x86_64
Informações do RAID:
root@local-database:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda1[7] sdd1[4] sdc1[5] sdb1[6]
5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 1/2 pages [4KB], 524288KB chunk
root@local-database:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Dec 27 17:55:35 2015
Raid Level : raid5
Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Aug 8 14:07:27 2023
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : local-database:0 (local to host local-database)
UUID : 18d38d9a:daaa0652:8e43a020:133e5a4f
Events : 53431
Number Major Minor RaidDevice State
7 8 1 0 active sync /dev/sda1
6 8 17 1 active sync /dev/sdb1
5 8 33 2 active sync /dev/sdc1
4 8 49 3 active sync /dev/sdd1
Informações sobre o LV específico usado para o banco de dados e áreas temporárias:
--- Logical volume ---
LV Path /dev/MainDisk/postgres
LV Name postgres
VG Name MainDisk
LV UUID TpKgGe-oHKS-Y341-029v-jkir-lJn8-jo8xmZ
LV Write Access read/write
LV Creation host, time local-database, 2015-12-27 18:04:04 -0800
LV Status available
# open 1
LV Size 4.78 TiB
Current LE 1251942
Segments 4
Allocation inherit
Read ahead sectors auto
- currently set to 6144
Block device 253:2
Informações do PV:
root@local-database:~# pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name MainDisk
PV Size 5.46 TiB / not usable 2.50 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 1430699
Free PE 121538
Allocated PE 1309161
PV UUID N3tcTa-LBw2-D8gI-6Jg4-9v3T-KWn2-5CDVzK
Eu realmente gostaria de reduzir os tempos de backup para 11 horas, para que não colidissemos com os tempos reais de trabalho. Existe algo nas opções TRIM que eu possa fazer aqui ou há algo mais que eu perdi? Eu verifiquei se o banco de dados não aumentou repentinamente nenhuma nova tabela ou cresceu 50% da noite para o dia; não há problemas de conexão de rede, não houve nada estranho que tenha acontecido com a rede ou o servidor externo pouco antes de começarmos a levar 16 horas para fazer o backup, pelo que posso ver. Há mais alguma coisa que estou perdendo?
Editar devido aos comentários: os SSDs reais têm apenas um ano e meio, substituindo os SSDs originais de 250 GB em abril de 2022. (Ficou sem espaço e a matriz RAID, LV e sistema de arquivos foram expandidos no local.) Estamos usando RAID de software, Linux de padrão ósseo com mdadm.
Edite em resposta aos comentários:
root@local-database:~# lsblk -d
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
sdb 8:16 0 1.8T 0 disk
sdc 8:32 0 1.8T 0 disk
sdd 8:48 0 1.8T 0 disk
root@local-database:~# cat /sys/module/raid456/parameters/devices_handle_discard_safely
N
root@local-database:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 21
Model: 2
Model name: AMD FX(tm)-8320 Eight-Core Processor
Stepping: 0
CPU MHz: 1400.000
CPU max MHz: 3500.0000
CPU min MHz: 1400.0000
BogoMIPS: 7023.19
Virtualization: AMD-V
L1d cache: 16K
L1i cache: 64K
L2 cache: 2048K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
De acordo com um artigo vinculado por Nikita Kyprianov nos comentários abaixo, o Samsung EVO 870s tem sérios problemas com hardware AMD, o que claramente é. Então isso parece ser isso. Acho que teremos que conviver com isso...
Você precisa ativar o suporte para descarte em /etc/lvm.conf (issue_discards=1)
Não me lembro se isso precisa ser definido em md, mas não há menção em minhas páginas man locais.