Here is an EXPLAIN prior to an ANALYZE (sorry for the lengthiness): spaceschema=# explain SELECT CP.package_id, CP.name_id, CP.evr_id, CP.package_arch_id FROM rhnPackageName PN inner join rhnChannelNewestPackage CP on CP.name_id = PN.id inner join rhnChannel C on C.id = Cp.channel_id inner join rhnPackage P on P.id = CP.package_id inner join rhnPackageEvr EVR on P.evr_id = EVR.id WHERE ( C.id = 1 or C.parent_channel = 2) AND PN.name = 'httpd' AND C.label not like '%beta%' order by EVR.evr DESC; QUERY PLAN --------------------------------------------------------------------------- ----------------------------------------------------- Sort (cost=627029.51..627029.52 rows=1 width=70) Sort Key: evr.evr -> Nested Loop (cost=113975.12..627029.50 rows=1 width=70) -> Nested Loop (cost=113975.12..627029.19 rows=1 width=38) -> Hash Join (cost=113975.12..627028.89 rows=1 width=30) Hash Cond: (cp.name_id = pn.id) -> Nested Loop (cost=113966.83..626995.91 rows=6584 width=30) -> Bitmap Heap Scan on rhnchannel c (cost=8.52..12.53 rows=1 width=7) Recheck Cond: ((id = 1::numeric) OR (parent_channel = 2::numeric)) Filter: ((label)::text !~~ '%beta%'::text) -> BitmapOr (cost=8.52..8.52 rows=1 width=0) -> Bitmap Index Scan on rhn_channel_id_pk (cost=0.00..4.26 rows=1 width=0) Index Cond: (id = 1::numeric) -> Bitmap Index Scan on rhn_channel_parent_id_idx (cost=0.00..4.26 rows=1 width=0) Index Cond: (parent_channel = 2::numeric) -> Bitmap Heap Scan on rhnchannelnewestpackage cp (cost=113958.32..616242.98 rows=859232 width=37) Recheck Cond: (cp.channel_id = c.id) -> Bitmap Index Scan on rhn_cnp_cid_nid_uq (cost=0.00..113743.51 rows=859232 width=0) Index Cond: (cp.channel_id = c.id) -> Hash (cost=8.27..8.27 rows=1 width=7) -> Index Scan using rhn_pn_name_uq on rhnpackagename pn (cost=0.00..8.27 rows=1 width=7) Index Cond: ((name)::text = 'httpd'::text) -> Index Scan using rhn_package_id_pk on rhnpackage p (cost=0.00..0.28 rows=1 width=16) Index Cond: (p.id = cp.package_id) -> Index Scan using rhn_pe_id_pk on rhnpackageevr evr (cost=0.00..0.30 rows=1 width=48) Index Cond: (evr.id = p.evr_id) (26 rows)
I then ran an ANALYZE on rhnPackageName, rhnChannelNewestPackage, rhnChannel, and rhnPackageEvr After, I get the following from the same EXPLAIN: Sort (cost=593711.04..593711.04 rows=1 width=70) Sort Key: evr.evr -> Nested Loop (cost=75858.49..593711.03 rows=1 width=70) -> Nested Loop (cost=75858.49..593710.72 rows=1 width=38) -> Hash Join (cost=75858.49..593710.42 rows=1 width=30) Hash Cond: (cp.name_id = pn.id) -> Nested Loop (cost=75850.21..593680.13 rows=5867 width=30) -> Bitmap Heap Scan on rhnchannel c (cost=8.52..12.53 rows=1 width=7) Recheck Cond: ((id = 1::numeric) OR (parent_channel = 2::numeric)) Filter: ((label)::text !~~ '%beta%'::text) -> BitmapOr (cost=8.52..8.52 rows=1 width=0) -> Bitmap Index Scan on rhn_channel_id_pk (cost=0.00..4.26 rows=1 width=0) Index Cond: (id = 1::numeric) -> Bitmap Index Scan on rhn_channel_parent_id_idx (cost=0.00..4.26 rows=1 width=0) Index Cond: (parent_channel = 2::numeric) -> Bitmap Heap Scan on rhnchannelnewestpackage cp (cost=75841.69..586728.21 rows=555151 width=37) Recheck Cond: (cp.channel_id = c.id) -> Bitmap Index Scan on rhn_cnp_cid_nid_uq (cost=0.00..75702.90 rows=555151 width=0) Index Cond: (cp.channel_id = c.id) -> Hash (cost=8.27..8.27 rows=1 width=7) -> Index Scan using rhn_pn_name_uq on rhnpackagename pn (cost=0.00..8.27 rows=1 width=7) Index Cond: ((name)::text = 'httpd'::text) -> Index Scan using rhn_package_id_pk on rhnpackage p (cost=0.00..0.28 rows=1 width=16) Index Cond: (p.id = cp.package_id) -> Index Scan using rhn_pe_id_pk on rhnpackageevr evr (cost=0.00..0.30 rows=1 width=48) Index Cond: (evr.id = p.evr_id) I honestly don't know what any of this means exactly, but I modified a newly-created kickstart profile and it was relatively speedy (under a minute). The others are still taking a couple of minutes to update. The new kickstart I created is different in that it is the skeleton profile that is generated when you create a new profile. It has no scripts, software selection is set to @Base, and the advanced options are mostly all unchecked. On 2012-02-28 8:16 AM, "Wojtak, Greg (Superfly)" <gregwoj...@quickenloans.com> wrote: >I'll look at this today as well Jan. It appears that 300 seconds timeout >in httpd makes it so it doesn't time out in all cases I've tried so far, >so at least I have a workaround for now. > >Thanks! > >Greg > >On 2012-02-28 7:52 AM, "Jan Pazdziora" <jpazdzi...@redhat.com> wrote: > >>On Fri, Feb 17, 2012 at 02:06:56PM +0000, Wojtak, Greg (Superfly) wrote: >>> Hi there, >>> >>> Spacewalk 1.6 >>> Postgres >>> Cent 6.2 (64-bit) >>> >>> Has anyone else run into an issue where, when updating a kickstart >>>profile (or cloning, or doing anything with it really) that you >>>consistently time out with a 500 error after the request times out? >>> >>> What I'm seeing looks to be nothing more than the query (queries?) >>>taking too long to run. I can see the queries while I'm waiting for a >>>response after I hit the "Update Profile" button. Eventually, when the >>>request times out and the query finally finishes and I browse back into >>>Spacewalk, I get the message at the top of the screen that the profile >>>has been updated successfully (and indeed it appears it has been). >>> >>> I've increased the HTTP timeout to 300 seconds (from 120) to try and >>>work around this, but should it really take five minutes to update a >>>profile? >>> >>> The one query I was able to capture during this was: >>> SELECT CP.package_id, CP.name_id, CP.evr_id, CP.package_arch_id FROM >>>rhnPackageName PN inner join rhnChannelNewestPackage CP on CP.name_id = >>>PN.id inner join rhnChannel C on C.id = Cp.channel_id inner join >>>rhnPackage P on P.id = CP.package_id inner join rhnPackageEvr EVR on >>>P.evr_id = EVR.id WHERE ( C.id = $1 or C.parent_channel = $2) AND >>>PN.name = $3 AND C.label not like '%beta%' order by EVR.evr DESC >>> >>> (sorry for the bad formatting) >>> >>> I'm not sure what the $1, $2, and $3 are (I presume this is calling >>>some sort of a procedure and those are arguments). >>> >> >>Those are bind parameters. You can replace them with some reasonable >>values. >> >>Please analyze your tables and run explain plan to see what is >>happening. >> >>I assume your cobbler is running and is reachable just fine. >> >>Anything of interest in /var/log/tomcat6/catalina.out? >> >>-- >>Jan Pazdziora >>Principal Software Engineer, Satellite Engineering, Red Hat >> >>_______________________________________________ >>Spacewalk-list mailing list >>Spacewalk-list@redhat.com >>https://www.redhat.com/mailman/listinfo/spacewalk-list > > >_______________________________________________ >Spacewalk-list mailing list >Spacewalk-list@redhat.com >https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list