CloudFoundry中warden创建的container有上限?

UlricQin 发布于 2013/12/04 08:22
阅读 690
收藏 1

我自己搭建了一个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在共享了一些资源的感觉,而这个共享的资源总量有个限制,我只能这么怀疑了,唉,各种纠结


加载中
0
tsl0922
tsl0922

这个问题也是存在的,暂时没找早原因,还不确定是否和cgroup有关。 

我在一个4核CPU+8G内存的开发机器上测试过,最多可以正常运行的应用也就10来个,每个应用分配的内存和实例数变化的话,可以跑的应用数量也不一样。所有应用分配的内存加起来不能超过16G左右,一旦超过,新的应用虽然可以push上去,但无法启动,使用cf客户端启动应用得到的结果只有“Application failed to stage”,根本就没有执行buildpack。进warden命令行看了下,warden container的数量没有增加,可见,新应用的container就没有创建成功或者没有创建。这时候查看系统内存也是和你的情况一样,一大半的内存都是空闲的,CPU也不是很高。

tsl0922
tsl0922
回复 @UlricQin : 也是3.x的,具体不记得了,公司电脑,明天才能看。
UlricQin
UlricQin
回复 @tsl0922 : 我之前用的内核是3.2,升级到3.8之后的表现是: 部署nginx的static website,可以部署几十个,每个申请1G内存,甚至超过了我用的机器的物理内存(这次用的是16G的做测试) 感觉像是cgroup的问题啦 不过我升级完内核之后系统资源利用率还是上不去,尽管比之前要好,现在跟你说的情况类似了,你用的内核版本是?
UlricQin
UlricQin
回复 @tsl0922 : 我尝试过一个nginx的static website,这个只占用几M就可以run,不过我在cf push的时候给它分配了1G内存限制,这样类型的app在一个100多G内存的机器上可以跑30个左右,即使分配的内存额度别的app不能用,那也就是用去了30G,还剩70G没用起来。。。
tsl0922
tsl0922
回复 @红薯 : 这个起不到太大作用。它应该是会为应用保留分配的资源,即使应用没有使用那么多资源,这个也是合理的。一个应用空闲的资源不多,但很多个应用空闲的资源加起来就很可观了。
红薯
红薯
@tsl0922 咱能否把 tomcat 换成 Jetty ? 这个占资源更少些
下一页
0
UlricQin
UlricQin

再跟大家说说进展……

上面叙述的问题是我们自己的问题居多,当时因为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是否可以解决,过两天再试试

UlricQin
UlricQin
回复 @红薯 : 128的
红薯
红薯
上百G内存的机器?
0
红薯
红薯

今天跟 CF 的技术人员聊这个问题。他们讲到 CF 的一个用户默认是有内存限制的 1-2G 这样,需要自己手工去调整 DEA 的配置。@tsl0922

tsl0922
tsl0922
磁盘也是有这个限制的,需要调整配置。
红薯
红薯
回复 @UlricQin : 哈哈,其实我明天是介绍业务的,技术方面我只是了解个大概
UlricQin
UlricQin
总感觉有个地方怪怪的。。。原来是老大DEA手误了,呵呵,明天红薯老大去介绍oschina的paas?
返回顶部
顶部