Description of problem: Configuration Overview page takes ~90 seconds to load. Deploying files are also slow and occasionally errors out (in the beginning of the report it used to consistently error out with traceback). web UI /rhn/configuration/Overview.do page is slow - it loads in about 90-120 sec for me. I took a snapshot vs. oracle statspack for the single action of clicking on and thus loading this page. There may be performance issues in java layer as well, but as far as oracle, the following query is shown in the report as taking about 1 minute - ... CPU CPU per Elapsd Old Time (s) Executions Exec (s) %Total Time (s) Buffer Gets Hash Value ---------- ------------ ---------- ------ ---------- --------------- ---------- 0.45 1 0.45 37.2 55.33 24,538 3763434616 SELECT DISTINCT TC.* from (select CF.id, CC.id AS config_channe l_id, CFT.label AS type, CFN.path, CCT.label AS co nfig_channel_type, CF.modified, CC.name AS config_ channel_name from rhnConfigFile CF, rhnConfigChannel CC , rhnConfigFileName CFN, rhnConfigChannelType CCT, ... which corresponds to recent_modified_config_files_for_user query in code/src/com/redhat/rhn/common/db/datasource/xml/config_queries.xml: ... <mode name="recent_modified_config_files_for_user" class="com.redhat.rhn.frontend.dto.ConfigFileDto"> <query params="org_id, user_id, num"> SELECT DISTINCT TC.* from (select CF.id, CC.id AS config_channel_id, CFT.label AS type, CFN.path, CCT.label AS config_channel_type, CF.modified, CC.name AS config_channel_name from rhnConfigFile CF, rhnConfigChannel CC, rhnConfigFileName CFN, rhnConfigChannelType CCT, rhnConfigRevision CR, rhnConfigFileType CFT where CF.config_channel_id = CC.id and CC.org_id = :org_id and CC.confchan_type_id = CCT.id and CF.config_file_name_id = CFN.id and CF.latest_config_revision_id = CR.id and CR.config_file_type_id = CFT.id and rhn_config_channel.get_user_file_access(CF.id, :user_id) = 1 order by CF.modified desc) TC where rownum <= :num </query> </mode> Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Explain plan identified usage of parallel processing of RHNUSERSERVERPERMSDUPES view caused by indexes created with parallel degree set to 6. After altering indexes to noparallel alter index RHN_SGMEMBERS_SGID_SID_IDX noparallel; alter index RHN_UGMEMBERS_UID_UGID_UQ noparallel; alter index RHN_UG_ORG_ID_GTYPE_IDX noparallel; excution plan looked nearly equal to 9i plan and the page loaded in a second. There are 20 more indexes created with parallel degree != 1. Although I was not able to find any other 'parallel suffering' queries (well it highly depends on database content and statistics so others can find some) IMHO we can alter all indexes to noparallel to be on safe side.
Fixed commit 101b2fb8d53d2c1f2dbeadd2e0fa6c3a288cb970 Automatic commit of package [spacewalk-schema] release [0.5.13-1]. commit 33086e60ece01f1eb0a0c45fd578816413fffbc5 489319 - altered web_user_site_info's indexes to noparallel commit ed1b2f50813fc694eb2aa737fe90e7239ba5cb63 489319 - altered web_contact's indexes to noparallel commit 8bec63a407853723cbd378c1ebb56e991c7040d8 489319 - altered rhnUserGroupMembers's indexes to noparallel commit 1b2029e0a0f6bde21f6066c156ea29d327666a91 489319 - altered rhnUserGroup's indexes to noparallel commit bf2563b9ede6fe4a697fec20ea37f560dfc21b6d 489319 - altered rhnServerPackage's indexes to noparallel commit b5c1ff33bb3dd75b11e24bb6c7e3b03302e63083 489319 - altered rhnServerNeededCache's indexes to noparallel commit 118ecc237ae44d25d0b477e4a8a034e574ad65ee 489319 - altered rhnServerGroupMembers's indexes to noparallel commit 3860ce2c2352dae3a3a851ae65749a35339a1ce8 489319 - altered rhnServerGroup's indexes to noparallel
Spacewalk 0.5 released.
Spacewalk 0.5 has been released for long time ago.