Description of problem: ----------------------- To create glusterfs slice, slice_setup=yes option could be used 'service' section with 'glusterd' service. But this sets the CPUQuota to the default value of 400% Version-Release number of selected component (if applicable): ------------------------------------------------------------- gdeploy-2.0.1-8.el7rhgs How reproducible: ----------------- Not Applicable for RFE Steps to Reproduce: ------------------- Not Applicable for RFE Actual results: ---------------- Sets the CPUQuota to the default value of 400% (ie) 4 cores Expected results: ----------------- Provide a way to change the CPUQuota and don't hardcode the value of 400%
Devyani, I still don't see any option in 'service' section, that provides the flexibility to add CPUQuota. Could you please clarify ?
Hi, Commit [1] fixes this issue. It automates the task, by calculating the number of CPU's and then provides the appropriate load. Ramky can explain more on this. [1]https://github.com/gluster/gdeploy/pull/493/commits/5d950e6fbc7fdd218284a0f26100c5e995e16eb1
The way it handles is that, in hyper converged cases where there are other consumers of the CPUload . Its going to allocate 1/3 capacity to the gluster slice. It automated the process for setting up CPUQuota.
(In reply to Ramakrishna Reddy Yekulla from comment #7) > The way it handles is that, in hyper converged cases where there are other > consumers of the CPUload . Its going to allocate 1/3 capacity to the gluster > slice. It automated the process for setting up CPUQuota. Thanks Ramky and Devyani for this information.
Tested with gdeploy-2.0.2-24. By default 1/3 of the CPU is allocated for gluster process. After running gdeploy with slice setup on the machine with 2 cores. # cat /etc/systemd/system/glusterfs.slice [Slice] CPUQuota=66
The doc text looks good.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:1958