1. 问题描述

free -m查看内存使用情况：

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7821        7412         162           1         246         173
Swap:          2047        1839         208

htop命令按MEM%排序（快捷键M）：
02.png

发现 dmeventd 守护进程占用了大量的内存。
pstree命令查看 dmeventd 进程树。

$ pstree `pgrep dmeventd`
dmeventd───127*[{dmeventd}]

测试发现，dmeventd的子进程数量会随着k8s pvc的创建而增加，随着pvc的删除而减少。

2. 问题分析

2.1 设备映射器（Device Mapper）

在详细介绍 dm-event 服务之前，先了解一下设备映射器（Device Mapper）。设备映射器是 Linux 内核中的一个框架，用于在块设备上创建虚拟设备。这些虚拟设备可以进行各种操作，如逻辑卷管理、镜像、快照、条带化等。设备映射器通过称为“映射表”的数据结构定义这些操作。

2.2 dmeventd（Device Mapper Event Daemon）

dm-event 服务是 Linux 设备映射器（Device Mapper）子系统的一部分，主要用于监控和管理设备映射器设备的事件。dmeventd（Device Mapper Event Daemon）是该服务的核心守护进程，负责处理和响应与设备映射器相关的各种事件。
dmeventd 通常与逻辑卷管理器（LVM）一起使用，以提供以下功能：

  • 自动恢复：在设备故障时自动尝试恢复。
  • 监控和报警：监控设备状态并生成报警。
  • 日志记录：记录设备状态和事件日志。
  • 快照管理：管理逻辑卷的快照。

2.3 GlusterFS 与 dmeventd 的关系

在使用 GlusterFS 分布式文件系统时，通常会使用 LVM（Logical Volume Manager）来管理和配置存储卷。
GlusterFS 本身作为一个分布式文件系统，它并不直接依赖于 dmeventd 服务。dmeventd 通常用于监听和响应设备映射事件，这在 LVM 等场景下比较常见，但不是 GlusterFS 的核心依赖。在使用 GlusterFS 时，并不要求系统必须运行 dmeventd。
在GlusterFS官网中，也没有找到 dmeventd 相关内容。

3. 问题解决

综上分析，在 GlusterFS 分布式服务器中，如果 dmeventd 占用了大量内存，重启 dmeventd 是一种常见的解决方案，可以尝试释放内存和恢复其正常运行状态。

$ systemctl restart dm-event

4. 验证结果

4.1 查看内存使用情况

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7821        1562        5970           7         288        6002
Swap:          2047        1687         360

02.png

可以看到 dmeventd 占用的内存已经释放。
查看 dmeventd 进程树：

$ pstree `pgrep dmeventd`
dmeventd

之前随LV增加的 dmeventd 子进程也已经清除，仅剩重启后的dmeventd主进程。

4.2 K8S创建测试PVC

$ cat >> test-dmeventd-pvc.yaml << 'EOF'
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-dmeventd-logs
  namespace: lamxops-test
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: heketi-gfs-r2
  resources:
    requests:
      storage: 1Gi
EOF

$ kubectl create -f test-dmeventd-pvc.yaml
$ kubectl get pv | grep test-dmeventd
pvc-d8d67716-1480-4c83-9f8d-7dd9181f0bed   1Gi        RWX            Delete           Bound    lamxops-test/test-dmeventd-logs                            heketi-gfs-r2            12s
$ kubectl describe pv pvc-d8d67716-1480-4c83-9f8d-7dd9181f0bed | grep Path
    Path:                vol_29c819a7dca4cc4173fbf8f257dad53b

在GlusterFS服务器上查看 Volume vol_29c819a7dca4cc4173fbf8f257dad53b的状态：

$ gluster volume info vol_29c819a7dca4cc4173fbf8f257dad53b
 
Volume Name: vol_29c819a7dca4cc4173fbf8f257dad53b
Type: Replicate
Volume ID: bd0dc38b-f40f-425f-a1ce-f8eadc8ee1a2
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 172.16.0.65:/var/lib/heketi/mounts/vg_0d76fd5d15fb483975b2b18e09f95259/brick_b74d3149ce0c501442737adc6ac3996f/brick
Brick2: 172.16.0.66:/var/lib/heketi/mounts/vg_f5acede91897a1c7e3ed3c5359304f39/brick_375ede46402fc85a037a6bbe4a7db53c/brick
Options Reconfigured:
user.heketi.id: 29c819a7dca4cc4173fbf8f257dad53b
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

$ gluster volume status vol_29c819a7dca4cc4173fbf8f257dad53b
Status of volume: vol_29c819a7dca4cc4173fbf8f257dad53b
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick 172.16.0.65:/var/lib/heketi/mounts/v
g_0d76fd5d15fb483975b2b18e09f95259/brick_b7
4d3149ce0c501442737adc6ac3996f/brick        49278     0          Y       4811 
Brick 172.16.0.66:/var/lib/heketi/mounts/v
g_f5acede91897a1c7e3ed3c5359304f39/brick_37
5ede46402fc85a037a6bbe4a7db53c/brick        49278     0          Y       7498 
Self-heal Daemon on localhost               N/A       N/A        Y       11364
Self-heal Daemon on gfs-r2-node01           N/A       N/A        Y       11390
 
Task Status of Volume vol_29c819a7dca4cc4173fbf8f257dad53b
------------------------------------------------------------------------------
There are no active volume tasks

PVC创建成功。

4.3 查看 dmeventd 进程树

$ pstree `pgrep dmeventd`
dmeventd───2*[{dmeventd}]

随着新的PVC创建，GlusterFS通过LVM创建了LV，因此 dmeventd 进程数量+1。

4.4 K8S删除创建的测试PVC

$ kubectl delete -f test-dmeventd-pvc.yaml 
persistentvolumeclaim "test-dmeventd-logs" deleted

GlusterFS 服务器上查看之前创建的Volume：

$ gluster volume status vol_29c819a7dca4cc4173fbf8f257dad53b
Volume vol_29c819a7dca4cc4173fbf8f257dad53b does not exist

再次查看 dmeventd 进程树：

$ pstree `pgrep dmeventd`
dmeventd

5. 总结

目前在K8S测试服务的GlusterFS集群上进行了测试实施，待稳定运行一段时间后，再到K8S正式服务的GlusterFS集群服务器上实施。