ClusterLabs / ClusterLabs/fence-agents
Running fence_scsi_check_hardreboot consumes CPU.
- 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