11.27第一大题:
# 1. 进程等待接收信息过程浪费资源?
# 2. 动态调控Queue中任务数量?
# 3. 多进程内存泄漏定位及解决?
1.
当子进程在等待时间较长的时候, 在不杀死子进程的情况下, 为了节省资源, 可以更改子进程状态(应为睡眠状态或追踪状态) 以便节省资源. 父进程固定时间段查询子进程的信息接受状态(类似于时间片轮转),当发现子进程有信息变动的时候, 重新改变进程状态, 使其重新活跃.
2.
续接1.
为进程1设置等待超时, 当阻塞时间到上限之后, 父进程改变其状态为不活跃并将之从任务队列中移出. 由父进程管理这些已经休眠子进程的ID和信息状态, 当发现接受状态出现变化, 根据对应ID重新唤醒子进程,并且将子进程重新添加到任务队列中.
3.
在已经确认内存泄漏的情况.
定位:
使用pympler,memory_profiler等工具
个人认为不管是多进程还是单进程对于内存泄漏的定位步骤是相同的, 有所差别的是因为子进程处理的任务不同, 所以内存泄漏程度也有所差别.在定位内存泄漏点的时候, 倾向于优先排查占用内存较高的子程序调用频次较高的代码块.
然后进行具体的定位流程.
定位代码块 ===> 定位代码段 ===> 定位调用链 ===> 定位泄漏点
逐步查询到具体在调用哪段函数的时候产生内存占用过高的情况.
如果是自己的代码就追踪到泄漏点, 思考泄漏原因, 优化代码.
如果外部调用, 则搜索是否有已有泄漏事件, 查看解决方法或考虑更换调用.
###
关于1,2的子程序休眠问题.
对底层方面的知识不是很了解, Python的功能模块了解不够深刻。
@按道理来说是很常见的且已经实现的功能， 但是却找不到包或者工具。
## TODO ：技术难点在于，如何实现 子进程休眠之后 父进程能够查看信息状态。（或者，父进程统一接收信息， 对应用户对应进程号？）
###
12.4补
在进程处理方面.系统级的确走在所有软件开发的前端.
最初的时候, 系统使用的事件调用方式是多线程阻塞,select, 但性能低下.
之后发展出Unix的Kqueue,和Linux的eqoll.
这是事件驱动的系统调用, 同级概念还有 消息驱动, 中断驱动, 数据驱动..轮询应属于消息驱动
不管是事件驱动还是消息驱动都可以解决之上的进程问题.
关于事件驱动框架:
在Python中, 事件驱动框架可以使用Twised.
Java中相对应的是Netty(JavaNIO).