Bug 525339
Summary: | Channel cloning performance problem | ||
---|---|---|---|
Product: | Red Hat Satellite 5 | Reporter: | Xixi <xdmoon> |
Component: | Server | Assignee: | Jan Pazdziora <jpazdziora> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Jiri Kastner <jkastner> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 530 | CC: | cperry, cvantuin, cwyse, drussell, gbrooksc, jesusr, jkastner, johnh, jpazdziora, mdavis, mmccune, mmraka, mstadtle, mzazrivec, stanislav.polasek, xdmoon |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | 472595 | Environment: | |
Last Closed: | 2010-07-20 17:20:09 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 472595 | ||
Bug Blocks: |
Description
Xixi
2009-09-23 22:52:10 UTC
Cloning this for Satellite 5.3.0 to make sure the fix s ported to Satellite (5.3.1 ideally) as same issue was reported at a customer's, and the config change above resolved it. Issue-tracker upcoming. Hi I am experiencing the same issue as above, only the problem has simply gone away. Are these problems experienced with embedded or standalone or both? I am currently getting them on standalone(external). I was having problems with cloning a channel. 4+ hours to clone 8117 packages on Satellite 5.3. After modifying the /etc/httpd/conf.d/zz-spacewalk-server.conf and restarting httpd. We cloned the exact same channel in about 10 seconds. HUGE difference. Taking this bugzilla. So, is this bugzilla about kickstarting performance or about clonning? The original bug 472595 is not about cloning at all. However, the comment 2 and comment 4 talk about cloning, not about kickstarts. And comment 3 is not clear about what the issue actually way. Update to this bug. The issues experienced on the field have specifically been around the following: Slowness on front end and resluting in time out on FRONT-END of Satellite 5.3, when initiating system-group creation and or channel cloning. The fix related to making changes in /etc/httpd/conf.d/zz-spacewalk-server.conf and restarting httpd appear to make the issue go away. The changes are here : <Directory "/var/www/html"> AllowOverride all EnableMMAP off EnableSendfile off </Directory> I just tried that having EnableMMAP off EnableSendfile off does not have any impact on the speed of channel cloning. I've also tried that the speed of channel cloning on 5.3.0 is comparable to 5.2.0 (tested on rlx-1-*). Per communication on the mailing list, moving from sat531-blockers back to sat531-triage. Please re-open if needed. I don't believe this should be reopened (for reasons stated at the end), but wanted to share some more information for anybody that hits this in the future. At a customer site, we had /var/satellite hosted on SAN, and /rhnsat as local storage. We tried to clone RHEL5-64bit, and every clone would cause an oracle process to peg the CPU and we let it sit for a while >30min (the browser would eventually time-out). Bouncing tomcat or all satellite services had no effect. Eventually a channel was cloned (I do not know how long it took, we left for the night). The next day I added the follow params to zz-spacewalk-www.conf to the /var/www/html directive. EnableMMAP off EnableSendfile off And bounced all satellite services just to make sure. And now cloning rhel5 takes under a minute. I'm suspecting the variable that is used by customers, but not by developers is the remote storage (nfs / SAN / etc). And I realize we specifically state /rhnsat should be on local storage, but the docs are not clear as to where /var/satellite should live. If they are, I couldn't find it. |