不知不觉中,我的博客的mysql用的内存越来越多了,我的1核1G的主机有点儿内存不太够用了,一个偶尔的操作,mysqld被oom了,重启就报错,大概意思是:
1 |
InnoDB: mmap(137363456 bytes) failed; errno 12 |
因为我的机器只有1G内存,而且没有swap,mmap想map大于1g的文件,结果失败了;
比较大气的解决办法是: 加内存
比较小气的解决办法是: 加swap
DevOps
不知不觉中,我的博客的mysql用的内存越来越多了,我的1核1G的主机有点儿内存不太够用了,一个偶尔的操作,mysqld被oom了,重启就报错,大概意思是:
1 |
InnoDB: mmap(137363456 bytes) failed; errno 12 |
因为我的机器只有1G内存,而且没有swap,mmap想map大于1g的文件,结果失败了;
比较大气的解决办法是: 加内存
比较小气的解决办法是: 加swap
阿里云ECS:
1c1g: 45RMB/月
1c2g: 85RMB/月
原本想把1c1g换成1c2g的,看了下差价,还是算了吧,弄点儿swap充数吧
缘起:
偶尔有同学反应容器很慢,查看容器状态发现内存没用完了;问题是,oom命名是开启的,为什么不杀进程呢?
其实,我忽略了一个问题,为了不必要的内存浪费,我给每个容器都配备了相当多的swap,oom是发生在连swap都被用完的情况下的;上面的情况是:内存用完了,但是swap还足够,开始大量使用swap,于是乎,反应就很慢;不仅如此,swap引发的设备IO,是不受单个容器的IO配额限制的,在没有控制的情况下疯狂使用swap会导致其他容器也会变慢
结论:
容器之间的资源隔离是相对的,总是会有某些情况下,容器之间会相互影响的;有些场景下,这些问题都无所谓,有些情况下就是致命的
http://ceph.com/releases/v12-2-0-luminous-released/
This is the first release of Luminous v12.2.x long term stable release
series. There have been major changes since Kraken (v11.2.z) and
Jewel (v10.2.z), and the upgrade process is non-trivial. Please read
these release notes carefully. The next stable release will be named
Mimic.
“过程改进”是多么抽象的一个词语,没有说什么过程,也没有说改进什么,简直没法执行。
是的,过程改进对人的要求还是比较高的,首先,你要能发现需要改进的过程,然后你还要发现如何去改进;这里对人的一个重要要求就是: 你愿意。
我几乎没做一件事情都能发现做法需要优化,但是,很多人重复100遍都不会去思考是否可以改进一下,反而习以为常了。
有些事情,昨天这么做可能已经是很好的了,但是,今天还这么做可能就很落后了,所以,人要在实践的过程中不断地思考,不断地改进。
另外,能否进行“过程改进”和人的能力也有直接关系,对有些人来说,能正确执行现有流程已经是很高的要求了,改进是不可能的。
再者,也有人觉得,我已经觉得自己很优秀了,不需要改进了。
如何才能让每个人都积极地思考过程改进呢????
$PROMPT_COMMAND 里面可以执行命令,比如记录上次执行了什么命令
https://stackoverflow.com/questions/3058325/what-is-the-difference-between-ps1-and-prompt-command
有了这个就再也不用羡慕人家的PS1帅气了
1 |
python manage.py createsuperuser |
python manage.py shell
|
1 2 3 4 5 6 |
from django.contrib.auth.models import User user=User() user.username="admin" user.is_superuser=True user.set_password('admin') user.save() |