Hi All
Thought I would share this one as its almost caused the failure of a very high value system upgrade project (Windows 2003/9.1D to Windows 2008/10.2B) at a client site. Luckily we found the solution a few days before go-live and all is on track now.
Apologies to those that already knew this, but hopefully it will save someone else a bit of time if they are pulling their hair out with unexplained and unpredictable batch and database performance.
There is a hidden 'Priority' setting in Windows Task Scheduler on 2008 R2 (X86 and X64). It should appear on the settings tab, but MS have neglected to display it. The task needs to be exported to XML and the file opened to see the tag. The Priority settings can be 0-10 with 0 meaning highest (Realtime) priority and 10 meaning lowest. Values 4-6 are 'Normal' priority and this is the equivalent of an interactive session e.g. client application sessions, command line sessions or queries run in Progress Editor or App Builder i.e. anything running on the user desktop.
The default Priority value for a new Scheduled Task is 7 (Below-Normal) and like I say this setting is hidden and unchangeable in the Task Scheduler UI. The task must be exported to XML, the value changed in the file and then imported back into Task Scheduler.
The net result for any tasks running with priority 7 is that Windows will arbitrarily decide to downgrade the CPU and disk i/o affinity for the task while it is running. This will happen even if the CPU is 99% idle. The affect can be seen in the Disk tab of System Resource Monitor. Normally this would just mean that a task ran slowly, but if that task is a .bat file running _progress or prowin32 connected in shared memory to a local database then the net result is catastrophic performance issues for all users and batches. Disk i/o for the database extent files will rocket to near 100% activity while bytes per second (and records per second in promon) will drop to almost nothing. Windows will upgrade and downgrade the affinity of the task while it is running making it look like the database has serious corruption or fragmentation issues.
We have spent countless hours investigating this from a database and application performance perspective before stumbling across a random post on another non-Progress forum similar to this one. Setting the Task priority to 4 (Normal) resolves this issue completely.
Hope this helps at least one person.
Regards
Andrew Bremner
Thought I would share this one as its almost caused the failure of a very high value system upgrade project (Windows 2003/9.1D to Windows 2008/10.2B) at a client site. Luckily we found the solution a few days before go-live and all is on track now.
Apologies to those that already knew this, but hopefully it will save someone else a bit of time if they are pulling their hair out with unexplained and unpredictable batch and database performance.
There is a hidden 'Priority' setting in Windows Task Scheduler on 2008 R2 (X86 and X64). It should appear on the settings tab, but MS have neglected to display it. The task needs to be exported to XML and the file opened to see the tag. The Priority settings can be 0-10 with 0 meaning highest (Realtime) priority and 10 meaning lowest. Values 4-6 are 'Normal' priority and this is the equivalent of an interactive session e.g. client application sessions, command line sessions or queries run in Progress Editor or App Builder i.e. anything running on the user desktop.
The default Priority value for a new Scheduled Task is 7 (Below-Normal) and like I say this setting is hidden and unchangeable in the Task Scheduler UI. The task must be exported to XML, the value changed in the file and then imported back into Task Scheduler.
The net result for any tasks running with priority 7 is that Windows will arbitrarily decide to downgrade the CPU and disk i/o affinity for the task while it is running. This will happen even if the CPU is 99% idle. The affect can be seen in the Disk tab of System Resource Monitor. Normally this would just mean that a task ran slowly, but if that task is a .bat file running _progress or prowin32 connected in shared memory to a local database then the net result is catastrophic performance issues for all users and batches. Disk i/o for the database extent files will rocket to near 100% activity while bytes per second (and records per second in promon) will drop to almost nothing. Windows will upgrade and downgrade the affinity of the task while it is running making it look like the database has serious corruption or fragmentation issues.
We have spent countless hours investigating this from a database and application performance perspective before stumbling across a random post on another non-Progress forum similar to this one. Setting the Task priority to 4 (Normal) resolves this issue completely.
Hope this helps at least one person.
Regards
Andrew Bremner
