Description

A job executing on a large number of nodes at the same time will cause excessive concurrency to other systems on which the job itself depends, requiring a way to control the concurrency of the job.

Design

• Job object to add concurrency attributes
• The server generates a token counter according to the value of concurrency when the job can be triggered
• When an agent is ready to perform a job try to get the token, if successful do it, else to wait for a cycle of retry

verison:0.2.3
log:

Nov 27 15:06:01 [27156]: (/home/harrison/Dropbox/project/go_path/src/github.com/HZ89/djob/store/store.go:746)
Nov 27 15:06:01 [27156]: [2017-11-27 15:06:01]  [10.45ms]  SELECT * FROM `executions`  WHERE `executions`.`name` = 'test1' AND `executions`.`region` = 'idc' AND `executions`.`group` = '0' AND `executions`.`run_node_name` = '' AND ((`name` = 'test1') AND (`region` = 'idc')) ORDER BY `executions`.`name` ASC LIMIT 1

When insert executions into databases, it will execution this sql, may be AND ((name = 'test1') AND (region = 'idc')) is superfluous

When a job needs to be executed on 97 agents, the CPU utilization of the job scheduling node can reach more than 70% (2.40GHz intel core2 duo cpu). The CPU utilization needs to be reduced below 40%

• A API, upload file to the server node
• Select the server that receives the file by tag matching
• Transfer files via BT

As agnet will perform an RPC call each time to run the job to obtain the job information, which led to the database periodically concurrent spikes.

• When query, query from cache first. if hit used it, if not query from database and set cache
• When update, update cache then update database
• When delete, delete cache and database

GNORM maybe better than GORM

Tags can only be read from the configuration file is not flexible. Tags can set by APIs, and store the tag to somewhere