相同的sql 在vm和物理机上执行时间不一致
物理机：环境： DL580g7 物理机器 E7-4660 memory：64G
os： redhat linux6.4
db： oracle 11.2.0.4
rac
虚拟机：
环境： esxi上的vm 内存5G
os： redhat linux6.4
db： oracle 11.2.0.4 sga：3G
单机
同样的sql在vm上运行时间130s 在物理机上运行时间217s
附件是10046的trace文件，麻烦刘大帮忙看看。
vm的是虚拟机的10046
perf是物理机的10046 附件是虚拟机上raw trace文件。 附件是物理上raw trace 文件。 create table nq_trade.tt as select * from nq_trade.T0_Stockholder order by stock_account
两遍执行的sql都是这个
在物理的trace文件里面 sql显示的不太全。 btw：在trace文件中有看到：
vm：
WAIT #8: nam='direct path read temp' ela= 146 file number=201 first dba=1770551 block cnt=31 obj#=80324 tim=1388651592727448
pm：
WAIT #140013268878352: nam='direct path read temp' ela= 7240 file number=201 first dba=1568128 block cnt=31 obj#=-1 tim=1389019792821405
ela 差别很大。
vm上是文件系统。
物理机是rac asm的。 参考这个讨论
http://t.askmaclean.com/thread-2994-1-1.html 老大看了您说的这个帖子：还有一个不明白：
vm：
create table nq_trade.tt as select * from nq_trade.T0_Stockholder order by
stock_account
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.04 0 14 1 0
Execute 1 130.79 160.18 1030332 499800 609580 91064301
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 130.81 160.22 1030332 499814 609581 91064301
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Rows Row Source Operation
------- ---------------------------------------------------
0 LOAD AS SELECT (cr=526777 pr=1030332 pw=1030332 time=0 us)
91064301 SORT ORDER BY (cr=492047 pr=1030332 pw=538372 time=49937528 us cost=970976 size=3096186234 card=91064301)
91064301 TABLE ACCESS FULL T0_STOCKHOLDER (cr=492047 pr=491960 pw=0 time=15763326 us cost=135960 size=3096186234 card=91064301)
pm：
create table nq_trade.tt
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.03 0.04 0 476 0 0
Execute 1 217.43 250.35 1030629 499340 614574 91064301
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 217.47 250.40 1030629 499816 614574 91064301
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
0 0 0 LOAD AS SELECT (cr=500252 pr=1030629 pw=1030323 time=250457812 us)
91064301 91064301 91064301 SORT ORDER BY (cr=492047 pr=1030629 pw=538363 time=168084693 us cost=1310971 size=4780628850 card=95612577)
91064301 91064301 91064301 TABLE ACCESS FULL BAK_STOCKHOLDER (cr=492047 pr=491960 pw=0 time=26741344 us cost=134350 size=4780628850 card=95612577)
两者主要的差别在排序的时间上，这个能说明cpu的处理能力有差别吗？
1. 在vm下清空os的cache。 第一次执行同样的sql用179s 第二次也清空了缓存，用了240s
2. 在980监察rac的环境下，asm的存储，执行同样的sql 用了140s。
3. 在原来的580的交易rac的环境下，asm的环境，执行同样的sql使用了260s。
下面是一些详细的情况：
create table aa as select * from bb order id。
执行该步骤主要有3个过程。 1. 扫描bb表。 2. 对bb表进行排序。 3. 将排序好数据插入到aa表中。
分析第一个步骤 扫描表，扫描表示对io要求比较高的操作。
在vm上，STAT #2 id=3 cnt=91064301 pid=2 pos=1 obj=80324 op='TABLE ACCESS FULL T0_STOCKHOLDER (cr=492052 pr=491972 pw=0 time=42237304
在980上.STAT #139734718575176 id=3 cnt=91064301 pid=2 pos=1 obj=84174 op='TABLE ACCESS FULL T0_STOCKHOLDER (cr=489570 pr=489564 pw=0 time=20634523
在580上，STAT #140651295510608 id=3 cnt=91064301 pid=2 pos=1 obj=92398 op='TABLE ACCESS FULL T0_STOCKHOLDER (cr=489794 pr=0 pw=0 time=33042339 us
vm上使用fs，为了防止文件系统的缓存影响，在vm上执行了清除缓存的操作后，vm >580 >980
分析第二个步骤 ，sort order by
vm上STAT #2 id=2 cnt=91064301 pid=1 pos=1 obj=0 op='SORT ORDER BY (cr=492052 pr=1030343 pw=538371 time=45776116
在980上 STAT #139734718575176 id=2 cnt=91064301 pid=1 pos=1 obj=0 op='SORT ORDER BY (cr=489570 pr=1027929 pw=538365 time=92280804 us
在580上 STAT #140651295510608 id=2 cnt=91064301 pid=1 pos=1 obj=0 op='SORT ORDER BY (cr=489794 pr=538363 pw=538363 time= 167233675
执行时间上 580>980>vm
分析第三个步骤：
vm： STAT #2 id=1 cnt=0 pid=0 pos=1 obj=0 op='LOAD AS SELECT (cr=494724 pr=1030353 pw=1030331 time=0 us)'
980：STAT #139734718575176 id=1 cnt=0 pid=0 pos=1 obj=0 op='LOAD AS SELECT (cr=490294 pr=1027942 pw=1030325 time=153536271 us)'
580：STAT #140651295510608 id=1 cnt=0 pid=0 pos=1 obj=0 op='LOAD AS SELECT (cr=497575 pr=538363 pw=1030323 time=260027699 us)'
执行时间：580>980>vm
980 E7-2860
580 E7-4860
都是2.2G的。 SET SERVEROUTPUT ON
SET TIMING ON
DECLARE
n NUMBER := 0;
BEGIN
FOR f IN 1..10000000
LOOP
n := MOD (n,999999) + SQRT (f);
END LOOP;
DBMS_OUTPUT.PUT_LINE ('Res = '||TO_CHAR (n,'999999.99'));
END;
/
给出几个环境的输出 raw trace文件在附件。 执行这段代码了：
580 23.33s
980 11.12s
580 23.33s
980 11.12s
vm 也是11s
单core 的主频 vm=980 > 580 大约等于 2 * 580的CPU
单core的主频 980=580 2个环境都看下
cat /proc/cpuinfo
看了，频率一样。
DL580g7使用
处理器系列
英特尔® 至强® 7500 系列或者 6500 系列 980 E7-2860
580 E7-4860
其实cpu一样，2860 qpi=2 E7-4860 qpi=4， cpu主频和二级缓存一样一样的。 新的G7 已经可以用E7 了。 实际测试 和 规格有区别， 说明 硬件或者操作系统 可能存在问题
页:
[1]