☰

Dell PE RHEL 7 性能糟糕

tag-icon • tag-icon performance dell-poweredge rhel7
Dell PE RHEL 7 性能糟糕

我们有一台“旧”的 Dell PE r740xd 服务器，配置相当高，安装了 rhel 7（最新版）。在 / 上运行 ls -l 可能需要几分钟。

一些规格：

# 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

目前只使用 sdb，我刚刚安装了操作系统。什么会对性能产生如此大的影响？

答案1

由于您只提到ls -l /花费很长时间（例如并非所有目录），因此一种可能性是您的根 inode 变得非常大。

您可以使用它来检查stat /并查看报告的大小。具有 4K 块的文件系统上的典型根 inode 仅为 4K。

目录的 inode 可能会因为在其中创建大量名称而变得非常大——无论这些名称是文件、目录、设备节点等。只要名称不适合 inode 的当前块，就必须进行扩展。

具有大 inode 的目录枚举其包含的所有名称会很慢，即使大多数名称已被删除。如果这是根 inode，则它可能会影响许多文件系统操作，例如对 的调用open()等。

不幸的是，大多数文件系统在删除名称时不会自动缩小 inode。

对于大型非根 inode，您可以创建一个新目录，将所有内容从旧目录移动到新目录，删除旧目录，然后重命名新目录。

对于 ext2/3/4 文件系统上的大型根 inode，fsck -f -D /dev/...如果可以将其连接到另一个系统，则可以在块设备上运行。如果无法做到这一点，您可以尝试shutdown -r -F now重新启动系统并在启动时强制执行 fsck；它可能会优化和缩小目录。

对于其他文件系统，唯一明智的补救措施可能是在新磁盘上重建文件系统。

为了防止将来出现较大的根 inode，请尝试确定哪个程序在其中创建了这么多名称，/并防止它在将来再次这样做。很可能某个程序将其临时文件存储在那里；将其配置为使用它/tmp；或者更好的是，/tmp为其创建一个子目录，这样如果您想再次重建有问题的程序的临时目录，就不必中断其他程序的使用/tmp。

在查找此类文件时，使用ls -a /显示隐藏文件。如果此操作无果，您可以尝试仔细查看 的输出lsof / | grep -i del；可能存在在 / 中创建、打开然后取消链接的文件，因此名称不再显示。

答案2

原来是交换机的上行链路端口坏了。这个问题已经修复，现在性能符合我们的预期。

相关内容