主页 / user-639471

King David's questions

Martin Hope
King David
Asked: 2024-05-22 22:59:13 +0800 CST
  • 5

假设我想在某些文本的开头通过管道输出日期

例如

echo "this line is test line" | date

预期输出应该是

Wed May 22 14:55:10 UTC 2024 this line is test line

如何在行前插入日期和时间？

bash
Martin Hope
King David
Asked: 2024-04-04 02:50:46 +0800 CST
  • 6

我们有以下文件系统。

从lsblk -f

sdb                 LVM2_member       uMrU0b-6F3l-M9Ue-LPsf-kd6n-5l4m-WfxaRQ
└─DB_vg-DB_lv xfs                     a800d759-c8c7-4e7e-86d5-3d6a06123465
sdc                 LVM2_member       CgGp4m-qGtE-S3Br-0gJs-IdCG-CJXM-pwu7ps
└─DB_vg-DB_lv xfs                     a800d759-c8c7-4e7e-86d5-3d6a06123465
sdd                 LVM2_member       vGfMF3-PPem-JOjD-w2Qt-bP4O-Wppy-YnIB6A
└─DB_vg-DB_lv xfs                     a800d759-c8c7-4e7e-86d5-3d6a06123465

从lsblk

sdb                   8:16   0    4G  0 disk
└─DB_vg-DB_lv 253:4    0   12G  0 lvm
sdc                   8:32   0    4G  0 disk
└─DB_vg-DB_lv 253:4    0   12G  0 lvm
sdd                   8:48   0    4G  0 disk
└─DB_vg-DB_lv 253:4    0   12G  0 lvm

在未安装的磁盘上，我们执行以下操作：

wipefs -a /dev/sdb /dev/sdc /dev/sdd

wipefs: error: /dev/sdb: probing initialization failed: Device or resource busy

Device or resource busy当磁盘sdb sdc sdd未安装时，为什么我们会得到？

擦除该磁盘上的文件系统的正确方法是什么

linux
Martin Hope
King David
Asked: 2024-03-20 01:06:04 +0800 CST
  • 6

我们从内核消息中得到的以下消息的含义是什么

#  dmesg  | grep "MDS CPU bug"
[    0.432893] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.

以上消息安全吗？或者需要采取一些相应措施

linux
Martin Hope
King David
Asked: 2024-01-09 16:54:25 +0800 CST
  • 5

从 fdisk -l /dev/sda，我们得到以下

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200   482344959   240122880   83  Linux

通常在系统下我们应该得到Linux LVM，因为sda2是LVM

vgdisplay | grep Format
  Format                lvm2

这是我们需要忽略的事情吗？

linux
Martin Hope
King David
Asked: 2023-12-07 16:53:50 +0800 CST
  • 5

我们的 Kafka 集群包括 12 台 VM RHEL 7.6 机器。

机器规格详细信息：

  1. CPU：14

  2. Kafka磁盘是VMDK磁盘。（sdb磁盘）

  3. 内存48G

当 Kafka 集群正在努力工作时（当将数据注入 Kafka 磁盘并从磁盘进行密集读取时），我们可以从sar报告中看到 VMDK 磁盘利用率非常高，几乎 100% 并且 CPU iowait 也达到约 40%

当没有写入/读取 Kafka 磁盘 ( sdb ) 时，磁盘利用率约为 1-3%，这很好

这是第一台 Kafka 机器的示例，该示例与集群中的其他机器类似

sar -p -d 5 15 | grep sdb

                  DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
