Redian新闻
>
请问怎么知道程序速度的瓶颈是在cpu还是内存?
avatar
p*e
3
比方说我有一个在单机上运行的并行程序,我想知道制约这个程序速度的瓶颈是在
CPU的运算速度还是内存读写速度。请问有没有什么测试程序能告诉我它的瓶颈
在哪里。
avatar
t*9
4
seatguru
avatar
d*3
6
你是想测第三方软件还是你自己写的?
第三方的话最简单的就是看资源管理器cpu和内存占用的变化咯
avatar
y*0
7
这个是查seat map,不是seat availablity吧?

【在 t*****9 的大作中提到】
: seatguru
avatar
p*4
8
这你也信?
avatar
p*e
9
主要还是第三方的,我还没有想过怎么自己去写这个测试的步骤。我用linux的环境。我
试过用i7z,这是一个测试CPU load的程序。当我运行一个瓶颈在内存的程序的时候。
我可以看到CPU不总是100%的占满。但是当我用top或者htop的时候,就看不到这个现象。
所以我觉得用top看到的不一定准确。其实我想知道有没有什么一般的规则,比方说如果
一个程序的数据吞吐量很大的话,(远大于CPU cache的size),那么这个程序的瓶颈
几乎就肯定是在内存方面。

【在 d*******3 的大作中提到】
: 你是想测第三方软件还是你自己写的?
: 第三方的话最简单的就是看资源管理器cpu和内存占用的变化咯

avatar
y*b
10
除了top,free看内存消耗很管用
一旦swap大了,不仅程序性能急剧下降,系统都可能失去反应
avatar
d*a
11
你说的要求,包含了两个不同的概念:一个是内存够不够大,另一个是内存访问是不是
瓶颈。
前者可以通过top看到,内存不够大会产生很多I/O访问,系统层的CPU占用率就低。CPU
占用率100%,只是说这个程序没有太多的I/O,内存是足够大了。
后者可以用performance counter monitor工具来看CPI和内存访问频率。一个占用CPU
100%的程序,也有可能CPI极低,时间都花在内存访问上了。

。我
象。
如果

【在 p******e 的大作中提到】
: 主要还是第三方的,我还没有想过怎么自己去写这个测试的步骤。我用linux的环境。我
: 试过用i7z,这是一个测试CPU load的程序。当我运行一个瓶颈在内存的程序的时候。
: 我可以看到CPU不总是100%的占满。但是当我用top或者htop的时候,就看不到这个现象。
: 所以我觉得用top看到的不一定准确。其实我想知道有没有什么一般的规则,比方说如果
: 一个程序的数据吞吐量很大的话,(远大于CPU cache的size),那么这个程序的瓶颈
: 几乎就肯定是在内存方面。

avatar
u*n
12
On linux, you may run oprofile to profile your program to understand time
consumed by your functions.
Also see this:
https://www.akkadia.org/drepper/cpumemory.pdf

【在 p******e 的大作中提到】
: 比方说我有一个在单机上运行的并行程序,我想知道制约这个程序速度的瓶颈是在
: CPU的运算速度还是内存读写速度。请问有没有什么测试程序能告诉我它的瓶颈
: 在哪里。

avatar
p*e
13

CPU
我知道我运行的程序所用的内存没有超过机器的内存大小,因为我用htop看过,
硬盘上的swap空间确实是没有被动用过。但是由于程序用的数据量比较大,
做过分析的人告诉我说实际上CPU在很大的时间内是在等待和内存交换数据,
所以升级CPU对于性能的提升有限。
CPU
我找到了一些分析的程序,像perf,glances。不过看了得仔细的看说明来学一下这些
工具
怎么用.

【在 d***a 的大作中提到】
: 你说的要求,包含了两个不同的概念:一个是内存够不够大,另一个是内存访问是不是
: 瓶颈。
: 前者可以通过top看到,内存不够大会产生很多I/O访问,系统层的CPU占用率就低。CPU
: 占用率100%,只是说这个程序没有太多的I/O,内存是足够大了。
: 后者可以用performance counter monitor工具来看CPI和内存访问频率。一个占用CPU
: 100%的程序,也有可能CPI极低,时间都花在内存访问上了。
:
: 。我
: 象。
: 如果

avatar
p*e
14
多谢。我回来学一学这个oprofile怎么使用。

【在 u**n 的大作中提到】
: On linux, you may run oprofile to profile your program to understand time
: consumed by your functions.
: Also see this:
: https://www.akkadia.org/drepper/cpumemory.pdf

avatar
u*n
15
Then you may revisit your algorithm and data structure, make it cache
friendly. There are also prefetch instructions which might help hide memory
access latency.

【在 p******e 的大作中提到】
: 多谢。我回来学一学这个oprofile怎么使用。
avatar
d*a
16
是这样。用top看到CPU占用率100%,只是说程序没有浪费时间在I/O上。用top是看不到
内存系统性能的。
如前所说,要用performance counter monitor工具来看内存访问频率和CPI。perf可以
。glances和top类似,不是做这个用的。

【在 p******e 的大作中提到】
: 多谢。我回来学一学这个oprofile怎么使用。
avatar
j*I
17
用top或者类似的看virtual page.如果virtual page一直太大,可能是这个app耗内存
,或者内存管理有问题。内存问题最后多多少少会引起swap,看page fault number.
至于CPU运算速度,我觉得你想的说的是程序的算法效率或者复杂度相对于CPU的问题?
这个通过简单的用系统的工具看指标我觉得意义不是很大。

【在 p******e 的大作中提到】
: 比方说我有一个在单机上运行的并行程序,我想知道制约这个程序速度的瓶颈是在
: CPU的运算速度还是内存读写速度。请问有没有什么测试程序能告诉我它的瓶颈
: 在哪里。

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。