dtm_master_running_flow
2016-08-03 15:29:56 0 举报`dtm_master_running_flow` 是一个用于监控和管理分布式事务管理器（DTM）运行状态的流程。该流程主要关注DTM的主节点，以确保其正常运行并处理事务请求。在流程中，首先检查DTM主节点是否在线，然后收集其性能指标和资源使用情况，以便进行实时监控和故障诊断。此外，流程还会定期检查DTM主节点上的事务队列，确保没有长时间阻塞的事务。如果发现潜在的问题，流程会采取相应的措施，如调整资源分配、优化配置参数或重启DTM主节点。总之，`dtm_master_running_flow` 旨在确保分布式事务管理器在高负载和复杂环境下的稳定运行，从而保障整个系统的可靠性和性能。
作者其他创作
大纲/内容
dtm_unlock_mutexes(epid);
init_accept_manager
channel的另一端因为child死掉而closeonexec但是我们这边的channel因为没有exec而没有close不需要显示close吗？会浪费fd，socketpair的系统资源也不会释放
初始化signal handlers
创建g_srv-control_socket
for 0 ~ func_process[i] LOCKGUARD_PROCESSfork FUNC，修改共享内存来通知controller新增一个CONTROL_PROCESS角色与CONTROL_PROCESS通信的socket记为controller_fd
此时新老子进程均在proc_info里面均与master有channel均在accept队列里面
Y
这里不关闭channeldel accept和设置shutdown=0wait到了再做这些
创建g_srv-service_socket
for 0 ~ g_srv-config-basic_config.max_threadsfork WORKER，修改共享内存来通知controlleradd_accept_worker
g_gracefullly_child_start = 1
while (g_gracefully_shutdown == 0)
if(proc_info[i].graceful_shutdown == 1)如果是被master显式kill的
不是worker也执行这个，好吗？
将proc_info中现有所有graceful_shutdown=0的子进程均kill SIGUSR1，均标记为graceful_shutdown=1
初始化proc_info数组为该数组每个元素预创建socket pair（MAX_NUM_OF_PROCESS/200）
更新conf_modify_time重新load_config_from_file
return
遍历proc_info当前所有子进程如果仍有alive且shutdown=0的，则什么都不做，否则：
g_gracefullly_child_shutdown = 1
sleep 100ms
reload_dtm
N
非阻塞read controller_fd获取需master执行的控制指令
reset proc_info[i]不会重启，不会close socket pair
如果有指令
子进程收到SIGUSR1就g_gracefully_shutdown=1
accept_worker_manager由master来均匀调度哪个worker来持有accept锁
创建g_srv
del_accept_worker(epid);
更新conf_modify_time读取config
g_gracefully_reload == 1
epid 0
将proc_info中现有所有子进程均标记为graceful_shutdown=1，包括worker和func
WIFSIGNALED(statloc)如果是被信号干掉的child，log一下继续
初始化shm
遍历proc_info，向所有子进程均发送kill SIGTERMprocess_type = -1process_num = 0关闭所有socket pair
final reap
每循环read一次所以暂停、重启fork都是以循环为最小时间单位的
读到控制指令后，设置全局变量如g_gracefully_loadconf、g_gracefullly_child_shutdown等新增变量g_no_forking，默认为0，只可被controller遥控改变
遍历proc_info寻找是否dead child是哪个子进程
将proc_info中现有所有子进程均kill SIGUSR1，包括worker和funcprocess_type = -1process_num = 0
现在的signal handler没有区分角色难道每种角色收到同样信号的处理都一样吗？难道不应该是某些信号只能给worker发不能给master发以免无操作吗？
end of while
1 == g_gracefully_loadconf
0 条评论
下一页