11:45:44 AM       sdb    667.60  50776.00 114753.80    247.95    145.06    210.63      1.50    100.00
11:45:49 AM       sdb    484.60  40296.00 142994.40    378.23    145.80    343.71      2.06    100.00
11:45:54 AM       sdb    355.40  12758.40 170463.40    515.54    285.86    724.10      2.81    100.00
11:45:59 AM       sdb    477.40  26828.80 142663.20    355.03    219.43    419.59      2.10    100.02
11:46:04 AM       sdb    526.40  30964.80 116515.60    280.17    219.52    495.00      1.90     99.98
11:46:09 AM       sdb    387.20  26939.20 142214.60    436.86    192.80    405.45      2.58    100.00
11:46:14 AM       sdb    403.00  18192.00 130434.80    368.80    286.71    681.59      2.48    100.00
11:46:19 AM       sdb    608.00  50153.60  96733.40    241.59    163.63    336.13      1.65    100.04
11:46:24 AM       sdb    188.40   8406.40  87474.80    508.92    196.47    657.40      5.31     99.98
11:46:29 AM       sdb    749.40  54948.80 167797.40    297.23    207.97    388.29      1.33    100.02
11:46:34 AM       sdb    419.20  57480.00 110545.60    400.82    143.63    305.59      2.39    100.00
11:46:39 AM       sdb    549.60  34772.80 149058.60    334.48    144.77    286.05      1.82     99.98
11:46:44 AM       sdb    468.26  40547.70 130706.99    365.72    146.39    318.22      2.13     99.90
11:46:49 AM       sdb    412.40  21929.60 186562.40    505.56    144.34    363.23      2.42     99.98
11:46:54 AM       sdb    574.60  36830.40 177053.60    372.23    149.73    245.82      1.74    100.00
Average:          sdb    484.76  34122.49 137730.57    354.51    186.13    385.28      2.06     99.99

从CPU报告的角度来看

sar  5 15

12:12:45 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
12:12:50 PM     all      8.21      0.00      9.87     10.26      0.00     71.67
12:12:55 PM     all      6.50      0.00      7.65      7.78      0.00     78.07
12:13:00 PM     all      7.90      0.00      9.40     10.53      0.00     72.16
12:13:05 PM     all     11.83      0.00     13.24     26.62      0.00     48.31
12:13:10 PM     all     11.66      0.00     12.84     19.00      0.00     56.50
12:13:15 PM     all      8.23      0.00      9.98      9.52      0.00     72.26
12:13:20 PM     all      7.74      0.00      8.87     10.95      0.00     72.44
12:13:25 PM     all      6.70      0.00      7.92      9.10      0.00     76.27
12:13:30 PM     all      7.15      0.00      8.32      8.05      0.00     76.49
12:13:35 PM     all     12.84      0.00     14.12     15.17      0.00     57.87
12:13:40 PM     all      7.91      0.00      9.04     35.44      0.00     47.62
12:13:45 PM     all      9.20      0.00     10.63     11.09      0.00     69.09
12:13:50 PM     all      9.57      0.00     10.98      8.15      0.00     71.30
12:13:55 PM     all     10.85      0.00     12.61      7.39      0.00     69.15
12:14:00 PM     all     10.88      0.00     12.44      9.54      0.00     67.15
Average:        all      9.14      0.00     10.52     13.23      0.00     67.11

从 RAM 内存的角度来看，我没有看到问题，但不确定这里的瓶颈是什么以及为什么磁盘利用率非常高

一个方向是将 CPU 从 14 核增加到 48 核，但也许我们获得高 CPU %IOWAIT 值的事实是磁盘利用率高的结果。

来自生产者发送到集群的流量被持久化到磁盘。因此，存储卷的底层吞吐量可能成为集群的瓶颈。

在这种情况下，将其他 kafka 机器添加到集群中是有意义的。或者可能向每台 Kafka 机器添加一些额外的磁盘（如 JBOD 磁盘），以平衡密集的写入/读取。

感谢您提供任何可以提高 Kafka 磁盘利用率的建议

Vmware 磁盘详细信息（来自 vSphere 客户端的编辑设置）

SATA controller 0     AHCI
VM storage policy     VxRail RAID5 Default 
Sharing               No SHaring
Disk File             VxRail-VSAN_Datastore 
Disk mode             Dependent 
Virtual Device Node   SCSI controller 0

加载集群时 vmstat 的结果

