[Spacewalk-list] 500 ISE (Timeout) When Updating Kickstart Profile?
Wojtak, Greg (Superfly)
GregWojtak at quickenloans.com
Tue Feb 28 14:10:44 UTC 2012
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)"
<GregWojtak at 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" <jpazdziora at 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 at redhat.com
>>https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
>_______________________________________________
>Spacewalk-list mailing list
>Spacewalk-list at redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list
More information about the Spacewalk-list
mailing list