主页 / server / 问题 / 1112334
Accepted
natxo asenjo
Asked: 2022-10-06 11:51:38 +0800 CST

戴尔 PE RHEL 7 糟糕的性能

  • 772

我们有一个“旧”的戴尔 PE r740xd 服务器，其规格相当高，安装了 rhel 7（最新）。运行 ls -l on / 可能需要几分钟。

一些规格：

# 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，我刚刚安装了操作系统。什么会如此显着地影响性能？

performance

2 个回答

  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
  2. Best Answer

    事实证明，这是交换机上断开的上行链路端口。这已经修复，现在的性能是我们所期望的。

    • 0

相关问题