据我所知，使用 20-30TB 磁盘与 HDFS 可能会带来一些挑战，但通过适当的配置也可以有效地管理它
虽然使用 20-30TB 磁盘与 HDFS 一起使用是可能的，但需要仔细考虑块大小、重建时间、数据分布、元数据管理和性能。适当的规划和配置可以帮助缓解这些挑战。
性能：大磁盘可能会导致更长的寻道时间并可能影响性能，特别是对于需要频繁随机访问的工作负载。
基于上述情况，我们是否可以打算在新的数据节点机器上使用 20T-30T 的磁盘？
请注意，我们打算从头开始安装基于 DELL HW 的 16 个数据节点机器，每个数据节点应包含 12 个非 RAID 磁盘（每个磁盘大小约为 22T）
我们有一些红帽服务器，其详细信息如下（当操作系统磁盘大小为 230G 时）
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 230G 0 disk
├─sda1 8:1 0 1G 0 part /boot/efi
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 228G 0 part
├─VG100-lv_root 253:0 0 20G 0 lvm /
├─VG100-lv_swap 253:1 0 16G 0 lvm [SWAP]
└─VG100-lv_var 253:2 0 30G 0 lvm /var
fdisk -l
Disk /dev/sda: 193.3 GB, 193273528320 bytes, 377487360 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sda1 1 209715199 104857599+ ee GPT
目标是在当前 /var 为 30G 且根文件系统为 20G 的情况下，基于磁盘大小为 230G 来增加 /var 和根文件系统
因此，我们从以下步骤开始，该步骤应该为我们提供足够的 PFREE 或足够的“物理可用”空间。
parted /dev/sda resizepart 3 100%
Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?
parted: invalid token: 3
Fix/Ignore/Cancel?
sgdisk -e /dev/sda
注意 - sgdisk：修复备份 GPT 表的最简单方法是使用带有 -e 选项的 sgdisk 命令，该命令将备份 GPT 数据结构移动到磁盘末尾
parted /dev/sda resizepart 3 100%
Information: You may need to update /etc/fstab.
partprobe /dev/sda
pvresize /dev/sda
Failed to find physical volume "/dev/sda".
0 physical volume(s) resized or updated / 0 physical volume(s) not resized
但来自 pvsPfree仍为 0
# pvs
PV VG Fmt Attr PSize PFree
/dev/sda3 VG100 lvm2 a-- 66.00g 0
关于能够增加 /var 和根文件系统分区的其他方法有什么想法吗？
更多信息
# vgs
VG #PV #LV #SN Attr VSize VFree
VG100 1 3 0 wz--n- <228.00g <162.00g
我们也尝试这个（例如）
lvextend -l +100%FREE -r /dev/mapper/VG100-lv_root
Size of logical volume VG100/lv_root unchanged from 20.00 GiB (5120 extents).
Logical volume VG100/lv_root successfully resized.
xfs_growfs /dev/mapper/VG100-lv_root
但根文件系统的大小相同
df -h | grep VG100-lv_root
/dev/mapper/VG100-lv_root 20G 3.8G 17G 19% /
pvs
PV VG Fmt Attr PSize PFree
/dev/sda3 VG100 lvm2 a-- 66.00g 0
我们有带有 3 台虚拟机的 kafka 集群。，当每台kafka机器都使用sdb磁盘（VMDK磁盘）来存储数据时
在所有机器上我们看到以下内核消息
[1123783.849575] EXT4-fs (sdb): error count since last fsck: 9
[1123783.849582] EXT4-fs (sdb): initial error at time 1595958527: ext4_writepages:2414
[1123783.849586] EXT4-fs (sdb): last error at time 1613639279: ext4_put_super:791
[1210205.709917] EXT4-fs (sdb): error count since last fsck: 9
[1210205.709937] EXT4-fs (sdb): initial error at time 1595958527: ext4_writepages:2414
[1210205.709944] EXT4-fs (sdb): last error at time 1613639279: ext4_put_super:791
[1296627.570121] EXT4-fs (sdb): error count since last fsck: 9
[1296627.570141] EXT4-fs (sdb): initial error at time 1595958527: ext4_writepages:2414
[1296627.570147] EXT4-fs (sdb): last error at time 1613639279: ext4_put_super:791
[1383049.419003] EXT4-fs (sdb): error count since last fsck: 9
[1383049.419019] EXT4-fs (sdb): initial error at time 1595958527: ext4_writepages:2414
[1383049.419025] EXT4-fs (sdb): last error at time 1613639279: ext4_put_super:791
[1469471.269771] EXT4-fs (sdb): error count since last fsck: 9
.
.
.
红帽对此消息的解释如下。（来自案例 - https://access.redhat.com/solutions/383993）
问题
我在 /var/log/messages 中看到以下几行：
kernel: EXT4-fs (sdd1): error count: 5
kernel: EXT4-fs (sdd1): initial error at 1369732760: ext4_lookup:1044: inode 11534366
kernel: EXT4-fs (sdd1): last error at 1369733705: ext4_lookup:1044: inode 11534366
解决方法 这些不是错误，而是信息性消息；然而，他们可能引用了其他可能的历史错误。一旦成功运行 fsck，这些错误计数就应该重置；然而，在 e2fsprogs-1.41.12-18 之前，一个错误阻止了重置。此问题已通过勘误表在 e2fsprogs-1.41.12-18 中得到纠正。
我们在 Kafka 集群上收到的消息与 Redhat 情况几乎没有什么不同
所以我们更担心sdb磁盘，
根据红帽的说法，他们并不那么担心，因为他们解释了这些消息，因为它们是信息性消息
因此，关于我的内核消息，我可以umount从挂载点读取磁盘并执行以下操作fsck来修复错误，
但我的问题是我有多少需要担心以下消息：
[1123783.849575] EXT4-fs (sdb): error count since last fsck: 9
[1123783.849582] EXT4-fs (sdb): initial error at time 1595958527: ext4_writepages:2414
[1123783.849586] EXT4-fs (sdb): last error at time 1613639279: ext4_put_super:791
[1210205.709917] EXT4-fs (sdb): error count since last fsck: 9
[1210205.709937] EXT4-fs (sdb): initial error at time 1595958527: ext4_writepages:2414
如何了解 RHEL 7.x 计算机上每个端口的并发连接数
例如，假设我们使用 XXXX 并发连接连接到端口 9080。
wget http://server_mngmnt.jupiter.com:9080 &
wget http://server_mngmnt.jupiter.com:9080 &
wget http://server_mngmnt.jupiter.com:9080 &
wget http://server_mngmnt.jupiter.com:9080 &
wget http://server_mngmnt.jupiter.com:9080 &
.
.
.
第二 - 端口 9080 的巨大并发连接可能会产生什么结果？
从我的机器
more /etc/security/limits.conf
# End of file
* soft nofile 25000
* hard nofile 25000
sysctl -n fs.file-max
500000
ulimit -n
63536
swpd字段表示已经使用了多少交换空间；当系统物理内存已满并且Linux内核开始使用交换分区/文件时，该值会增加。当系统物理内存和交换空间已耗尽时
从我们的 RHEL 7.2 机器上我们可以看到以下内容
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
3 0 1029076 6695152 4 49021608 1 1 520 32 2 2 9 1 90 0 0
2 0 1029076 6694024 4 49022924 0 0 19612 0 5761 4269 7 1 91 0 0
8 0 1029076 6665220 4 49021688 0 0 14812 707 22450 26191 13 3 84 0 0
2 0 1029076 6656396 4 49021704 0 0 15748 0 17994 21252 9 2 88 0 0
2 0 1029088 6649536 4 49022448 0 12 33972 12 13426 14773 8 2 90 1 0
2 0 1029088 6687988 4 49022604 0 0 31212 0 6085 4391 7 2 91 0 0
2 0 1029088 6688688 4 49022340 0 0 27040 9 7001 8469 4 1 95 1 0
3 0 1029092 6689572 4 49022820 0 4 12136 28 3390 2773 4 0 96 0 0
1 0 1029092 6689856 4 49022224 0 0 13776 0 3460 2841 4 0 96 0 0
1 0 1029092 6690356 4 49021820 0 0 18444 0 3445 2819 4 0 96 0 0
1 0 1029092 6689864 4 49021520 0 0 18768 0 3743 3005 4 0 96 0 0
1 0 1029092 6693856 4 49021452 0 0 17544 0 3406 2732 4 0 96 0 0
1 0 1029092 6694048 4 49021208 0 0 24244 292 4654 4816 4 1 95 0 0
1 0 1029092 6695096 4 49021312 0 0 15572 0 3431 2835 4 0 96 0 0
2 0 1029092 6694536 4 49022072 0 0 17476 0 5065 4033 7 1 91 0 0
2 1 1029092 6685364 4 49022140 0 0 28112 9 24914 30798 10 3 86 1 0
1 0 1029092 6684160 4 49021280 0 0 10356 104 14245 16378 5 2 93 0 0
1 0 1029092 6671432 4 49022212 0 0 12816 20 11465 13620 5 1 94 0 0
1 0 1029092 6707700 4 49022364 0 0 19840 0 4113 3603 4 0 95 0 0
2 0 1029092 6706948 4 49022364 0 0 18128 0 3324 2833 4 0 96 0 0
swpd 的高值表明存在问题吗？
free -g
total used free shared buff/cache available
Mem: 122 69 6 8 46 43
Swap: 15 0 14
vmstat 1 20
128195440 K total memory
72465912 K used memory
77700088 K active memory
36918416 K inactive memory
6707164 K free memory
4 K buffer memory
49022360 K swap cache
16351228 K total swap
1029076 K used swap
15322152 K free swap
137196351 non-nice user cpu ticks
778 nice user cpu ticks
21836716 system cpu ticks
1437416566 idle cpu ticks
7095049 IO-wait cpu ticks
0 IRQ cpu ticks
1280657 softirq cpu ticks
0 stolen cpu ticks
8346063429 pages paged in
515040249 pages paged out
3267044 pages swapped in
5005632 pages swapped out
4242627451 interrupts
1713287115 CPU context switches
1705353038 boot time
31037695 forks
sar -B 2 5
03:37:14 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
03:37:16 PM 0.00 6.00 133.50 0.00 93.00 0.00 0.00 0.00 0.00
03:37:18 PM 0.00 0.00 34.50 0.00 91.50 0.00 0.00 0.00 0.00
03:37:20 PM 0.00 4.50 50683.50 0.00 19022.00 0.00 0.00 0.00 0.00
03:37:22 PM 60.00 2.00 11028.50 0.00 10382.00 0.00 0.00 0.00 0.00
03:37:24 PM 0.00 0.00 805.00 0.00 1205.50 0.00 0.00 0.00 0.00
Average: 12.00 2.50 12537.00 0.00 6158.80 0.00 0.00 0.00 0.00
sar -d
03:34:42 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
03:34:52 PM sda 448.60 20769.60 66.30 46.45 0.60 1.35 0.15 6.73
我们在物理机上安装了RHEL 7.9版本，当sda设备是操作系统时
机器有以下磁盘。
sda - OS disk
sdb - data disk
sdc - data disk
重新启动后操作系统磁盘设备更改为sdc以下内容并sda成为数据磁盘的一部分
sdc 8:32 0 558.4G 0 disk
├─sdc1 8:33 0 500M 0 part /boot
└─sdc2 8:34 0 557.9G 0 part
├─VG-VOL_root 253:0 0 100G 0 lvm /
├─VG-VOL_swap 253:1 0 16G 0 lvm
├─VG-VOL_var 253:2 0 200G 0 lvm /var
我们假设下次sdc可能会重新启动？将再次更改为sda应有的样子
但如何防止sda磁盘更改为其他设备呢？重启后？
根据红帽文档，他们建议设置以下内容：
用户可以通过在 /etc/sysconfig/grub 文件中附加“scsi_mod.scan=sync”来修改内核启动参数，以获得更一致的磁盘字母。 它不能保证在所有情况下设备名称一致。应谨慎使用此选项，因为它会减慢磁盘发现过程，从而减慢整个引导过程。
但是这个配置真的有scsi_mod.scan=sync帮助 /etc/sysconfig/grub 吗？
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VG/VOL_root rd.lvm.lv=VG/lv_swap rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
scsi_mod.scan=sync <---------------
sda为了避免重新启动后磁盘设备发生更改，我们可以采取哪些其他选项？
来自服务器的其他一些有用的详细信息
ls -ltr /dev/disk/by-id | grep sdc
lrwxrwxrwx 1 root root 9 Dec 28 11:43 wwn-0x6588a5a0ef7f4d0023880046051e7a74 -> ../../sdc
lrwxrwxrwx 1 root root 9 Dec 28 11:43 scsi-36588a5a0ef7f4d0023880046051e7a74 -> ../../sdc
lrwxrwxrwx 1 root root 10 Dec 28 11:43 wwn-0x6588a5a0ef7f4d0023880046051e7a74-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Dec 28 11:43 scsi-36588a5a0ef7f4d0023880046051e7a74-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Dec 28 11:43 lvm-pv-uuid-2Ee6HA-9vVx-bUVq-noyG-U0Nq-AVMz-oI56ji -> ../../sdc2
lrwxrwxrwx 1 root root 10 Dec 28 11:43 wwn-0x6588a5a0ef7f4d0023880046051e7a74-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Dec 28 11:43 scsi-36588a5a0ef7f4d0023880046051e7a74-part1 -> ../../sdc1
cat /etc/fstab | grep boot
UUID=f57f0346-9e6c-429e-b80f-3871334bae35 /boot xfs defaults 0 0
我们有 254 台物理服务器，所有机器都是 DELL 服务器 R740。
服务器是 Hadoop 集群的一部分。其中大多数拥有HDFS文件系统和数据节点和节点管理器服务，其中一部分是Kafka机器。
物理服务器上安装的操作系统是RHEL 7.9
现在我们要向集群添加额外的 52 台物理服务器。但我们只能添加R760必须安装的DELL 服务器RHEL 8.6
每台物理服务器包括256G和64个核心。
问题是我们无法使用 RHEL 8.6 版本，因为 Hadoop 版本。不适合 RHEL 8.6
因此，我们需要保留 RHEL 7.9 版本，但另一方面 DELL 服务器 R760 无法与 RHEL 7.9 保持一致
所以，我们正在考虑使用VM机器而不是DELL R760物理机。
我们很清楚虚拟机的性能与物理机的性能不同。
但我们可以这么说。如果我们将虚拟机上的默认内存从 256G 增加到 384G，并将核心数从 64 增加到 80 个核心
因此，如果我们将 VM 机器设置为具有更多内存和 CPU 的上述规格
那么添加额外的虚拟机有意义吗？到Hadoop集群而不担心性能问题？
从本质上讲，页面缓存是虚拟文件系统 (VFS) 的一部分，您可以猜到，其主要目的是改善读写操作的 IO 延迟。
在计算中，页面缓存（有时也称为磁盘缓存）是源自辅助存储设备（例如硬盘驱动器 (HDD) 或固态驱动器 (SSD)）的页面的透明缓存。
操作系统将页面缓存保留在主内存 (RAM) 的其他未使用部分中，从而可以更快地访问缓存页面的内容并提高整体性能。
基于以上所述，现有的用于监控页面缓存的工具有哪些？我希望监控使用情况、点击率，尤其是脏页。
操作系统版本为RHEL 7.X。
我们的 DELL 机器很少（有RHEL 7.6） ，当我们更换机器上的 DIMM 卡时，因为我们从内核消息中看到的错误
一段时间后，我们再次检查内核消息，发现以下内容，我们可以看到有关 RAM 内存的错误（也与 RHEL 案例有关 - https://access.redhat.com/solutions/6961932）
[Mon May 8 21:08:01 2023] EDAC sbridge MC0: PROCESSOR 0:406f1 TIME 1683580080 SOCKET 0 APIC 0
[Mon May 8 21:08:01 2023] EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#1 (channel:1 slot:1 page:0x6f3c77 offset:0xc80 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:4)
[Mon May 8 21:08:21 2023] mce: [Hardware Error]: Machine check events logged
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 4
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: It has been corrected by h/w and requires no further action
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: event severity: corrected
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: Error 0, type: corrected
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: fru_text: B6
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: section_type: memory error
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: error_status: 0x0000000000000400
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: physical_address: 0x000000446e0d5f00
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: node: 1 card: 1 module: 1 rank: 0 bank: 3 row: 64982 column: 888
[Tue May 9 05:30:29 2023] {13}[Hardware Error]: error_type: 2, single-bit ECC
[Tue May 9 05:30:29 2023] EDAC sbridge MC0: HANDLING MCE MEMORY ERROR
[Tue May 9 05:30:29 2023] EDAC sbridge MC0: CPU 0: Machine Check Event: 0 Bank 1: 940000000000009f
[Tue May 9 05:30:29 2023] EDAC sbridge MC0: TSC 30d2ef7e9bfda
[Tue May 9 05:30:29 2023] EDAC sbridge MC0: ADDR 446e0d5f00
[Tue May 9 05:30:29 2023] EDAC sbridge MC0: MISC 0
[Tue May 9 05:30:29 2023] EDAC sbridge MC0: PROCESSOR 0:406f1 TIME 1683610228 SOCKET 0 APIC 0
[Tue May 9 05:30:29 2023] EDAC MC1: 0 CE memory read error on CPU_SrcID#1_Ha#0_Chan#1_DIMM#1 (channel:1 slot:1 page:0x446e0d5 offset:0xf00 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:1 ha:0 channel_mask:2 rank:4)
[Tue May 9 05:30:51 2023] mce: [Hardware Error]: Machine check events logged
[Tue May 9 17:52:21 2023] perf: interrupt took too long (380026 > 7861), lowering kernel.perf_event_max_sample_rate to 1000
[Wed May 10 06:27:17 2023] warning: `lshw' uses legacy ethtool link settings API, link modes are only partially reported
只是为了确保上述消息不是随机消息，我们决定重新启动机器并查看是否重现了有关内存的错误消息
但有关 RAM 内存的错误消息仍然存在。
所以我们对从内核消息中看到的问题感到困惑
尽管我们更换了 DIMM 卡，但我们如何仍然得到关于 RAM 的错误
我必须在这里提供有关我们从IDRAC看到的内容的更多信息
因为我们可以在上面的 IDRAC 上完成有关 DIMM 卡或 RAM 内存的信息
所以问题是 -dmesg尽管更换了所有 DIMM，但（内核消息）怎么会抱怨 RAM 内存？
有没有可能是其他东西坏了而不是 DIMM 卡？比如DELL机器的主板？
dmesg这是来自重要生产服务器（RHEL 7.2 - DELL 机器硬件）的输出示例，因为我们可以看到sde服务器中的磁盘快死了
[Wed Jun 30 11:24:58 2021] sd 0:2:4:0: [sde] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Jun 30 11:26:18 2021] sd 0:2:4:0: [sde] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Jun 30 11:26:18 2021] sd 0:2:4:0: [sde] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Jun 30 11:27:28 2021] sd 0:2:4:0: [sde] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Jun 30 11:27:46 2021] sd 0:2:4:0: [sde] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
有趣的是，这些消息是旧的2021，我们没有在2022/2023
基于这些事实，我想问一下是否应该根据来自的错误磁盘消息考虑更换磁盘2021
第二个重要问题是如何通过以下方式捕获新的内核消息dmesg
是否可以重新创建新的内核消息？
据我所知，也许重启机器可以帮助解决这个问题，但我想避免机器重启
我们想知道我们是否不能通过balloon memory调整以下值来限制 Linux 机器上的 -
Mem.CtlMaxPercent
例如，是否可以将 20% 设置为Mem.CtlMaxPercent默认值 65%？
目标是在 RHEL 机器上提供更多可用内存，因为 RHEL 机器上的气球内存大约是 30G，我们希望减小这个值，以便 RHEL 机器有更多可用内存
参考 - https://nerdblurt.com/vmware-memory-ballooning-sched-mem-maxmemctl-versus-mem-ctlmaxpercent/
Sched.Mem.MaxMemCtl：通过膨胀从所选虚拟机回收的最大内存量，以兆字节 (MB) 为单位。如果 ESXi 主机需要回收额外的内存，它会被强制交换。交换不如膨胀。默认值 = -1（无限制）（VM 高级设置）
Mem.CtlMaxPercent：根据配置的内存大小的百分比，限制使用内存气球驱动程序 (vmmemctl) 从任何虚拟机回收的最大内存量。指定 0 以禁用所有虚拟机的回收。默认值 = 65%（主机高级设置）*
我们有 57 台 rhel 服务器机器——版本 7.5
这些机器具有强大的硬件，如 128G 内存和 32 个 CPU，
我们计划在所有机器上安装 docker 服务，以便在 docker 上运行几个容器
我们面临以下困境
sda，所以/var/lib/docker会是OS上的文件夹或者
要为 docker 添加专用磁盘sdb，以便在sdb不是 OS 磁盘的磁盘上运行 docker，
例如添加新磁盘 -sdb并安装sdb到/var/lib/docker
为docker添加额外的专用磁盘作为sdb是否合理，以避免OS/disk/Docker方面的性能方面 ？
我们有旧RHEL机器version 7.2
我们准备在这台服务器上安装 docker 服务
问题是服务器的文件系统是使用ftype=0参数创建的，而 docker 需要ftype=1
一种选择当然是使用 mkfs 格式化磁盘并使用ftype=1
但是我们想保留原来的操作系统而不是格式化磁盘
第二种选择是执行帖子中定义的步骤 - https://superuser.com/questions/1321926/recreating-an-xfs-file-system-with-ftype-1/1321963#1321963
但是这个步骤是有风险的，需要关闭服务器
尽管我们正在寻找第三种替代方案，以便在 rhel 7.2 版上实现 docker 安装ftype=0
例如，有趣的方向可能是通过向服务器添加一个新磁盘并创建XFS文件系统，使用ftype=1，但我们不确定如何在附加磁盘上定义 docker 安装（因为这个磁盘实际上没有操作系统）。
我们很乐意开箱即用地获得任何其他想法。
我们有rhel 7.2机器
服务器有以下服务
[root@server1 system]# more rc_build_infra.service
[Unit]
Description=infra Manager Server
Requires=network.target remote-fs.target
After=network.target remote-fs.target
[Service]
Restart=on-failure
StartLimitInterval=5min
StartLimitBurst=4
LimitMEMLOCK=infinity
LimitNOFILE=65535
Type=simple
User=infra_bb
Group=mc_group
Environment=JAVA_HOME=/usr/bin/java
ExecStart=/opt/infra_start.sh
[Install]
WantedBy=multi-user.target
现在我想建立一个类似的服务，但新服务应该在之后执行 -rc_build_infra.service
新服务中应该有哪些配置
所以新服务将在机器启动期间执行 -rc_build_infra.service
我们有 redhat 7.5 服务器
我们怀疑端口 50070 没有被服务正确关闭，（我们通过 netstat 和 PID 未找到）但是从日志中我们可以看到端口正在使用中
因此我们尝试执行以下操作，例如
ss --kill state listening src :50070
ss: unrecognized option '--kill'
Usage: ss [ OPTIONS ]
ss [ OPTIONS ] [ FILTER ]
-h, --help this message
-V, --version output version information
-n, --numeric don't resolve service names
-r, --resolve resolve host names
-a, --all display all sockets
-l, --listening display listening sockets
-o, --options show timer information
-e, --extended show detailed socket information
-m, --memory show socket memory usage
-p, --processes show process using socket
-i, --info show internal TCP information
-s, --summary show socket usage summary
-b, --bpf show bpf filter socket information
-Z, --context display process SELinux security contexts
-z, --contexts display process and socket SELinux security contexts
-N, --net switch to the specified network namespace name
-4, --ipv4 display only IP version 4 sockets
-6, --ipv6 display only IP version 6 sockets
-0, --packet display PACKET sockets
-t, --tcp display only TCP sockets
-u, --udp display only UDP sockets
-d, --dccp display only DCCP sockets
-w, --raw display only RAW sockets
-x, --unix display only Unix domain sockets
-f, --family=FAMILY display sockets of type FAMILY
-A, --query=QUERY, --socket=QUERY
QUERY := {all|inet|tcp|udp|raw|unix|unix_dgram|unix_stream|unix_seqpacket|packet|netlink}[,QUERY]
但 ss 不包括杀戮标志
什么是正确关闭端口或释放 rhel 机器上的端口的选项？
日志是：
2020-07-18 21:26:22,753 INFO impl.MetricsSystemImpl (MetricsSystemImpl.java:shutdown(606)) - NameNode metrics system shutdown complete.
2020-07-18 21:26:22,753 ERROR namenode.NameNode (NameNode.java:main(1783)) - Failed to start namenode.
java.net.BindException: Port in use: linux.gg.com:50070
at org.apache.hadoop.http.HttpServer2.constructBindException(HttpServer2.java:1001)
at org.apache.hadoop.http.HttpServer2.bindForSinglePort(HttpServer2.java:1023)
at org.apache.hadoop.http.HttpServer2.openListeners(HttpServer2.java:1080)
at org.apache.hadoop.http.HttpServer2.start(HttpServer2.java:937)
at org.apache.hadoop.hdfs.server.namenode.NameNodeHttpServer.start(NameNodeHttpServer.java:170)
at org.apache.hadoop.hdfs.server.namenode.NameNode.startHttpServer(NameNode.java:942)
at org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:755)
at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:1001)
at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:985)
at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1710)
at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1778)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:216)
at org.apache.hadoop.http.HttpServer2.bindListener(HttpServer2.java:988)
at org.apache.hadoop.http.HttpServer2.bindForSinglePort(HttpServer2.java:1019)
... 9 more
2020-07-18 21:26:22,755 INFO util.ExitUtil (ExitUtil.java:terminate(124)) - Exiting with status 1
2020-07-18 21:26:22,757 INFO namenode.NameNode (LogAdapter.java:info(47)) - SHUTDOWN_MSG:
/************************************************************
SHUTDOWN_MSG: Shutting down NameNode at
************************************************************/
[root@linux hdfs]#
[root@linux hdfs]#
[root@linux hdfs]# netstat -tulpn | grep 50070 ( no PID number is returned )
我们有一个 VM Linux 服务器，该hot add功能在 VCenter 中被禁用。
目前，我们无法关闭机器，并且功能是disable，因此我们无法为机器添加内存资源。
那么您知道如何在hot add不关闭 Linux redhat 机器电源的情况下启用该功能吗？
我们在一个集群中有 16 台 Linux RHEL 7.5 服务器，服务器与 NTP 服务器的 crony 服务同步
我们有两个问题
如何知道我们的服务器上是否配置了夏令时？
如何在我们的 Redhat Enterprise Linux 7 服务器上禁用 DST？
在我们的 linux rhel 服务器上fs.file-max设置100000
sysctl -p | grep fs.file-max
fs.file-max = 100000
据我了解，file-max 内核参数指的是打开的文件描述符，而 file-nr 为我们提供了当前打开的文件描述符的数量。但是 lsof 会列出所有打开的文件，包括不使用文件描述符的文件——例如当前工作目录、内存映射库文件和可执行文本文件。
所以回到我的问题
剂量以下 lsof ，真的很好地表明我们达到了 fs.file-max 值吗？
lsof | wc -l
或者
[[ ` lsof | wc -l ` -gt 100000 ]] && echo "please increase the fs.file-max"
我们有 5 台 Linux rhel 机器，我们注意到所有机器都同时挂起
从消息文件中，我们可以看到以下内容
Dec 29 19:54:25 localhost kernel: pci 0000:ff:12.4: BAR 4: failed to assign [mem size 0x00000040]
Dec 29 19:54:25 localhost kernel: pci 0000:ff:12.0: BAR 1: failed to assign [mem size 0x00000010]
这个内核消息是否可能是 linux 崩溃/挂起的原因？
根据redhat，他们建议更新内核版本（https://access.redhat.com/solutions/2772311）
但他们没有提到任何关于 linux 崩溃/挂起的信息
是否可以通过重新编辑 fstab 文件来运行 xfs 修复？
/dev/mapper/vg-linux_root / xfs defaults 0 0
UUID=7de1dc5c-b605-4a6f-bdf1-f1e869f6ffb9 /boot xfs defaults 0 0
/dev/mapper/vg-linux_var /var xfs defaults 0 0
/dev/mapper/vg-linux_swap swap swap defaults 0 0
我不确定，但将最后一个数字从 0 替换为 1 ，对吗？