我自己搭建了一个CloudFoundry平台,不是用bosh,手工编译各个模块代码搞的,解决了各种问题之后……
push一个app,可以正常运行,再push一个还可以正常运行,但是……
当单机(为了测试性能,我只用了一个dea和warden)创建的container达到十几个、二十几个的时候(具体数目很难给,占用资源比较大的java项目的话只能是十几个,nginx静态站点可以达到二十几个),再push app就会失败,提示说内存不够,OOM了……而实际上此时用free -g查看系统内存还有100多G空闲
手工使用warden命令行,create一个container,copy_in一个jdk,运行java -version仍然提示:
There is insufficient memory for the Java Runtime Environment to continue. Cannot create GC thread. Out of system resources
手工使用warden命令行进入刚才的container,执行free -g看到的跟在宿主机上面看到的一样,还有好些内存没用,执行ulimit -a看到的限制感觉也没问题,与之前正常运行的那些container的ulimit -a效果一致
难道真的是内存不够用?我跑到宿主机上run了几个java app,一切正常……
现象就是这样了,描述的比较长,希望提供尽量多的线索,困扰了整整两天了,实在是搞不定,求各位OSC大神帮忙:) 开源中国貌似也搞了一个paas,不知道是不是基于cloudfoundry的,如果是的话, @红薯 有没有遇到这个问题呢?
补充:
进入cgroup的memory子系统目录查看相应的instance,自动创建的那些instance(用cf push app之后warden自动创建的instance)内存限制是读取的manifest.yml中的值,手工创建的那个instance,内存限制是long型最大值,所以看上去也不是cgroup在做限制的问题
好像是这些用warden管理的instance在共享了一些资源的感觉,而这个共享的资源总量有个限制,我只能这么怀疑了,唉,各种纠结
这个问题也是存在的,暂时没找早原因,还不确定是否和cgroup有关。
我在一个4核CPU+8G内存的开发机器上测试过,最多可以正常运行的应用也就10来个,每个应用分配的内存和实例数变化的话,可以跑的应用数量也不一样。所有应用分配的内存加起来不能超过16G左右,一旦超过,新的应用虽然可以push上去,但无法启动,使用cf客户端启动应用得到的结果只有“Application failed to stage”,根本就没有执行buildpack。进warden命令行看了下,warden container的数量没有增加,可见,新应用的container就没有创建成功或者没有创建。这时候查看系统内存也是和你的情况一样,一大半的内存都是空闲的,CPU也不是很高。
再跟大家说说进展……
上面叙述的问题是我们自己的问题居多,当时因为cf logs命令查看log信息的时候报权限错,就简单的把创建container的setup.sh中useradd vcap用户的uid给写死成宿主机vcap用户的uid了!而实际上每个container中的vcap用户的uid应该是不一样的,这样才方便做资源隔离
至于怎么处理cf logs报权限错的问题,我们现在是这么做的:http://qxh.iteye.com/blog/1985609
重新改回来之后再push应用,一个上百G内存的机器可以创建256个container,再创建就受限于网络问题了,不知道简单调整一下网络的pool_size是否可以解决,过两天再试试
今天跟 CF 的技术人员聊这个问题。他们讲到 CF 的一个用户默认是有内存限制的 1-2G 这样,需要自己手工去调整 DEA 的配置。@tsl0922