主页 / server / 问题 / 1141074
Accepted
tsc_chazz
Asked: 2023-08-09 06:40:45 +0800 CST

SSD阵列上的文件访问突然变慢；TRIM 似乎不可用。如何启用，或者还有什么可能？

  • 772

我们有一个用于 GIS 数据库的系统（以 Postgres 作为底层引擎），该系统使用 4x2TB Samsung EVO870 SATA SSD 的软件 RAID 5 阵列作为其数据库驱动器。有一个夜间备份脚本，可将表转储到本地临时目录，对它们进行 GZip 压缩，然后将它们传输到单独的计算机（使用mv）。一般备份从1830开始一直运行到0500；是的，这是一个很大的备份。一个月左右前，外部系统掉线了，所以mv步骤停止工作，临时存储区域被未移动的文件填满。修复外部系统后，我们注意到临时区域已满，并删除了其中的所有内容 - 大约 3.5TB 的文件。大约两周前，我们注意到每日备份直到 1000 才完成。我怀疑事情已经变慢，因为临时目录虽然被删除，但没有被清除，所以当我们必须编写一个新的临时文件作为一部分时对于备份，我们必须先清理 SSD 块，然后才能重写它们。

fstrim -av不打印任何内容，这表明没有文件系统表示它们支持 DISCARD。

该系统在 RAID 阵列之上确实有 LVM。数据库和临时目录位于 ext4 文件系统中（是 ext2，但发生了一些事情），位于其自己的 LV 中，安装在/db；fstrim -v /db报道File system does not support DISCARD。

操作系统版本：Debian Linux 8 (jessie)、Linux 3.16.0-4-amd64 x86_64

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

有关用于数据库和临时区域的特定 LV 的信息：

  --- 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

光伏信息：

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

我真的很希望将备份时间缩短至 11 小时，这样我们就不会再与实际工作时间冲突。TRIM 选项中是否有我可以在此处执行的操作，或者还有其他我错过的操作吗？我检查过数据库没有突然增加任何新表，或者一夜之间增加了 50%；没有网络连接问题，据我所知，在我们开始花费 16 小时进行备份之前，网络或外部服务器没有发生任何奇怪的情况。我还缺少什么吗？

根据评论进行编辑：实际的 SSD 仅使用了一年半，于 2022 年 4 月取代了原来的 250GB SSD。（空间不足，RAID 阵列、LV 和文件系统已就位扩展。）使用软件 RAID、骨标准 Linux 和mdadm.

编辑回应评论：

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

根据 Nikita Kyprianov 在下面的评论中链接的一篇文章，三星 EVO 870s 在 AMD 硬件上存在严重问题，这显然是事实。看来就是这样。我想我们只能忍受它......

lvm

1 个回答

  1. Best Answer

    您需要在 /etc/lvm.conf 中启用丢弃支持 (issue_discards=1)

    我不记得这是否需要在 md 中设置，但我的本地手册页中没有提及。

    • 2

相关问题