Phantom Jobs on Windows

Curt,

If you use Windows Task Manager to identify a specific PHANTOM process and  right-click -> Set priority you will see the current job poriority. The settings are:

• Realtime
• High
• Above Normal
• Normal
• Below Normal
• Low

Compare the process priority with that of a standard non-PHANTOM process. From the description it could be that PHANTOMs are started with a lower priority than that of interactive processes (which generally is a good thing). If this is the issue then please open a ticket through your usual support channel with Rocket, If you do NOT see a difference in priority I recommend checking the application logic.

It is also possible that you are experiencing a delay in initiating PHANTOMs, in which case please see this article:

•  How-to-bypass-a-phantom-startup-delay-in-UniData-for-unix-linux-platforms

An elevated priority is required to increase any process priority and this should not be done trivially - particularly for 'Realtime' - as this can - and will - hog a complete system to the detriment of all other processes. It is not an approach I would casually recommend,

Regards

JJ

-----------------------------
John Jenkins
Thame, Oxfordshire
------------------------------

Hi,

By default, when you create a ScheduledTask, his Priority level is set to 7 

win32/taskschd/tasksettings-priority

to define another priority you can :

• create the task via vbs ->  CreateObject("Schedule.Service") 
• create the task via ps1 ->  New-ScheduledTaskAction/New-ScheduledTaskTrigger/New-scheduledtaskSettingSet (set priority=4) then Register-ScheduledTask 

or 

1/ create the task with gui

2/export the task as xml (right click on task name)

3/edit the xml , set priority=4

4/re-import the task 

I hope this help.

What time of day are you setting the phantom to run

We're setting it to run at 5pm. 

Since it's an archive job, why not set it to start up at Midnight?

Or your most quiescent time?

We were trying to take advantage of quiet time. The job runs in 7.5 hours on a telnet session and 17 hours as a phantom. Starting the job later has no effect other than it completing later. It's a single thread job so it's not taxing on the server at all. 

Curt,

In terms of the process priority that is initially assigned to a udt process started from telnet or command prompt they are all assigned a value of 8 as reported by the sys internals tool process explorer. The tool also shows phantom processes started from the telnet session or the command prompt also both have a value of 8. The value defines the priority that the threads in these processes will all start at. The value of 8 is the default value.

There are several tools available in Windows to change this prioirty value, including START as already mentioned, you can also do this via powershell. To change the priority using these methods programmatically you will require elevated rights to do so.

As both the telnet session and phantom seem to have the same priority here when I checked on an 8.2.4 system, there must be another reason why the phantoms are running slower.

As a first check you load the process explorer tool from sysinternals, add the priority column to the output as see the priority assigned to each process. I would suggest looking at using the START command in some form to see if forcing the priority of the phantom process.

I have confirmed if you use START udt PHANTOM phantomname from the command prompt then the phantom process does start with a priority of 13. I have not done any further testing other than making sure it is started with a higher priority. I would strongly suggest doing a lot of testing of this on a test system before doing so as it may introduce 'race' conditions not previously encountered.

If you are using the Recoverable File System (RFS) then changing the priorites assigned by UniData to any of it's processes is very dangerous and should not be done without discussing with Rocket first.

So in summation if you are using the RFS do not change the priority values. If you are then do this first on a test system to ensure no unwanted race conditions are meet. With that all said given the telnet and phantom have the same thread prioirty I suspect the reason is deeper than a simple thread priority as to why it runs slower. If problems were encountered with the higher priority value then from a Rocket Support Standpoint then this would make for a very challenging support case. 

Regards,