# Process runs slower as a scheduled task than it does interactively

I have a scheduled task which is very CPU- and IO-intensive, and takes about four hours to run (building source code, if you're curious). The task is a Powershell script which spawns various sub-processes to do its work. When I run the same process interactively from a Powershell prompt, as the same user account, it runs in about two and a half hours. The task is running on Windows Server 2008 R2.

What I want to know is why it takes so much longer to run as a scheduled task - more than an hour longer. One thing I noticed is that the task scheduler runs at Below-Normal priority, so when my task starts, it inherits the same lowered priority. However, I've updated the script to set the Powershell process priority back to Normal, and it still takes just as long.

Anybody have an idea what could be different between the two scenarios? I've ruled out differences in processor and IO load - this task is the only thing the system is used for, so there's nothing else running that could be competing for resources.

-
Any updates? I'm very curious to see what you can find. –  mfinni Jun 18 '10 at 19:20
I did find what I think was the cause; see my answer below. –  Charlie Jun 21 '10 at 1:09

It appears that there is more than just "regular" process priority at work here. As I noted in the question, the task scheduler by default runs your task at lower than normal priority. This question on StackOverflow describes how to fix any task to run at Normal priority, but the fix still leaves one thing slightly different: memory priority. Memory priority was a new feature for Windows Vista, and is described in this Technet article. You can see memory priority using Process Explorer, which is a must-have tool for any administrator or programmer.

Anyway, even with the scheduled task priority fix, the memory priority of your task is set to 4, which is one notch below the normal setting of 5. When I manually boosted the memory priority of my task up to 5, the performance was on par with running the process interactively.

For info on boosting the priority, see my answer to a related StackOverflow question about IO priority; setting memory priority is done similarly, via NtSetInformationProcess, with PROCESS_INFORMATION_CLASS set to ProcessMemoryPriority (the value of this is 39 or 0x27). I might make a free utility that can be used to set this, if others need it and don't have access to programmer tools.

EDIT: I've gone ahead and written a free utility for querying and setting the memory priority of a task, available here. The download contains both source code and a compiled binary.

-
Glad you found it, thanks for sharing. –  MadBoy Jul 17 '10 at 17:38

The issue is that your process is starting with a low I/O priority. The easiest way to verify this is with process explorer from sysinternals. If you look at the properties of any of the processes that were spawned from this scheduled task, you will see that it has an I/O priority of low.

Here is the solution to this issue:

2. Right click on the task and "export" it
3. Edit the task.xml file that you just exported
4. You will find a line similar to <Priority>7</Priority>
5. Change the value to a normal priority (between 4-6). A table of the potential values are here
7. In the task scheduler, in the actions area, import the task from the XML file

Unfortunately there is no way to modify the initial priority of scheduled tasks from the GUI.

-
Thanks for the suggestion. Regular process priority and IO priority are definitely part of it, and the other part is memory priority. See the accepted answer for more info. –  Charlie Apr 15 '11 at 18:22

Maybe scheduled tasks run at a lower priority by default.

Use prio to force higher priority.

-
You're right that they run at lower priority, but as I mentioned, I've already accounted for that. Unless there's some priority other than process priority that I don't know about. –  Charlie Jun 16 '10 at 18:31

If you set it to run as a scheduled task as User X, and then login as User X before it's supposed to run, it should open a window in your session when it runs, it'll be running in your session.

If you do this, does it take the longer, or shorter, period of time? I don't know what this will mean, but it may be a useful differentiator. Could there be some network access that the user account has when logged in, but not when running as a scheduled task, that needs to timeout and fail? Is the behavior different if you create a new user account and have it run as a scheduled task under that account?

Another idea: When running it as a scheduled task - now that you've fixed the priority on your script do the sub-processes all run as Normal, or Below-Normal?

-
The subprocesses definitely run as Normal, as verified by procexp/taskman. I think the network thing isn't it, because it doesn't do any substantive network access, but I'll double-check that. The idea about running the task as interactive is interesting too, I'll give it a try. –  Charlie Jun 16 '10 at 18:52
The process itself doesn't have to do any network access that you know of for this to be a problem. Read this post from Sysinternals and see how something seemingly unrelated can cause hangs/slowness. blogs.technet.com/b/markrussinovich/archive/2005/08/28/… –  mfinni Jun 16 '10 at 19:24

at first - you can use more than normal priority (High for example)

at second - you have to understand, than foreground session takes some resources, mainly hard disk IO and memory so scheduled task gets less. for clear benchmark you have to logoff while you powershell script running

and also you can try add more memory / use ramdrive / split work on several hard disk to speed up processes

-
Thanks for the ideas. The machine has plenty of memory and IO capacity, the problem is just that things run slower as scheduled tasks than they do interactively. When the scheduled task is running, there is usually no interactive logon session, so I think that's not the issue either. –  Charlie Jun 21 '10 at 0:57