Cloud Foundry我自己搭建了一个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