Start Stop Jobserver Dynamically

[Dominik Bahl]

Dear schedulix group,

i have a complete running schedulix environment.
3 Jobserver for automatic jobs and 1 Jobserver for manual executions (testing the Job configuration).
Everything is perfect.

My question now is:
I need the Server for testing only during the day. So sometimes from 8AM to 2PM or from 7AM to 6PM.
It depends on the business department, if they need to execute Jobs.
Is there a possibility to check with schedulix before a job is running, if the Jobserver is running?

Our goal is to reduce the runtime and costs of the manual Jobserver, because we don't need him in the night.

Best solution would be, if a manual Job starts, the jobserver should start too.
If after 1 hour no Job is started, the jobserver should be switched off.

Has anyone ever encountered this task?

Best regards
Dominik Bahl

[Ronald Jeninga]

Hi Dominik,

unless your computer is extremely short on resources, there's not really a need to switch off a single jobserver.

In order to start up a jobserver you'll need something that can execute programs on the system.

This is a bit like a chicken-egg problem.

If your jobservers run on a system remote to the scheduling server, you could start a jobserver on the system that runs the scheduling server and let it start the remote jobserver via ssh.

If one of the "production" jobservers happens to run as root or as the user that runs the "manual" jobserver, you could start the "manual" jobserver using that production jobserver.

Yesterday I've restarted the jobservers on our production server.

If I do a "ps" now, the system shows:

[root@lion lib]# ps -ef | grep jobserver

ronald    37851      1  0 Jul29 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /home/ronald/log/DEFAULT.out -e /bin/java de.independit.scheduler.jobserver.JobServer /home/ronald/etc/DEFAULT.conf jobserver[someone]

ronald    37852  37851  0 Jul29 ?        00:02:04 /bin/java de.independit.scheduler.jobserver.JobServer /home/ronald/etc/DEFAULT.conf jobserver[someone]

root      37887      1  0 Jul29 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /root/log/DEFAULT.out -e /bin/java de.independit.scheduler.jobserver.JobServer /root/etc/DEFAULT.conf jobserver[someone]

root      37888  37887  0 Jul29 ?        00:01:58 /bin/java  de.independit.scheduler.jobserver.JobServer /root/etc/DEFAULT.conf jobserver[someone]

A "list sessions" shows the connect time of the two jobservers:

[SYSTEM@localhost:2506] SDMS> list sessions;

List of Sessions

THIS SESSIONID PORT START                         TYPE      USER                       UID  IP        TXID     IDLE STATE  TIMEOUT INFORMATION                          STATEMENT      WAIT

---- --------- ---- ----------------------------- --------- -------------------------- ---- --------- -------- ---- ------ ------- ------------------------------------ -------------- ----

          1001 2506 Mon Jul 29 15:55:29 CEST 2019 JOBSERVER GLOBAL.LION.RONALD.DEFAULT 1194 127.0.0.1 10234750    3 IDLE       300 jobserver[someone]                    

          1002 2506 Mon Jul 29 15:55:29 CEST 2019 JOBSERVER GLOBAL.LION.ROOT.DEFAULT   1029 127.0.0.1 10234747    4 IDLE       300 jobserver[someone]                      

(I've shortened the output of the ps command and the list sessions output a bit).

The jobservers were idle most of the time.

Now the cumulated CPU usage is about 2 minutes per jobserver. It is safe to assume that the CPU usage after 24h runtime won't exceed 4 minutes.

(That means a single core has been occupied for at most 4 minutes within 24h. That's a usage of 0.3%. Since the system has 14 cores, it's a system use of 0.3%/14 ≈ 0.02%. I think that's neglectable). 

On my development system the situation is comparable. The jobservers (the 3 example ones) run since 10 days and have a cumulated CPU usage of 20 minutes each.

Do you really want to invest all that effort for that little gain?

Best regards,

Ronald

PS. The picture would change if you were talking about hundreds of jobservers.

In that case I'd start a single jobserver as root that can start (and stop) the required jobservers on demand.

That would be possible in your situation too, but it would in fact increase the system usage instead of reducing it.

[Dieter Stubler]

Hi Dominik,

You asked: Is there a possibility to check with schedulix before a job is running, if the job server is running?

You can use the LIST SESSION command of the schedulix API:

list session

and check whether a line with USER = job server name for example 'GLOBAL.EXAMPLES.HOST_2.SERVER' exists showing its connected.

or the SHOW SCOPE command of the schedulix API like:

show scope GLOBAL.EXAMPLES.HOST_2.SERVER

and look for the IS_CONNECTED == true indicating the job server is connected
(Maybe also check for IS_SUSPENDED == false, IS_ENABLED == true and IS_TERMINATE == false).

Since a job server does not take much cpu or memory resources, a running job server should not be noticeable slowing down the machine it is running on.
So I think there is no need to spend a lot of effort to temporarily shut down down not used job servers because you will barle  notice any performance gain after the job server is shut down.

The job server is the instance on a machine executing jobs on behalf of the schedulix server.
So if it is not running, there is no way to execute something on the machine controlled by schedulix.
This includes starting a job server since there is no instance listening to the schedulix server able to do this.
If there would be, we would have a similar process as the job server itself.

So my recommendation is to just keep your your job servers up.

To avoid execution of test jobs causing load interfering with production jobs you can use jobs to temporarily suspend and resume a job servers using the api.

suspend GLOBAL.EXAMPLES.HOST_2.SERVER

resume GLOBAL.EXAMPLES.HOST_2.SERVER

Having the UDP notify port configured correctly you can use a fairy long NOPDELAY avoiding to much useless polling between the job server and the schedulix server.

Hope that helps

Dieter

[Dominik Bahl]

Hi Dieter,
Hi Ronald,

thank you for your explanations and information.

I have to process your information first.

Thank you very much

Best regards
Dominik