众所周知，最简单的 daemon 运行的方式就是在命令后加 &，再配合将输出重定向到一个 log 文件，这样就可以实现即以 daemon 跑，也能随时查看 output 和error 相关的信息。比如
不过最近几天，我发现每次到公司查看昨晚上的任务情况，都发现进程在我下班后不久就被干掉，output.log 中也没有任何的错误信息。实在是相当诡异。
google 了一番，没什么有建设性的意见，一开始以为是不是 &方式的 daemon 天生有缺陷，还研究半天怎么用 python fork 出 daemon process。但越试越感觉，可能这个不是主要原因，在玩了几次 python-daemon 之后，还是决定回到源头尝试解决。
其中有一个回答提到了可能因为脚本占用内存过大导致被系统 kill 掉(OOM)，这个时候脚本本身是不会输出错误的。于是就去 /var/log/system.log 里边儿翻 OOM，结果 OOM 没翻到到翻到了一个 "Received SIGRTMIN+24 from PID 27041 (kill)." , 继续 google 了一下发现。这是系统进程 systemd 发出的信号，（systemd 可以理解为调度 daemon process 的进程）。
为什么 systemd 没事儿会来干我的脚本呢？ 因为 systemd 默认会在一个 user detach 的时候，干掉这个 user 启动的所有 process，不管你是不是 daemon。所以当我的本地电脑休眠超过一定时间时，远程的机器自动 logout user, 然后触发 systemd 干掉了我的脚本，即便我的脚本有 &加持。
知道问题的原因那就简单了，简单 google 一下就能知道, 我们只需要修改 /etc/systemd/logind.conf 中，将 KillUserProcesses=no 反 comment 即可。代表让 systemd 不要干掉 user process。
params就是(5, 5)
(5,) * 2 ,就是2个5的元组,乘号可以理解成相加。"*" * 30就是30个“*"的字符串
*params作为参数，前面的*号就是把params元组分解成元素的意思，这样就分开成为2个参数了。实际上传递给了x，y
于是就执行了power（5，5）
如今研究人工智能，跑深度学习算法，显卡/GPU绝对是第一大门槛，所以不管您是1080Ti还是V100，如果不能发挥出GPU的最大能力，那它可能就是不是显卡而是块普通的砖头了吧。显卡爆炸
显卡爆炸和内存的使用紧密相连，特别是在代码中对某些变量的不当使用，很有可能内存泄露，从而慢慢得导致显卡OOM(out of memory)。一般来说，计算模型时显存主要是模型参数 + 计算产生的中间变量
