ClusterLabs / ClusterLabs/fence-agents

Running fence_scsi_check_hardreboot consumes CPU.

Open
#313 11 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
125
Forks
184
PR merge metrics
No merged PRs in 30d

Description

Hi All,

Configure a cluster using fence_scsi in a virtual environment to which only one CPU core is allocated.

When fence_scsi_check_hardreboot is used together with the watchdog service to configure the pacemaker cluster, fence_scsi_check_hardreboot uses 20% of the CPU every second.

When this happens, pacemaker frequently outputs the following log.

```
(snip)
12:56:45 xx pacemaker-controld [10137] (throttle_check_thresholds) notice: High CPU load detected: 2.080000
12:57:15 xx pacemaker-controld [10137] (throttle_check_thresholds) notice: High CPU load detected: 1.930000
12:57:45 xx pacemaker-controld [10137] (throttle_check_thresholds) notice: High CPU load detected: 1.540000
12:58:15 xx pacemaker-controld [10137] (throttle_check_thresholds) notice: High CPU load detected: 1.470000
12:58:45 xx pacemaker-controld [10137] (throttle_check_thresholds) notice: High CPU load detected: 1.230000
12:59:15 xx pacemaker-controld [10137] (throttle_check_thresholds) notice: High CPU load detected: 1.650000
(snip)
```

Some improvement can be achieved by increasing the number of CPU cores or increasing the monitoring interval of the watchdog service.
However, some users may not be able to change core assignments. Increasing the monitoring interval also affects the failover time when a failure occurs.

Is there any way to improve the fence_scsi_check_hardreboot script to solve the problem?
(Can make the processing of fence_scsi_check_hardreboot a little lighter?)

Best Regards,
Hideo Yamauchi.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by examining and profiling the fence_scsi_check_hardreboot script while the watchdog service runs on a one-core virtual cluster. Compare CPU usage and failover behavior before and after any investigation, with the goal of reducing recurring CPU consumption without weakening hard-reboot detection.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devops, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.