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. 正常启动系统即可恢复；

1. 缩小分区之前，应该先缩小文件系统；
2. 扩大分区之后，再后扩大文件系统；

看现在的情况，应该是操作系统根分区坏了，修复好的可能性很小，也非常的麻烦；
但是 /home 分区是没有问题，这部分数据不会丢失；

可以 livecd 进去后，重装系统，再把 /home 分区挂载上就可以了。

楼主多大啦，最近也想在西安买房，本来首付无压力，老婆想着 100+平。。。所以一直拖着没买

gzip 有一个 --rsyncable 选项，专门为 rsync 调优的，你可以试试，看下实际效果。

return 状态可以改成 444。