Limiting (server) CPU usage for an engine (OpenInsight 32-Bit) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>category:"OpenInsight 32-Bit" author:"Wilhelm Schmitt" author:"Donald Bakke" author:"The Sprezzatura Group" author:"[url=http://www.sprezzatura.com]The Sprezzatura Group[/url]" author:"Pat McNerthney"}}

[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]


==== Limiting (server) CPU usage for an engine (OpenInsight 32-Bit) ====
=== At 13 JAN 2005 08:23:27PM Wilhelm Schmitt wrote: ===
 
 
<QUOTE>
When a lot of users ask for reports and queries at the same time, the 4 processors on a Win2000 server use up 100% and hold up other requests temporarily.



We know how to direct queries and reports to a specific engine, but is it possible to limit the server's CPU usage for a specific engine?



Wilhelm
</QUOTE>
----

=== At 14 JAN 2005 12:08AM Donald Bakke wrote:  ===

<QUOTE>Wilhelm,



Not sure if this will help but have you tried setting the priority of the OENGINE.exe process (via Task Manager) to BelowNormal or Low?



dbakke@srpcs.com

[url=http://www.srpcs.com]SRP Computer Solutions, Inc.[/url]



[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 14 JAN 2005 03:33AM The Sprezzatura Group wrote:  ===

<QUOTE>You can also try to limit the tight processing loop by forcing the engine to give up a little control to Windows.



For a select or a list, what you can do is add in a symbolic dictionary something like




<code>


call yield()

@ans='


</code>




If you set this to 0 length, then you can include this in LIST and SELECT statements, for each record processed, the system will yield processing.





The Sprezzatura Group

[i]World Leaders in all things RevSoft[/i]

<img src=http://www.sprezzatura.com/zz.gif

</QUOTE>

----

=== At 14 JAN 2005 04:24AM The Sprezzatura Group wrote:  ===

<QUOTE>As another member of the collective pointed out, it's a tad early, and I was thinking of AREV, not OI with respect to yield.



Suppose theoretically you could do the same with the windows sleep API calls, but can't say I've tried it as fact.



The Sprezzatura Group

[i]World Leaders in all things RevSoft[/i]

<img src=http://www.sprezzatura.com/zz.gif

</QUOTE>

----

=== At 14 JAN 2005 04:26AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:  ===

<QUOTE>...and on a further note ... :)



If I recall correctly the yield() function is designed to work effectively against the Presentation Server when executing in event context.  From your post it sounds as though you are not operating in this context, so you might also try a Windows API Sleep() call in place of the yield()?



[url=http://www.sprezzatura.com]The Sprezzatura Group[/url]

[i]World Leaders in all things RevSoft[/i]

[img]http://www.sprezzatura.com/zz.gif[/img]

</QUOTE>

----

=== At 14 JAN 2005 04:27AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:  ===

<QUOTE>Snap!  Ah, the joys of working in different cities.... :)

</QUOTE>

----

=== At 17 JAN 2005 01:53PM Wilhelm Schmitt wrote:  ===

<QUOTE>Don,

thanks for your suggestion.

Setting the priority of OENGINE.exe low would affect all OENGINEs, giving all other processes higher priority.

We would like to be able to limit a single engine call to use a max. n% of CPU.

Wilhelm

</QUOTE>

----

=== At 17 JAN 2005 02:01PM Wilhelm Schmitt wrote:  ===

<QUOTE>Sprezz, 



we put several yield()s in loops, but our problem seems to be located when starting queries, i.e. within the SELECT. We have to wait, until the resulting list is returned.

Is it possible to hook into the select process itself?



We also noted, that on large indexes, if we query through 2 indexed fields at the same time it is much slower than querying on 1 indexed field an another non-indexed field.

Wilhelm

</QUOTE>

----

=== At 17 JAN 2005 04:20PM Pat McNerthney wrote:  ===

<QUOTE>You could try adjusting the thread priority using [url=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setthreadpriority.asp"SetThreadPriority[/url].



Pat

</QUOTE>

----

=== At 17 JAN 2005 04:23PM Pat McNerthney wrote:  ===

<QUOTE>Well that didn't work so well.



I meant to link to the SetThreadPriority Win32 API documentation located here:  http://msdn.microsoft.com/library/en-us/dllproc/base/setthreadpriority.asp



Pat

</QUOTE>

----

=== At 18 JAN 2005 04:02AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:  ===

<QUOTE>Wilhelm,



[i]...SELECT. We have to wait, until the resulting list is returned.

Is it possible to hook into the select process itself?[/i]



Sort of :)  You can create a symbolic dictionary item that includes the yield() statement and returns a simple value like @ans=1.  This can then be included in your select statement and it will be executed with every iteration.  You can either do this for a specific table or add it to SYSDICT so it is globally available.



[url=http://www.sprezzatura.com]The Sprezzatura Group[/url]

[i]World Leaders in all things RevSoft[/i]

[img]http://www.sprezzatura.com/zz.gif[/img]



</QUOTE>

----

=== At 21 JAN 2005 09:27AM Wilhelm Schmitt wrote:  ===

<QUOTE>Sprezz,

we connected some SLEEPs to a MFS and got an acceptable response for reporting, especially in READ and READO, counting the ocurrences within the same engine during a certain time span.

The option for SELECTs with a symbolic does not seem very appealing, especially for large data files.

Thanks



-Wilhelm-

</QUOTE>

----

=== At 21 JAN 2005 09:29AM Wilhelm Schmitt wrote:  ===

<QUOTE>Pat,

thanks for the link.

We are going to experiment a little bit with the option.

(Not yet ready for putting it into the production system.)



Wilhelm

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=85C3666B47B6EDFB85256F890007A3F5|View this thread on the Works forum...]]