我编译了代码并运行了两个可执行文件:exec1
和exec 2
。
它们都具有相同的代码,但它们被赋予不同的输入。
我使用的是操作系统Kubuntu
(非常新手)。
exec1
,另一个数据库用于exec2
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
stepping : 2
microcode : 0x10
cpu MHz : 2660.022
cache size : 12288 KB
physical id : 0
siblings : 6
core id : 10
cpu cores : 6
apicid : 20
initial apicid : 20
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
使用以下脚本(需要更新):
echo "timestamp,VmSize,VmRSS";
while awk '{ printf "%s,%s,%s\n", systime(), $1, $2}' /proc/13417/statm; do sleep 1; done
timestamp,VmSize,VmRSS
1427295959,92907,49655
1427295960,92907,49655
1427295961,92907,49655
1427295962,92907,49655
1427295964,92907,49655
1427295965,92907,49655
答案 0 :(得分:2)
是否可以知道同时运行两个可执行文件是否会影响两个可执行文件的速度?
如果运行一个可执行文件需要N秒,并且运行其中两个可执行文件需要相同的N秒(没有时间差),那么它们不会相互影响。
如何衡量每个可执行文件使用的内存量?
您可以使用这个小脚本每秒以csv格式输出时间戳和内存使用情况。
echo "timestamp,VmSizeKB,VmRssKB";
while awk '{ printf "%s,%s,%s\n", systime(), $1 * 4, $2 * 4}' /proc/<pid>/statm; do sleep 1; done
将<pid>
替换为您的进程ID。
可以直观地进行吗?
然后将该csv导入谷歌文档或其他电子表格应用程序并构建一个漂亮的图表。您只对VmRSS列感兴趣,这是您的进程使用的物理内存量。
答案 1 :(得分:1)
鉴于前提条件是(至少)有两个可用的物理CPU核心,并且您的程序没有庞大的私有工作集,并行运行两个实例通常比一个接一个地运行它们更快。在某些情况下,情况恰恰相反,但通常情况下,在健康的条件下情况就是如此。
在正常情况下,任何两个实例(并发或一个接一个)都将使用缓冲区缓存中相同的映射页面来获取可执行文件和只读数据,但同时运行的进程也具有更高的可能性最后一个缓存级别的内存,它们同时在不同的CPU核心上运行指令
此外,使用fork
创建的两个实例(见下文)将仅在fork
之前运行CRT初始化和任何初始化代码,并且不需要额外的shell。
(当然,当你的进程执行大量锁定或大量并发无缓存I / O或者如果它们消耗大量内存时,这些优点变得完全无关紧要并变成缺点,因此它们开始干扰不健康因此,“通常”,并非总是如此。)
两次运行相同程序的最简单方法(好吧,实际上是三次,如果算上父项)和测量(并比较它是否比一次调用更快)是调用fork
两次并自己进行测量。实际上调用fork
一次就足以运行这两个实例,但是这样做会更加扭曲以进行你想做的测量。
在fork
两次之后,你有两个子进程在运行(然后可以做他们应该做的任何事情)。父进程使用clock_gettime
获取当前时间,并在waitpid
上阻塞(两次)。
在waitpid
后,家长再次致电clock_gettime
并拨打times
。
您现在可以:
通过这种方式,您可以准确地确定执行子(子)的实时时间以及他们消耗了多少CPU时间(用户和内核)。
答案 2 :(得分:0)
你可以运行
myprogram argone &
myprogram argtwo &
运行在后台运行相同程序的两个进程。
您可能也会对batch
和nohup
以及top