- When a large number of cached glocks are built up for GFS2, and memory pressure causes a flush of cache, the CPU utilization of
glock_workqueuebecemes very high, possibly causing the system to become unresponsive.
- When page cached is flushed out, the CPU utilization of
- We are seeing high load on our clusters. This high load is due to CPU utilization. There is an associated large drop in page cache for the GFS2 filesystem during the high load. When the large pagecache drop completes, the load goes back down to normal. The
glock_workqueueprocesses are increased during this high load time period. Very little I/O occurs during the high load event.
- A hung process was halted, and during that time the system stopped functioning for all existing users. A glock service spiked to 100% CPU, you were not able to start any new ssh sessions and it kicked existing ssh users off. The symptom went away by the time you we were able to gain access... We saw a huge spike in load and CPU usage, but I/O was at normal levels. Multiple instances of glock_workqueue using 100% cpu.
- Red Hat Enterprise Linux 5 (RHEL5) with the Resilient Storage Add On
- Observed in RHEL 5 Update 7 - Update 9
- GFS2 file system(s) mounted on multiple nodes
- Often triggered by a backup utility running against GFS2 file system(s), such as Symantec NetBackup
Subscriber exclusive content
A Red Hat Subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.
- Red Hat Enterprise Linux