vmstat 1 20
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
18 13   1024 379388      0 54566428    0    0  1888  5137    0    0  4  4 47 45  0
 0 19   1024 328408      0 54606020    0    0     0  6853 11700 7288  2  2 12 85  0
 0 15   1024 330204      0 54618088    0    0 12004 56708 16881 8254  3  3 16 78  0
 0 13   1024 345284      0 54601404    0    0  3492 104672 5135 3067  0  1 43 56  0
 0 17   1024 324864      0 54620400    0    0   248 66547 16615 8477  2  4 31 63  0
 0 18   1024 367468      0 54577640    0    0     0 84404 13020 6995  2  3  6 90  0
 0 21   1024 327480      0 54611036    0    0  8536 125999 29355 37872  4  7 18 71  0
 0 19   1024 362180      0 54581692    0    0  7692 66464 4167 2717  0  0 33 66  0
 0 19   1024 419264      0 54523248    0    0     0 46409 1799 1825  0  0 27 73  0
 0 14   1024 356708      0 54586004    0    0     4 78656 17169 9841  3  4 23 70  0
 0 14   1024 407352      0 54539976    0    0     0 136732 4554 4673  0  1 20 79  0
 0 12   1024 389672      0 54557752    0    0  5832 59124 9619 5537  1  2 25 71  0
 0 14   1024 431880      0 54513164    0    0   948 94160 14272 7229  2  3 30 65  0
 0 15   1024 440300      0 54502784    0    0  9140 136328 10626 5296  1  1 38 60  0
 0 13   1024 441708      0 54501948    0    0  7652 62132 4663 2756  0  1 33 66  0
 0 14   1024 449396      0 54492664    0    0   416 64790 1955 1757  0  0 33 66  0
 0 17   1024 424028      0 54520452    0    0   484 114372 16674 7946  2  3 25 70  0
 0 18   1024 441912      0 54499924    0    0     0 82027 2752 2100  0  0 22 78  0
 0 14   1024 473604      0 54468560    0    0     0 60188 2021 2212  0  0 22 78  0
 1 14   1024 420224      0 54525684    0    0  8576 128225 21739 9684  9  4 27 60  0
hard-drive
Martin Hope
King David
Asked: 2023-10-30 01:08:25 +0800 CST
  • 5

我们有以下网卡配置。来自ethtool，（服务器是RHEL 7.9版本）

ethtool p1p1
Settings for p1p1:
        Supported ports: [ FIBRE ]
        Supported link modes:   10000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: No
        Supported FEC modes: Not reported
        Advertised link modes:  10000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

我们尝试通过将以下行添加到ifcfg-p1p1文件并重新启动网络服务来将自动协商设置为yes ，但没有成功。

ETHTOOL_OPTS="speed 10000 duplex full autoneg on"

第二次尝试如下。

ethtool -s p1p1 autoneg  on speed 10000 duplex full
Cannot set new settings: Invalid argument
  not setting speed
  not setting duplex
  not setting autoneg

但没有成功

设置自动协商的其他选项是什么：是？

或者这可能与 cisco 交换机相关并且无法从 Linux 端配置？

linux
Martin Hope
King David
Asked: 2023-10-24 19:10:23 +0800 CST
  • 5

clockdiff是测量主机之间时钟差的命令

这是我的 Linux 机器上的示例。

clockdiff -o 162.23.2.2
.
host=server11 rtt=750(187)ms/0ms delta=0ms/0ms Tue Oct 24 11:01:42 2023

问题是当我们想要过滤输出或将输出保存到文件时，如下所示

clockdiff -o 162.23.2.2 >/tmp/file

more /tmp/file

1698145574 0 0

正如我们在上面看到的，文件的输出不是我们从控制台运行命令时的输出

如何将输出保存为以下任何想法：

.
host=server11 rtt=750(187)ms/0ms delta=0ms/0ms Tue Oct 24 11:01:42 2023
linux
Martin Hope
King David
Asked: 2023-08-15 19:14:30 +0800 CST
  • 5

如何知道red hat Linux机器上动态端口分配的范围

我们在 Linux 上做了

sysctl -a | egrep "net.inet.ip.portrange.first|net.inet.ip.portrange.last"

但这些参数不在内核配置中

该参数是否等同于文件-中的设置/proc/sys/net/ipv4/ip_local_port_range？

more /proc/sys/net/ipv4/ip_local_port_range
1024    65535
linux
Martin Hope
King David
Asked: 2023-08-10 20:00:35 +0800 CST
  • 6

我们有一台运行 RHEL 7.9 版的 Linux 计算机。在本机中，我们安装了 Ticktok 服务，该服务使用端口号4590。

有时服务会停止并且不使用端口号4590。

问题是，当服务不使用该端口时，其他应用程序可能会使用它，而当服务启动时，它会失败，因为端口已在4590使用中。

那么我们如何4590为Ticktok服务预留端口号呢？

额外细节：

  1. 端口号不能1024，我们必须使用端口号4590
  2. 服务是systemctl服务的一部分
  3. Ticktok 服务有时会出于维护目的而关闭。
