Those jobs also run at priority 20, the same as interactive jobs. One thing
I've done is to create a class named ODBC and set it at 40. Then have those
jobs run with that class. They run a bit slower, but they don't have
interactive priority either.
Paul Nelson
Office 512-392-2577
Cell 708-670-6978
nelsonp@xxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Brian Piotrowski
Sent: Friday, January 23, 2009 1:15 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Rein in QZDASOINIT
Happy Friday, All!
With the increased amount of web pages we are using on our systems, I am
noticing that the QZDASOINIT jobs appear to be chewing up more and more CPU
cycle times. That being said, I am looking into moving the jobs to their
own subsystem and changing the memory pool on them (as per a wiki document I
found). However, I'm wondering if there's anything else I can do to curb
the bad habits of these database queries?
One thing I think will make a difference is to move to a different strategy
other than "select X for lib.member" used in virtually all of the web pages
we host. However, I thought I'd hit the group up for some advice to see
what everyone else is doing.
If it makes any difference, the i5 is being used to house the data and we
have Windows Server 2003 Web edition hosting the web (ASP / ASPX) pages. It
is these pages that access the i5 through an ODBC string.
Thanks!
/b;
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Brian Piotrowski
Assistant Mgr. - I.T.
Simcoe Parts Service, Inc.
Ph: 705-435-7814 x343
Fx: 705-435-6746
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
http://www.simcoeparts.com
midrange.com
