Re: Optimizing..

A couple of clarifying questions: This limit of threads per CPU VP, is it a maximum limit of all queries, so that if the limit is hit, new queries are blocked, or is it a limit per query, so that only large queries are effected (big join/order/group by could use 30 threads but only gets 20)? This change in the number of threads per query appears to be influenced by what the PDQ is set to, so this would seem to be a problem only if PDQ is at 100, in which case no one else can run a DSS query. And if this is based on CPU VPs, would this include scan threads? Thanks, Paul David Kosenko wrote in message <352fd29d.107231508@nntp.news.netcom.net>... >"Mark D. Stock" <mdstock@informix.com> offerred: >+I have also heard of this method. But if you think about it >logically, >+one CPUVP per CPU should give you total CPU power. What is happening >+with more CPUVPs giving better performance, is that they are being >+switched too often. They are then being replaced with another >process, >+and with so many CPUVPs around, with any luck it is one of them. >+ >+I suggest this goes to process priority. You might try increasing the >+priority of your CPUVP processes. I think on HP this is best achieved >+manually, as opposed to setting NOAGE. > >Actually, the number of CPU VPs influence the number of threads >spawned for queries. On some platforms (HP for one) the number of >threads spawned for the "correct" number of cpuvps winds up being too >low for the capacity of the processors. Tuning more than physial >processors generates more threads, thus you get higher cpu >utilization. As whether this always translates into faster query >response is another matter: it might, but it might not. > > >-- >Dave Kosenko davek@summitdata.com >Director of Training Services (732) 469-4070 >Summit Data Group (an Informix Authorized Education Center)