Bug 489319 - Performance Problems with Configuration Management/Deployment
Performance Problems with Configuration Management/Deployment
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Michael Mráka
Red Hat Satellite QA List
Depends On:
Blocks: space05
  Show dependency treegraph
Reported: 2009-03-09 09:54 EDT by Michael Mráka
Modified: 2009-09-17 03:10 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-17 03:10:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Mráka 2009-03-09 09:54:14 EDT
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
<mode name="recent_modified_config_files_for_user"
  <query params="org_id, user_id, num">
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
        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 &lt;= :num

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Michael Mráka 2009-03-09 09:55:13 EDT
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

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.
Comment 2 Michael Mráka 2009-03-09 11:32:19 EDT
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
Comment 3 Jesus M. Rodriguez 2009-04-14 10:13:24 EDT
Spacewalk 0.5 released.
Comment 4 Miroslav Suchý 2009-09-17 03:10:54 EDT
Spacewalk 0.5 has been released for long time ago.

Note You need to log in before you can comment on or make changes to this bug.