服务进程集中管理动态分配 - noradle/noradle-dispatcher GitHub Wiki

【进程配置】 默认情况下,根据可用于执行 psp.web 请求的 job process 的 cpu 数来计算初始的 process 数。 然后对每个 nodeJS server 平均分配进程数。 然后 p_mon 会定期测算各个 nodeJS 请求的总处理时长和个数,对处理量大的 nodeJS 自动多分配进程资源。 测试统计周期如果过长,那么对瞬间的突发情况可能不能很少的分配进程资源。 如果测试统计周期过短,那么会造成 p_pmon 进行进程服务对象调整的频度过大。 一般来讲,各个 job process 通过 pipe 将每次请求的时长分配报告给 k_pmon k_pmon 进行累加统计,然后在每次唤醒时,重新调整各个 nodeJS 的服务对象。

dispatcher如何通知p_mon自己的队列长度?

每当向队列排队时,说明当前的OSP已经不够用了, 当有新可用的OSP时,马上先通知pmon然后在发送正常请求。 这样,队列长度可以最及时的通知。 并且,通知内容包括 当前slot数,当前排队数。 如当前 slot=8,排队=3,则应该slot数指标调整到13,但是不能超过最大限额。

pmon如何接受

pmon 从接收 alert 改为接收 pipe(name='NORADLE-PMON')停止。 OSP 接收控制帧 (cfgId,cur_slot,queue)将其pipe给pmon, pmon 更新 pv name-value. pmon 按照 pv.quota(cfgId)来增加和减少进程数

pmon如何反应

只要没到达最大 OSP限额,就按照当前排队数增加OSP job。 一开始 pv.quota(cfgId) 就是cfg.min_servers, 一旦受到 ask_osp 请求后,就增加。 然后当从大到小看空闲的 slot 有多少,再准备减少 pv.quota(cfgId) 空闲1s就算空闲。

dispatcher 在队列满的时候,首先要发送队列长度,通知 pmon 动态调整进程数。 【实施后可能存在的问题】

  1. 如果在前台运行 adjust / run 可能会出现错误,应该不会,因为实际的服务进程还是后台 job
  2. pv.cur_cfg_id 可能丢失。其实不可能,因为 pv 包不依赖于任何其他包,因此永远不会失效从而丢失掉状态

应该能够清理不用的OSP