warden memory

warden

google group中有人提到，给应用分配的内存会用于多个用途，包括：

The memory used by the warden container
The memory used to map kernel extensions and system libraries (such as libc) into the process
The memory used for the jvm executables, jvm working heap, jit space, compressed references and so on.
The memory used for classes (application server and application), thread stacks, direct io buffers, and so on.
The memory used by the java application heap

java default buildpack中，将java_opts中的Xmx和Xms都赋值为用户设置的Memory_Limit
如果Xmx=Xms，那么避免堆动态扩展。

Xmx是最大堆
Xms是最小堆。这是程序初始化时，内存大小
Xss是栈容量

warden容器不管应用的形式，是否为交互式应用

那么，问题应该就是java应用和warden容器直接的问题了。
修改xss过小会导致stackoverflow
修改xmx和xms没啥影响？

ps aux|grep java可以看到rss（实际内存大小）
对于设定的xmx，程序运行的rss是定值。
warden容器中运行的java程序，rss在达到最大值前，已经被kill。
通过设置Xmx不能解决该问题。

PerSize？MaxPerSize？

如果是java参数设置错误的话，应该会报错。
现在是java参数设置不会报错，但是warden容器将进程kill。
参考网上的说法是，oom，warden容器kill了java进程。

解决办法，增加warden容器memory_limit,已经设为1.5G,再增加也无意义。
减小java程序的开销。设置Xmx。256m，512m，均设过。没有明显变化。不设置也不行。

会跟启动时间有关吗？