Docker存储之Devicemapper

问题

docker 容器中创建很大的文件会占用较多的docker存储空间(很正常啊),在容器内部df可以看到容量的变化,在宿主机上docker info也能看到data空间的变化;

当把那个(或那些)很大的文件删除后,在容器内部df可以看到已用容量减小,可用容量变大,但是宿主机上docker info看到的已用空间却没有减少,也就是说,已经分配出去的就收不回来了。

怎么办?

也不是完全回收不了,当把那个容器删除掉,docker info看到的已用空间就会减少了

 

所以

  1. 必要的时候可以重建容器
  2. 不是特别需要的话,不要在容器内部写太多的数据,大数据写到卷上

软件可维护性

软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。
决定可维护性的因素:
1.系统的大小
2.系统的年龄
3.结构合理性
可维护性可通过7个质量特性来衡量:
可理解性
可测试性
可修改性
可靠性
可移植性
可使用性
效率

注意: 没有 可扩展性,可扩展性和可修改性是不同的概念

nginx 配置点滴

  1. 重定向
    1. rewrite可以重定向
    2. return 301 $url; 也能重定向,简单的重定向使用return 301更简介,如,强制访问443端口,80段定义如下:

       
  2. return 301 $url ; 不同于 return $url ;
    1. 后者不会导致页面跳转,而是服务器端代为请求了
  3. location = / 不能嵌套在其他的location中,虽然逻辑上似乎合理,但是执行不到
  4. nginx中常用的变量: http://nginx.org/en/docs/varindex.html
  5. lua openresty https://github.com/openresty/lua-nginx-module

关于location:

  1. location之间是互斥的,可以嵌套,但不可以继承,如:
    1. location / 嵌套在 location / 中,虽然没有语法错误,但是,内层的location不会被执行到
    2. location /sub 嵌套在 location / 中时,如果匹配到了location sub 则location / 里面 ,location /sub 外面的逻辑不会被执行到,这就是我所谓的不可以继承,效果等同于并列的两个location

开发库

开发库是开发人员修改代码的地方。(开发人员可以随意修改)
受控库是测试版本代码存放的地方。(需要开发组长提交测试申请修改)
产品库是测试通过版本存放的地方。(需要测试报告来驱动修改)

参考
http://blog.sina.cn/dpool/blog/s/blog_4ec6138401000akg.html?vt=4

java cpu 100% 无响应

占用cpu高的线程的堆栈如下:

gdb 跟进发现:线程在函数Dependencies::find_finalizable_subclass(Klass*) 中,应该有一个循环,不断地调用函数Klass::subklass()

 

解决办法:

The fix was simple – disable CMS class unloading options when -Xnoclassgc or -XX:-ClassUnloading are specified.

参考资料:

https://blogs.oracle.com/poonam/entry/jvm_hang_with_cms_collector

 

想阅读jvm源码吗? https://blogs.oracle.com/sundararajan/entry/so_you_want_to_read