linux
Martin Hope
King David
Asked: 2023-07-21 13:08:11 +0800 CST
  • 9

由于我们的应用程序适用于python2RHEL 8，因此我们需要迁移到 RHEL 8

在 RHEL 8 机器上安装后python2，我们看到以下内容：

rpm -qa | grep python2
python2-pip-9.0.3-19.module+el8.6.0+13001+ad200bd9.noarch
python2-setuptools-wheel-39.0.1-13.module+el8.4.0+9442+27d0e81c.noarch
python2-pip-wheel-9.0.3-19.module+el8.6.0+13001+ad200bd9.noarch
python2-2.7.18-11.module+el8.7.0+15681+7a92afba.x86_64
python2-libs-2.7.18-11.module+el8.7.0+15681+7a92afba.x86_64
python2-setuptools-39.0.1-13.module+el8.4.0+9442+27d0e81c.noarch

但是当我们尝试使用 时import yum，我们会收到有关“没有名为 yum 的模块”的错误，并显示以下输出：

python
Python 2.7.18 (default, Jun 17 2022, 07:56:00)
[GCC 8.5.0 20210514 (Red Hat 8.5.0-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import yum
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named yum

yum 安装的 rpm 为：

rpm -qa | grep yum
yum-4.4.2-11.el8.noarch
yum-utils-4.0.18-4.el8.noarch

yum 显示为：

more /usr/bin/yum
#!/usr/bin/python
import sys
try:
    import yum
except ImportError:
    print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   %s

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
%s

If you cannot solve this problem yourself, please go to
the yum faq at:
  http://yum.baseurl.org/wiki/Faq

""" % (sys.exc_value, sys.version)
    sys.exit(1)

sys.path.insert(0, '/usr/share/yum-cli')
try:
    import yummain
    yummain.user_main(sys.argv[1:], exit_code=True)
except KeyboardInterrupt, e:
    print >> sys.stderr, "\n\nExiting on user cancel."
    sys.exit(1)

从pip2列表中我们得到这个输出：

pip2 list
pip (9.0.3)
setuptools (39.0.1)

那么为什么我们会收到有关 的错误 No module named yum？

https://www.getpagespeed.com/solutions/python-scripts-running-on-rocky-linux-8-can-not-import-yum

https://access.redhat.com/solutions/4289441

python
Martin Hope
King David
Asked: 2023-06-29 16:37:15 +0800 CST
  • 5

我们有 RHEL 7.9 机器集群，我们使用该服务器作为 kafka 客户端生产者。

每台机器都有以下规格（DELL实体机）

48 CORES
128G memory

在大多数机器上，我们发现 %idle 非常低（来自 sar 命令），值约为 2-6

有时我们还看到机器挂起几秒钟，CPU 平均负载值在 40-60 之间，但似乎没问题

所以我们唯一担心的一点是如何知道2-6个空闲是否仍然正常还是我们不能允许的

我们可以设置阈值，在空闲率较低时发出警报吗？但问题是如何设置阈值呢？

例如我们可以定义 10% 或 20% 的阈值吗？或者其他一些值？

vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
60  0      0 65249020   3364 1082656    0    0     2     1  115   43 86  3 11  0  0
46  0      0 65240956   3364 1082656    0    0     0     0 167113 10096 92  3  5  0  0
53  0      0 65248888   3364 1082656    0    0     0     0 208360 9795 92  4  4  0  0



sar 5 5

09:46:10 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:46:15 AM     all     91.93      0.00      4.03      0.00      0.00      4.04
09:46:20 AM     all     91.90      0.00      3.48      0.00      0.00      4.62
09:46:25 AM     all     91.76      0.00      3.21      0.00      0.00      5.04
09:46:30 AM     all     91.69      0.00      2.84      0.00      0.00      5.47
09:46:35 AM     all     92.17      0.00      4.50      0.00      0.00      3.34
Average:        all     91.89      0.00      3.61      0.00      0.00      4.50


top -bn2 | grep '%Cpu' | tail -1 | grep -P '(....|...) id,'|awk '{print "CPU Usage: " 100-$8 "%"}'
CPU Usage: 96.2%
    

sar -P ALL 1 1

Average:        CPU     %user     %nice   %system   %iowait    %steal     %idle
Average:        all     91.94      0.00      4.75      0.00      0.00      3.31
Average:          0     12.24      0.00     51.02      0.00      0.00     36.73
Average:          1     17.35      0.00     41.84      0.00      0.00     40.82
Average:          2    100.00      0.00      0.00      0.00      0.00      0.00
Average:          3     98.02      0.00      1.98      0.00      0.00      0.00
Average:          4     99.00      0.00      1.00      0.00      0.00      0.00
Average:          5     98.00      0.00      2.00      0.00      0.00      0.00
Average:          6     98.02      0.00      1.98      0.00      0.00      0.00
Average:          7     98.00      0.00      2.00      0.00      0.00      0.00
Average:          8     98.00      0.00      2.00      0.00      0.00      0.00
Average:          9     99.00      0.00      1.00      0.00      0.00      0.00
Average:         10     99.00      0.00      1.00      0.00      0.00      0.00
Average:         11     98.02      0.00      1.98      0.00      0.00      0.00
Average:         12     98.00      0.00      2.00      0.00      0.00      0.00
Average:         13     98.00      0.00      2.00      0.00      0.00      0.00
Average:         14     98.99      0.00      1.01      0.00      0.00      0.00
Average:         15     99.00      0.00      1.00      0.00      0.00      0.00
Average:         16     98.99      0.00      1.01      0.00      0.00      0.00
Average:         17     99.00      0.00      1.00      0.00      0.00      0.00
Average:         18     98.00      0.00      2.00      0.00      0.00      0.00
Average:         19     99.00      0.00      1.00      0.00      0.00      0.00
Average:         20     99.00      0.00      1.00      0.00      0.00      0.00
Average:         21     97.06      0.00      2.94      0.00      0.00      0.00
Average:         22     98.00      0.00      2.00      0.00      0.00      0.00
Average:         23     98.02      0.00      1.98      0.00      0.00      0.00
Average:         24     20.20      0.00     41.41      0.00      0.00     38.38
Average:         25     31.31      0.00     23.23      0.00      0.00     45.45
Average:         26     99.01      0.00      0.99      0.00      0.00      0.00
Average:         27     98.02      0.00      1.98      0.00      0.00      0.00
Average:         28     98.02      0.00      1.98      0.00      0.00      0.00
Average:         29     98.02      0.00      1.98      0.00      0.00      0.00
Average:         30     98.99      0.00      1.01      0.00      0.00      0.00
Average:         31     98.02      0.00      1.98      0.00      0.00      0.00
Average:         32     98.99      0.00      1.01      0.00      0.00      0.00
Average:         33     98.02      0.00      1.98      0.00      0.00      0.00
Average:         34     98.02      0.00      1.98      0.00      0.00      0.00
Average:         35     99.00      0.00      1.00      0.00      0.00      0.00
Average:         36     97.06      0.00      2.94      0.00      0.00      0.00
Average:         37     98.00      0.00      2.00      0.00      0.00      0.00
Average:         38     97.06      0.00      2.94      0.00      0.00      0.00
Average:         39     98.99      0.00      1.01      0.00      0.00      0.00
Average:         40     98.00      0.00      2.00      0.00      0.00      0.00
Average:         41     98.00      0.00      2.00      0.00      0.00      0.00
Average:         42     98.99      0.00      1.01      0.00      0.00      0.00
Average:         43     98.00      0.00      2.00      0.00      0.00      0.00
Average:         44     98.00      0.00      2.00      0.00      0.00      0.00
Average:         45     98.99      0.00      1.01      0.00      0.00      0.00
Average:         46     98.00      0.00      2.00      0.00      0.00      0.00
Average:         47     98.00      0.00      2.00      0.00      0.00      0.00



 uptime
 09:53:23 up  2:07,  4 users,  load average: 49.94, 49.17, 49.17


 free -g
              total        used        free      shared  buff/cache   available
Mem:            125          61          62           0           1          62
Swap:            15           0          15



iostat
Linux 4.18.0-305.el8.x86_64 (dragon12)      06/29/2023      _x86_64_        (48 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          86.30    0.00    3.27    0.00    0.00   10.42

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               2.59        91.45        60.94     754657     502839
dm-0              1.95        83.37        54.04     687962     445952
dm-1              0.01         0.27         0.00       2220          0
dm-2              0.57         2.76         6.65      22810      54839



 sar -B 2 5
Linux 4.18.0-305.el8.x86_64 (dragon12)      06/29/2023      _x86_64_        (48 CPU)

10:05:30 AM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
10:05:32 AM      0.00      1.50  23815.00      0.00  43641.00      0.00      0.00      0.00      0.00
10:05:34 AM      0.00      0.00  27231.50      0.00  45495.00      0.00      0.00      0.00      0.00
10:05:36 AM      0.00      0.00  28570.50      0.00  47603.50      0.00      0.00      0.00      0.00
10:05:38 AM      0.00      0.00  27766.50      0.00  48434.50      0.00      0.00      0.00      0.00
10:05:40 AM      0.00     14.00  28007.00      0.00  48733.50      0.00      0.00      0.00      0.00
Average:         0.00      3.10  27078.10      0.00  46781.50      0.00      0.00      0
linux
Martin Hope
King David
Asked: 2023-05-31 19:13:09 +0800 CST
  • 6

当操作系统版本为 RHEL 7.9 时，我们使用DELL R630我们实验室中的服务器。

这是这些服务器上文件系统的示例（从启动的角度来看）：

NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                  8:0    0  500G  0 disk
├─sda1               8:1    0    1G  0 part /boot
└─sda2               8:2    0  229G  0 part

最近我们获得了新的 DELL 服务器 R750，我们还在该服务器上安装了来自相同 ISO 的 RHEL 7.9。

现在我们有额外的启动分区 - /boot/efi。

lsblk
NAME             MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                8:0    0   500G  0 disk
├─sda1             8:1    0   512M  0 part /boot/efi
├─sda2             8:2    0     1G  0 part /boot
└─sda3             8:3    0   560G  0 part

从fstab它看起来像这样：

UUID=746E-8398          /boot/efi               vfat    defaults,uid=0,gid=0,umask=0077,shortname=winnt 0 0

由于我们在所有类型的服务器上使用相同的 ISO 文件从相同的 ISO 安装 RHEL 7.9，那么我们不明白我们是如何获得新分区的/boot/efi？

linux
Martin Hope
King David
Asked: 2023-01-06 09:01:20 +0800 CST
  • 6

我们最近注意到这个问题

我们发现 rsyslog 服务正在消耗内存，有时高达 10G

我们有不同类型的 redhat 机器，版本为 7.6 和 7.9

例如，当服务消耗超过 2 GIGA 时，是否可以自动重启服务 rsyslog（通过 systemctl 配置）？

从文档中我看到（服务路径 - /lib/systemd/system/rsyslog.service）

[Service]
MemoryLimit=2G

但不确定我们是否达到内存限制（2G）然后服务将自动重启

这是我们想要的例子

如果 rsyslog 服务消耗超过 2G，则服务将重新启动为

systemctl restart rsyslog.service

如果上述方案无法实现，那么我们希望得到其他建议

linux
Martin Hope
King David
Asked: 2022-08-23 04:53:45 +0800 CST
  • 5

我们有带 DELL 硬件的 Linux 机器，机器有 256G 内存

在添加 32G 的新 DIMM 卡之前，我们验证Configured Clock Speed是 2400MHz

所以后来我们在这台机器上添加了额外的 32G（2 个 DIMM 卡，与机器已有的 DIMM 卡类型相同），机器启动后，我们检查了Configured Clock Speed，dmidecode我们发现它已经改变了

所以Configured Clock Speed从更改2400MHz为1866 MHz

例子

添加新 DIMM 之前

dmidecode | grep "Configured Clock Speed"
        Configured Clock Speed: 2133 MHz
        Configured Clock Speed: 2133 MHz
        Configured Clock Speed: 2133 MHz
        Configured Clock Speed: 2133 MHz
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: 2133 MHz
        Configured Clock Speed: 2133 MHz
        Configured Clock Speed: 2133 MHz
        Configured Clock Speed: 2133 MHz
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown

添加新 DIMM 后

  Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: 1866 MHz
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown
        Configured Clock Speed: Unknown

那么改变的原因可能是什么？，为什么要加一个dimm内存，然后Configured Clock Speed改成这样呢？

Server is Dell PowerEdge R730 and memories are:

Memory Device
    Array Handle: 0x1000
    Error Information Handle: Not Provided
    Total Width: 72 bits
    Data Width: 64 bits
    Size: 16384 MB
    Form Factor: DIMM
    Set: 3
    Locator: A9
    Bank Locator: Not Specified
    Type: DDR4
    Type Detail: Synchronous Registered (Buffered)
    Speed: 2400 MHz
    Manufacturer: 002C0632002C
    Serial Number: 1B42681B
    Asset Tag: 001808A0
    Part Number: 18ASF2G72PDZ-2G3D1
    Rank: 2
    Configured Clock Speed: 1866 MHz
    Minimum Voltage:  1.2 V
    Maximum Voltage:  1.2 V
    Configured Voltage:  1.2 V

在此处输入图像描述

memory redhat-enterprise-linux
Martin Hope
King David
Asked: 2022-07-25 08:42:32 +0800 CST
  • 5

我们有 RHEL 机器，df -i我们可以看到一些分区是 100%（大约 inode），尽管df -h我们有空间

注意 - 磁盘是 VMDK 磁盘

 df -h
/dev/sdc                     40G   17G   23G  43% /data/sdc
/dev/sdd                     40G   23G   17G  58% /data/sdd
/dev/sde                     40G   23G   17G  58% /data/sde
/dev/sdb                     40G   26G   14G  65% /data/sdb


 df -i 
/dev/sdc                    2621440  231948  2389492    9% /data/sdc
/dev/sdd                    2621440 2616820     4620  100% /data/sdd
/dev/sde                    2621440 2613218     8222  100% /data/sde
/dev/sdb                    2621440 2621440        0  100% /data/sdb

所以我只是收集了一些选项来解决达到 100% 问题的 inode

  1. 将磁盘从 40G 扩展到 100G

然后，重新扫描操作系统上的磁盘

 echo 1 >/sys/block/${disk_name}/device/rescan

然后将磁盘大小调整为

resize2fs /dev/$disk_name
  1. 与选项 1 相同的步骤，但另外创建新文件系统 as mkfs.ext4 -j -m 0 /dev/$disk -F ，以便mkfs根据新磁盘空间增加 inode

所以根据第1步和第2步

只做第 1 步或第 1 步之外的第 2 步就足够了吗？

linux filesystems
Martin Hope
King David
Asked: 2022-07-20 02:53:54 +0800 CST
  • 5

我们想知道 - 单个存储卷读取或写入的速度有多快，以兆字节/秒为单位

例如 - 125MBps 吞吐量。

所以我们使用该smartctl命令来捕获 XXXMBps 吞吐量。价值

但我们没有从 smartctl 找到此信息

还有其他选择吗？

 smartctl -a /dev/sdb
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-514.26.2.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               SEAGATE
Product:              DL1800MM0159
Revision:             ST51
User Capacity:        1,800,360,124,416 bytes [1.80 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
Lowest aligned LBA:   0
Formatted with type 2 protection
Logical block provisioning type unreported, LBPME=0, LBPRZ=0
Rotation Rate:        10000 rpm
Form Factor:          2.5 inches
Logical Unit id:      0x5000c500bc73d273
Serial number:        WBN12G02
Device type:          disk
Transport protocol:   SAS
Local Time is:        Tue Jul 19 10:49:47 2022 UTC
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Disabled or Not Supported

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     19 C
Drive Trip Temperature:        60 C

Manufactured in week 46 of year 2018
Specified cycle count over device lifetime:  10000
Accumulated start-stop cycles:  19
Specified load-unload count over device lifetime:  300000
Accumulated load-unload cycles:  1380
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 421312352
  Blocks received from initiator = 4275942608
  Blocks read from cache and sent to initiator = 4194898282
  Number of read and write commands whose size <= segment size = 316377477
  Number of read and write commands whose size > segment size = 3066756

Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 29286.85
  number of minutes until next internal SMART test = 9

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   2663961716        5         0  2663961721          5      29253.063           0
write:         0        0        22        22         22     118463.418           0
verify:    64194        0         0     64194          0          0.000           0

Non-medium error count:     3382

No self-tests have been logged
linux hard-drive
Martin Hope
King David
Asked: 2022-07-04 00:16:23 +0800 CST
  • 4

要删除文件夹下的文件，我们可以使用以下方法查找

find /home -type f -delete

但是如何仅递归删除临时文件夹下存在的文件？

假设我们有以下临时路径示例

/home/bla/bla/temp
/home/test/temp
/home/subf/subf/subf/temp
.
.
.
/home/1/temp

如何更改查找语法以仅删除temp目录下的文件

目标是使用 find 命令以仅匹配临时文件夹并删除临时目录下的文件

linux redhat-enterprise-linux
Martin Hope
King David
Asked: 2022-06-16 08:59:52 +0800 CST
  • 4

我们有 Hadoop 集群，我们正在收集指标收集数据，以调查 Spark 应用程序的缓慢行为

经过对我们的 Hadoop 集群的长期调查

我们从 Prometheus 指标点注意到 node_disk_io_now 的值高于正常值，并且它与数据节点机器上的所有 HDFS 磁盘相关

node_disk_io_now 定义是：

node_disk_io_now (field 9) 唯一应该归零的字段。当请求被提供给适当的结构 request_queue 时递增，并在完成时递减。

我们想知道，调整内核参数是否可以对磁盘性能产生积极影响。

根据 node_disk_io_now 定义，似乎有太多任务在队列中等待，

也许一些内核参数可以帮助改善上述行为，因此队列中的任务不会长时间存在

hard-drive redhat-enterprise-linux
Martin Hope
King David
Asked: 2022-05-25 07:38:05 +0800 CST
  • 8

我们有配置chrony.conf

脚本检查 ping 是否正常ntp1和ntp2（ntp 服务器）

然后脚本将 ntp 服务器插入到/etc/chrony.conf（仅当 ping 成功时）

来自 bash 脚本的示例：

ping -c 1 ntp1

if [[ $? -eq 0 ]];then
echo "server ntp1 iburst" >> /etc/chrony.conf
else
echo "sorry so much but no ping to ntp1 server , /etc/chrony.conf will not configured "
exit 1
fi


ping -c 1 ntp2

if [[ $? -eq 0 ]];then
echo "server ntp2 iburst" >> /etc/chrony.conf
else
echo "sorry so much but no ping to ntp2 server , /etc/chrony.conf will not configured "
exit 1
fi

问题是有时用户决定禁用ping或icmp

那么在那种情况下，我们检查 ping 的场景是不相关的，我们不能将这些行添加到/etc/chrony.conf

所以我们想知道如何测试和服务器以添加ntp1ntp1和chrony配置ntp2ntp2

例如，如果ntp1似乎ntp2不是作为 ntp 服务器，那么我们不会将它们添加到 chrony 配置中

redhat-enterprise-linux ping
Martin Hope
King David
Asked: 2022-04-28 15:36:32 +0800 CST
  • 5

我们想了解net.core.netdev_max_backlog 内核值非常低且不推荐的方面是什么

在我们的 Linux RHEL 机器上，此参数的值为1000

因为我们的机器是 HADOOP 机器（BIGDATA 集群）

我们看到最佳实践是将价值增加到65536

如上所述：

https://datasayans.wordpress.com/2015/11/04/performance-kernel-tuning-for-hadoop-environment/

背景：

内核参数“netdev_max_backlog”是接收队列的最大大小。收到的帧从网卡上的环形缓冲区中取出后，将存储在此队列中。对高速卡使用高价值以防止丢失数据包。在 SIP 路由器等实时应用中，长队列必须分配高速 CPU，否则队列中的数据将过期（旧）。

那么 - 当这个内核参数的值不足时，可能是什么方面？

其他 - 参考 - https://gist.github.com/leosouzadias/e37cd189794bb78de502ac25cb605576

https://community.cloudera.com/t5/Community-Articles/OS-Configurations-for-Better-Hadoop-Performance/ta-p/247300

https://www.senia.org/2016/02/28/hadoop-and-redhat-system-tuning-etcsysctl-conf/

https://mapredit.blogspot.com/2014/11/hadoop-server-performance-tuning.html

https://gist.github.com/phaneesh/38b3d80b38cc76abb1d010f598fbc90a

https://docs.datastax.com/en/dse/5.1/dse-dev/datastax_enterprise/config/configRecommendedSettings.html

PDF - https://www.cisco.com/c/dam/en/us/solutions/collat​​eral /data-center-virtualization/big-data/cloudera-intel-cisco-hadoop-benchmark.pdf

linux redhat-enterprise-linux