n******7
发帖数: 12463 | 1 有几个问题请教：
1. 如何效率地评估java程序的内存消耗和运行时间?
前几天问了java code在不同机器上内存消耗不同的问题。现在测试了不同的Xms Xmx参
数，同样的机器使用16core，16个进程时大致如下.基本上Xms=1/2g,Xmx=6g时内存消耗
最少，也显著比其他参数要快。没有再往下测了。但是这样测试觉得好没效率，有没有
什么自动半自动的方法可以做这个评估的？特别是很多语言benchmark的测试，他们是
怎么评估像java这样语言的速度和内存使用的？
Xms Xmx
16g 112g: cput=11:50:14,mem=30666936kb,vmem=125003524kb,walltime=00:48
:24
16g 48g: cput=11:50:32,mem=28415984kb,vmem=55443888kb,walltime=00:48:
22
16g 40g: cput=11:47:43,mem=25669572kb,vmem=46747780kb,walltime=00:48:
13
16g 32g: cput=11:49:53,mem=22904308kb,vmem=38052696kb,walltime=00:48:23
24g 24g: cput=11:55:54,mem=25863512kb,vmem=29357612kb,walltime=00:48:
37
16g 24g: cput=11:50:52,mem=20067280kb,vmem=29357612kb,walltime=00:48:
09
16g 16g: cput=11:55:02,mem=17261712kb,vmem=20663064kb,walltime=00:48:50
12g 12g: cput=11:56:16,mem=12966704kb,vmem=16314988kb,walltime=00:48:55
6g 12g: cput=11:47:45,mem=8621560kb,vmem=16314988kb,walltime=00:48:36
8g 8g: cput=11:55:50,mem=8670664kb,vmem=11967980kb,walltime=00:48:49
4g 8g: cput=11:50:20,mem=5776760kb,vmem=11967448kb,walltime=00:48:29
2g 8g： cput=11:48:40,mem=4331176kb,vmem=11967448kb,walltime=00:48:41
6g 6g: cput=11:55:44,mem=6518500kb,vmem=9793676kb,walltime=00:48:59
2g 6g: cput=11:26:22,mem=3628316kb,vmem=9793676kb,walltime=00:47:49
1g 6g: cput=11:25:40,mem=3005524kb,vmem=9793676kb,walltime=00:47:48
2.另外我在同样的参数和硬件下测试了线程数>core数的效果，还是有进步的，这是不
是intel超线程的功效？每个线程本身是可以占满一个core的
6g 12g (16cores，32 threads）: cput=11:30:03,mem=8625976kb,vmem=
17380012kb,walltime=00:46:10
6g 12g (16cores，16 threads）: cput=11:47:45,mem=8621560kb,vmem=
16314988kb,walltime=00:48:36
3.内存使用似乎还是跟硬件有关？code的behavior是完全一样的，内存使用也应该完全
一样吧？
xms=1g,xmx=6g，12core，12threads的情况下：
在E5上：
cput=10:10:59,mem=2902424kb,vmem=9527420kb,walltime=00:56:01
在X5上：
cput=10:47:46,mem=2945292kb,vmem=9319108kb,walltime=00:58:58 | w**z
发帖数: 8232 | 2 you need to look into GC settings, there are a lot of knobs to turn. if you
are not familiar with GC, be careful turning the knobs. There is no one GC
setting which fits all applications. it really depends on the
characteristics of your app.
【在 n******7 的大作中提到】
: 有几个问题请教：
: 1. 如何效率地评估java程序的内存消耗和运行时间?
: 前几天问了java code在不同机器上内存消耗不同的问题。现在测试了不同的Xms Xmx参
: 数，同样的机器使用16core，16个进程时大致如下.基本上Xms=1/2g,Xmx=6g时内存消耗
: 最少，也显著比其他参数要快。没有再往下测了。但是这样测试觉得好没效率，有没有
: 什么自动半自动的方法可以做这个评估的？特别是很多语言benchmark的测试，他们是
: 怎么评估像java这样语言的速度和内存使用的？
: Xms Xmx
: 16g 112g: cput=11:50:14,mem=30666936kb,vmem=125003524kb,walltime=00:48
: :24
| z****e
发帖数: 54598 | 3 没太看懂你要评估啥东西
你是打算计算平均内存使用吗？
java的大部分程序，内存是托管的
使用的情况是动态的，因为一旦过了临界点，就会触发gc
gc之后，内存使用就小一点，这个动态的过程你评估了有啥用？
你是担心内存使用太多导致溢出吗？ | z****e
发帖数: 54598 | 4 一般对于java 内存的评估主要介于两点
一点是怀疑有memory leak，这个对系统伤害很大
所以监控看看有没有什么问题，还有死锁之类的
但是现在都lock free了，一般也不太容易搞出后者来
另外一点是gc的停顿时间，这个对于一些游戏的server来说
会比较敏感，所以会监控看看gc需要多长时间
但是你这个貌似不是游戏也不是什么memory leak
不太明白你为啥要去监控内存？ | n******7
发帖数: 12463 | 5 我的理解是Xms Xmx是最主要，也最好控制的两个参数？我只想直到对于我这个code，
怎么最快找到接近最佳的参数
比如这里说的
http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbag
Table 1: JVM Options to Be Checked for GC Tuning.
-Xms Heap area size when starting JVM
-Xmx Maximum heap area size
-XX:NewRatio Ratio of New area and Old area
-XX:NewSize New area size
-XX:SurvivorRatio Ratio of Eden area and Survivor area
you
GC
【在 w**z 的大作中提到】
: you need to look into GC settings, there are a lot of knobs to turn. if you
: are not familiar with GC, be careful turning the knobs. There is no one GC
: setting which fits all applications. it really depends on the
: characteristics of your app.
| n******7
发帖数: 12463 | 6 主要两个目的：
1. 尽量减少内存使用。因为在cluster上跑job有cpu和内存配额，需要的内存越少越好
2. 我本来琢磨触发GC会降低运行效率，所以想测试不同参数下运行时间，在内存使用
和运行时间之间找一个平衡。 不过这个结果似乎说明，GC不是问题，最快的结果是在
XMX参数最小的时候获得的。另外XMS参数不宜过大。
我结果里面的mem用量是每个参数下极限mem使用量，所以还是可比的。我的job必须指
定比这个量大的mem用量才不会被杀掉
【在 z****e 的大作中提到】
: 一般对于java 内存的评估主要介于两点
: 一点是怀疑有memory leak，这个对系统伤害很大
: 所以监控看看有没有什么问题，还有死锁之类的
: 但是现在都lock free了，一般也不太容易搞出后者来
: 另外一点是gc的停顿时间，这个对于一些游戏的server来说
: 会比较敏感，所以会监控看看gc需要多长时间
: 但是你这个貌似不是游戏也不是什么memory leak
: 不太明白你为啥要去监控内存？
| k**********g
发帖数: 989 | 7
In terms of overall CPU efficiency (averaged over time), GC is almost
negligible.
You should measure maximum GC pause. If this pause is within your acceptable
tolerance, then there is no problem at all. Feel free to use the minimum
amount of RAM that your program will run correctly (i.e. without failing).
If you don't have control over the peak memory usage (e.g. there are ways or
situations where your program will allocate too much memory, exceeding the
limit), you have to:
(1) Put some limits inside your algorithm; refuse to process input or stop
processing if the memory limit will be exceeded
(2) Modify your algorithm to use less memory
(3) Let your program die while sending a suitable diagnostic signal to
another watchdog program. Have the watchdog program re-launch the Java
program with increased memory limits, and try process the same data again.
Keep increasing the limit until it is successful.
Just my 2 cents.
【在 n******7 的大作中提到】
: 主要两个目的：
: 1. 尽量减少内存使用。因为在cluster上跑job有cpu和内存配额，需要的内存越少越好
: 2. 我本来琢磨触发GC会降低运行效率，所以想测试不同参数下运行时间，在内存使用
: 和运行时间之间找一个平衡。 不过这个结果似乎说明，GC不是问题，最快的结果是在
: XMX参数最小的时候获得的。另外XMS参数不宜过大。
: 我结果里面的mem用量是每个参数下极限mem使用量，所以还是可比的。我的job必须指
: 定比这个量大的mem用量才不会被杀掉
| w**z
发帖数: 8232 | 8 as I said, it depends on your app. How the objects are created? small
objects or big? long lived or short lived? things like that. if your app is
only for computation, you probably don't care about GC pause, the bigger the
heap, the faster it runs. If you really want to look at GC, turn on GC log.
【在 n******7 的大作中提到】
: 我的理解是Xms Xmx是最主要，也最好控制的两个参数？我只想直到对于我这个code，
: 怎么最快找到接近最佳的参数
: 比如这里说的
: http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbag
: Table 1: JVM Options to Be Checked for GC Tuning.
: -Xms Heap area size when starting JVM
: -Xmx Maximum heap area size
: -XX:NewRatio Ratio of New area and Old area
: -XX:NewSize New area size
: -XX:SurvivorRatio Ratio of Eden area and Survivor area
| n******7
发帖数: 12463 | 9 谢谢，非常有用
Feel free to use the minimum amount of RAM that your program will run
correctly (i.e. without failing).
这个好，我就不用测这么细了
现在这个code的行为基本是可预测的，跑一遍峰值内存就知道了，只取决于线程数。
这个watchdog 的建议不错，想起来组里面一个人有个类似的东西，用来resubmit
failed job
有需要的时候也的弄一个:)
【在 k**********g 的大作中提到】
:
: In terms of overall CPU efficiency (averaged over time), GC is almost
: negligible.
: You should measure maximum GC pause. If this pause is within your acceptable
: tolerance, then there is no problem at all. Feel free to use the minimum
: amount of RAM that your program will run correctly (i.e. without failing).
: If you don't have control over the peak memory usage (e.g. there are ways or
: situations where your program will allocate too much memory, exceeding the
: limit), you have to:
: (1) Put some limits inside your algorithm; refuse to process input or stop
| n******7
发帖数: 12463 | 10
这个我现在明白了 GC pause对我无所谓
这个我有疑问。就我的结果，同样Xmx的情况下，Xms越小反而越快
6g 6g: cput=11:55:44,mem=6518500kb,vmem=9793676kb,walltime=00:48:59
2g 6g: cput=11:26:22,mem=3628316kb,vmem=9793676kb,walltime=00:47:49
1g 6g: cput=11:25:40,mem=3005524kb,vmem=9793676kb,walltime=00:47:48
虽然只测了一次，这个1分钟的差异还是挺大的
而同样Xms的情况下，Xmx几乎没影响
16g 112g:cput=11:50:14,mem=30666936kb,vmem=125003524kb,walltime=00:48:24
16g 48g: cput=11:50:32,mem=28415984kb,vmem=55443888kb,walltime=00:48:22
16g 40g: cput=11:47:43,mem=25669572kb,vmem=46747780kb,walltime=00:48:13
16g 32g: cput=11:49:53,mem=22904308kb,vmem=38052696kb,walltime=00:48:23
16g 24g: cput=11:50:52,mem=20067280kb,vmem=29357612kb,walltime=00:48:09
16g 16g: cput=11:55:02,mem=17261712kb,vmem=20663064kb,walltime=00:48:50
【在 w**z 的大作中提到】
: as I said, it depends on your app. How the objects are created? small
: objects or big? long lived or short lived? things like that. if your app is
: only for computation, you probably don't care about GC pause, the bigger the
: heap, the faster it runs. If you really want to look at GC, turn on GC log.
| | | w**z
发帖数: 8232 | 11 the common practice is to set the Xms = Xmx for server app. my guess is that
your app is more cpu bound than memory bound. but someone says Xms doesn't
make difference. personally, I always set Xms the same as Xmx. http://java-monitor.com/forum/showthread.php?t=427
【在 n******7 的大作中提到】
:
: 这个我现在明白了 GC pause对我无所谓
: 这个我有疑问。就我的结果，同样Xmx的情况下，Xms越小反而越快
: 6g 6g: cput=11:55:44,mem=6518500kb,vmem=9793676kb,walltime=00:48:59
: 2g 6g: cput=11:26:22,mem=3628316kb,vmem=9793676kb,walltime=00:47:49
: 1g 6g: cput=11:25:40,mem=3005524kb,vmem=9793676kb,walltime=00:47:48
: 虽然只测了一次，这个1分钟的差异还是挺大的
: 而同样Xms的情况下，Xmx几乎没影响
: 16g 112g:cput=11:50:14,mem=30666936kb,vmem=125003524kb,walltime=00:48:24
: 16g 48g: cput=11:50:32,mem=28415984kb,vmem=55443888kb,walltime=00:48:22
| h**********c
发帖数: 4120 | 12 suggest you read Java Performance, written by Oracle engineers.
My thinking is GC should be handled out of the vm box. Single VM should be
stress-tested and the program/task should be able to throttle itself for
memory utilization and persist over usage to database. Use cluster/load
balancer to comprehensively conduct the VMs' symphony by major process
tables' reading or VM status readings -- process threshhold trigger balancer
audit and administration.
Unfortunately, in real life, we rather have to fight ignorance and
neglegance than build useful product to sustain the value of the society.
有几个问题请教：
1. 如何效率地评估java程序的内存消耗和运行时间?
前几天问了java code在不同机器上内存消耗不同的问题。现在测试了不同的Xms Xmx参
数，同样的机器使用16core，16个进程时大致如下.基本上Xms=1/2g,Xmx=6g时内存消耗
最少，也显著比其他参数要快。没有再往下测了。但是这样测试觉得好没效率，有没有
什么自动半自动的方法可以做这个评估的？特别是很多语言benchmark的测试，他们是
怎么评估像java这样语言的速度和内存使用的？
Xms Xmx
16g 112g: cput=11:50:14,mem=30666936kb,vmem=125003524kb,walltime=00:48
16g 48g: cput=11:50:32,mem=28415984kb,vmem=55443888kb,walltime=00:48:
22
16g 40g: cput=11:47:43,mem=25669572kb,vmem=46747780kb,walltime=00:48:
13
16g 32g: cput=11:49:53,mem=22904308kb,vmem=38052696kb,walltime=00:48:23
24g 24g: cput=11:55:54,mem=25863512kb,vmem=29357612kb,walltime=00:48:
37
16g 24g: cput=11:50:52,mem=20067280kb,vmem=29357612kb,walltime=00:48:
09
16g 16g: cput=11:55:02,mem=17261712kb,vmem=20663064kb,walltime=00:48:50
12g 12g: cput=11:56:16,mem=12966704kb,vmem=16314988kb,walltime=00:48:55
6g 12g: cput=11:47:45,mem=8621560kb,vmem=16314988kb,walltime=00:48:36
8g 8g: cput=11:55:50,mem=8670664kb,vmem=11967980kb,walltime=00:48:49
4g 8g: cput=11:50:20,mem=5776760kb,vmem=11967448kb,walltime=00:48:29
2g 8g： cput=11:48:40,mem=4331176kb,vmem=11967448kb,walltime=00:48:41
6g 6g: cput=11:55:44,mem=6518500kb,vmem=9793676kb,walltime=00:48:59
2g 6g: cput=11:26:22,mem=3628316kb,vmem=9793676kb,walltime=00:47:49
1g 6g: cput=11:25:40,mem=3005524kb,vmem=9793676kb,walltime=00:47:48
2.另外我在同样的参数和硬件下测试了线程数>core数的效果，还是有进步的，这是不
是intel超线程的功效？每个线程本身是可以占满一个core的
6g 12g (16cores，32 threads）: cput=11:30:03,mem=8625976kb,vmem=
17380012kb,walltime=00:46:10
6g 12g (16cores，16 threads）: cput=11:47:45,mem=8621560kb,vmem=
16314988kb,walltime=00:48:36
3.内存使用似乎还是跟硬件有关？code的behavior是完全一样的，内存使用也应该完全
一样吧？
xms=1g,xmx=6g，12core，12threads的情况下：
在E5上：
cput=10:10:59,mem=2902424kb,vmem=9527420kb,walltime=00:56:01
在X5上：
cput=10:47:46,mem=2945292kb,vmem=9319108kb,walltime=00:58:58
【在 n******7 的大作中提到】
: 有几个问题请教：
: 1. 如何效率地评估java程序的内存消耗和运行时间?
: 前几天问了java code在不同机器上内存消耗不同的问题。现在测试了不同的Xms Xmx参
: 数，同样的机器使用16core，16个进程时大致如下.基本上Xms=1/2g,Xmx=6g时内存消耗
: 最少，也显著比其他参数要快。没有再往下测了。但是这样测试觉得好没效率，有没有
: 什么自动半自动的方法可以做这个评估的？特别是很多语言benchmark的测试，他们是
: 怎么评估像java这样语言的速度和内存使用的？
: Xms Xmx
: 16g 112g: cput=11:50:14,mem=30666936kb,vmem=125003524kb,walltime=00:48
: :24
| w***g
发帖数: 5958 | 13 你的出发点是好的，但我觉得没做到点子上。48分钟walltime，就是差1分钟，也就是2
%的样子，并不是显著差异。如果你非要测这2%的差异，那么就要跑比如10次取平均，
而且每次跑之前需要invalidate buffer cache http://aplawrence.com/Linux/buffer_cache.html。有各种原因可能导致2%的差异，不一定光是Xms, Xmx的问题。当然最后测出来，可能还是只有2%的差异。所以还不如花时间在优化代码上，尽量简化代码的内存分配，减少不确定性，提高L2 cache命中率。前面也提了，把Xmx和Xms设成比你可用的最大量小一点就可以，反正不用也是浪费。
thread > core会有性能提升是因为一个thread block的时候另一个thread可以跑。
hyperthread有时候有帮助，有时候反而会使得程序更慢，没有一个定论。我认识有的人
一上来就disable hyperthreading。我的经验是hyperthread能有一定的性能提升。
如果你的cache命中率本来就低，那么再提高线程数可能还能更快。但正道是改代码
提高命中率而不是增加线程数。
【在 n******7 的大作中提到】
: 有几个问题请教：
: 1. 如何效率地评估java程序的内存消耗和运行时间?
: 前几天问了java code在不同机器上内存消耗不同的问题。现在测试了不同的Xms Xmx参
: 数，同样的机器使用16core，16个进程时大致如下.基本上Xms=1/2g,Xmx=6g时内存消耗
: 最少，也显著比其他参数要快。没有再往下测了。但是这样测试觉得好没效率，有没有
: 什么自动半自动的方法可以做这个评估的？特别是很多语言benchmark的测试，他们是
: 怎么评估像java这样语言的速度和内存使用的？
: Xms Xmx
: 16g 112g: cput=11:50:14,mem=30666936kb,vmem=125003524kb,walltime=00:48
: :24
| n******7
发帖数: 12463 | 14 不错，这样只用测试XMX就好，更省事了
that
t
【在 w**z 的大作中提到】
: the common practice is to set the Xms = Xmx for server app. my guess is that
: your app is more cpu bound than memory bound. but someone says Xms doesn't
: make difference. personally, I always set Xms the same as Xmx. http://java-monitor.com/forum/showthread.php?t=427
| n******7
发帖数: 12463 | 15 我实际一个run大概需要24小时，以后加了data可能更长。这次主要想看看内存可以少
到什么程度，速度能有多大提升。到时候给用户使用，还是资源消耗越少越好。
不过2%的差异确实不大，测试之前不知道能有多大区别，测试之后是奇怪为啥更小的
XMS可以更快
你可以看到cput在差异在5%左右，这是不是说，Xms小的情况下，并行效率更高了？我
第一次写java，以后估计也不怎么用了，这些问题主要是好奇...
如果用其他48分钟的run来评估背景的SD的话，这两个个47分钟的run大概在3个z-score
之外了。当然，像你说的，区别不大，所以也不详细测试了。
提高cache命中率我是一窍不通，不过先记下了。以后万一遇到类似问题，也知道改去
查些啥：）
是2
的人
【在 w***g 的大作中提到】
: 你的出发点是好的，但我觉得没做到点子上。48分钟walltime，就是差1分钟，也就是2
: %的样子，并不是显著差异。如果你非要测这2%的差异，那么就要跑比如10次取平均，
: 而且每次跑之前需要invalidate buffer cache http://aplawrence.com/Linux/buffer_cache.html。有各种原因可能导致2%的差异，不一定光是Xms, Xmx的问题。当然最后测出来，可能还是只有2%的差异。所以还不如花时间在优化代码上，尽量简化代码的内存分配，减少不确定性，提高L2 cache命中率。前面也提了，把Xmx和Xms设成比你可用的最大量小一点就可以，反正不用也是浪费。
: thread > core会有性能提升是因为一个thread block的时候另一个thread可以跑。
: hyperthread有时候有帮助，有时候反而会使得程序更慢，没有一个定论。我认识有的人
: 一上来就disable hyperthreading。我的经验是hyperthread能有一定的性能提升。
: 如果你的cache命中率本来就低，那么再提高线程数可能还能更快。但正道是改代码
: 提高命中率而不是增加线程数。
| a***n
发帖数: 538 | 16 据说xmx不要超过4g。java7以后的g1gc好像比较好，我没有测出区别来，不过好像停顿
会变小。 | n******7
发帖数: 12463 | 17 你是说xms吧？xmx不是总的memory pool size吗？这个没法给上限吧
【在 a***n 的大作中提到】
: 据说xmx不要超过4g。java7以后的g1gc好像比较好，我没有测出区别来，不过好像停顿
: 会变小。
| a***n
发帖数: 538 | 18 哦不知道，我一般都设成一样的了。另外超过一个物理cpu的话，好像还可以打开numa。
【在 n******7 的大作中提到】
: 你是说xms吧？xmx不是总的memory pool size吗？这个没法给上限吧
| g*****g
发帖数: 34805 | 19 The No.1 reason people tune GC is to balance between out of memory and long
GC pause. It looks to me neither concerns you. You should just use least
memory you need. | c*********e
发帖数: 16335 | 20 gc的停顿时间3-5 seconds.这个对于游戏来说太漫长了。
【在 z****e 的大作中提到】
: 一般对于java 内存的评估主要介于两点
: 一点是怀疑有memory leak，这个对系统伤害很大
: 所以监控看看有没有什么问题，还有死锁之类的
: 但是现在都lock free了，一般也不太容易搞出后者来
: 另外一点是gc的停顿时间，这个对于一些游戏的server来说
: 会比较敏感，所以会监控看看gc需要多长时间
: 但是你这个貌似不是游戏也不是什么memory leak
: 不太明白你为啥要去监控内存？
| | | c*********e
发帖数: 16335 | 21 和你的内存size 有关，越大越好。
【在 n******7 的大作中提到】
: 我的理解是Xms Xmx是最主要，也最好控制的两个参数？我只想直到对于我这个code，
: 怎么最快找到接近最佳的参数
: 比如这里说的
: http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbag
: Table 1: JVM Options to Be Checked for GC Tuning.
: -Xms Heap area size when starting JVM
: -Xmx Maximum heap area size
: -XX:NewRatio Ratio of New area and Old area
: -XX:NewSize New area size
: -XX:SurvivorRatio Ratio of Eden area and Survivor area
| w**z
发帖数: 8232 | 22 if the new gen is too small, too many new gen GC will eat a lot of CPU.
long
【在 g*****g 的大作中提到】
: The No.1 reason people tune GC is to balance between out of memory and long
: GC pause. It looks to me neither concerns you. You should just use least
: memory you need.
| z****e
发帖数: 54598 | 23 楼主做的不是游戏，游戏gc一般不超过20ms
：gc的停顿时间3-5 seconds.这个对于游戏来说太漫长了。
： | c*********e
发帖数: 16335 | 24 3d游戏不是用的c++吗，哪来的gc?
angry birds底层也是用的c++ 呀。
【在 z****e 的大作中提到】
: 楼主做的不是游戏，游戏gc一般不超过20ms
:
: ：gc的停顿时间3-5 seconds.这个对于游戏来说太漫长了。
: ：
|
|
