我猜测是短时间内大量进程 /线程的创建导致的，推荐使用 ganglia 或者 prometheus 监控来看下；

@7654 小米售后确实给力，从保修到进家检查，不到两个小时，这个还是要赞一个的!

我们之前也遇到了这个问题，版本 3.6。

当时的解决方式是使用 rocksdb 引擎的 mongo 3.4 版本，根据业务模型将数据从老的集群导出，并导入到新的集群，切换 mongos 配置到新集群，写入没有问题后将中间切换丢的数据再补上。

之所以使用 rocksdb 引擎的 mongo 3.4 版本，因为这个引擎对 SSD 支持友好，并能够在删除数据后释放逐步物理空间。

哈哈，很明显，VPS 的出口带宽占满了，导致 SSH 链接断掉，进而传输失败啊！

将 SSH 的保活机制调整下就行。

sysctl 是控制内核参数的，和下面的都没有关系。


systemd 是用来管理系统服务的（还有硬盘挂载、定时任务、会话管理等其他功能）
pam 是用来控制用户会话的，包括用户的资源限制，也就是这里的 ulimit 的，还有变量控制、密码认证等

systemd 并不会用到 pam 的 env、limits 等模块，所以平时用来控制资源的 /etc/security/limits.conf，控制环境变量的 /etc/environment 等文件，对于 systemd 的服务并不起作用

不过 systemd 会通过 pam_systemd.so 模块将 PAM 中的会话注册到 user.slice 中并进行相应的操作，
还有就是将会话中的进程放置到当前会话的 CGroup 控制组中，实现会话资源的统一管理

500 多 GB 还行吧，之前我们在 UCloud 云主机备份过三个复制组、共 2TB 的数据。

不过我们是根据业务层面的数据插入时间来检索备份的，小时级别共 3 个月的数据，大概一天就备份完了，可以作为参考。

这实际上属于 CI/CD 中的 CD - 持续部署。

jenkisn 本身是为少量工程的 CI （持续集成）设计的，大量工程的 CI 以及 CD 用它并不合适。

根据业务特性，我们自己实现了一套 CD，并集成到了运维平台中。

赞，在之前的公司用 shell 写过这样的脚本，不过当时是证书快到期了，业务分布在不同的云机器上；

所以就根据阿里云解析 API 获取所有域名的 A 解析，访问对应 IP 的所有活动端口，进而获取分析证书信息，统一替换。

不需要 commit=False，在 save() 之前，你可以通过 form.instance 来获取 /修改表单的数据，处理完逻辑之后再 save() 即可。

具体可以参阅： https://docs.djangoproject.com/en/1.11/topics/forms/modelforms/#s-overriding-clean-on-a-modelformset

@lzxz1234 完全符合我的需求，赞！

排除法：
1. 测试 nginx 服务本身，放一个静态页面 index.html 压测，得到 nginx 和外网带宽的最大 QPS ；
2. 开启 FPM 服务进行压测，此时的 QPS 肯定比 nginx 的低，看是否和现在的故障 QPS 一致；
3. 如果一致，那很明显是 FPM 本身有瓶颈了。

另外建议安装 atop，ganglia 等软件，实时查看服务器当前各项指标，加速找到问题原因。

为什么要重复造轮子？直接使用 sshpass 命令就行。

应该是被入侵了，执行下面的命令，看看哪些系统命令被修改了：
`for i in $(rpm -qa); do rpm -V $i |& grep bin;done`

@paouke

@banks0913 @moxiaonai
刚回西安 4 个月，最近打算买房，如果想买房后把北京的公积金提取出来，需要去北京公积金提取，还是在西安就行？

现在的 HR 说西安缴够 5 个月，就可以把北京的公积金转移到西安，到时就可以在西安全部提取吗？

@banks0913 请教下需要到北京去提取吗？

工作地点在哪里呢？

很简单：
1. 使用 LiveCD 进入系统，fsck 先修复 ext 文件系统；
2. 正常挂载文件系统，使用 find、ncdu 等工具，查找到底是哪些目录的文件把 inode 占用完；
3. 删除 /移走该目录，退出 LiveCD ；
4. 正常启动系统即可恢复；