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.

Solution 1:

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.

Solution 2:

The issue is that your process is starting with a low I/O priority and a low memory 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 and memory priority of 2.

Here is the solution to this issue:

1. Create the task
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: TaskSettings.Priority property
   • A value of 4 will have the same I/O and memory priority as an interactive process. Values of 5 and 6 will have lower memory priority
6. In the task scheduler, delete the task you initially created
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.

Solution 3:

Here's a powershell snippet for setting the priority (works in a remote powershell session!):

$taskName = "MyTask" ;`
$currentTask = Get-ScheduledTask -TaskName $taskName ;`
$settings = $currentTask.Settings ;`
$settings.Priority = 4 ;`
Set-ScheduledTask -TaskName $taskName -TaskPath $currentTask.TaskPath -Settings $settings

Solution 4:

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?