相同的sql 在vm和物理机上执行时间不一致

whiterain

物理机：

环境： 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

whiterain

附件是虚拟机上raw trace文件。

whiterain

附件是物理上raw trace 文件。

whiterain

create table nq_trade.tt as select * from nq_trade.T0_Stockholder order by stock_account
两遍执行的sql都是这个
在物理的trace文件里面 sql显示的不太全。

whiterain

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的。

Liu Maclean(刘相兵

参考这个讨论
http://t.askmaclean.com/thread-2994-1-1.html

whiterain

老大看了您说的这个帖子：还有一个不明白：
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的处理能力有差别吗？

whiterain

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

whiterain

980 E7-2860
580 E7-4860
都是2.2G的。

Liu Maclean(刘相兵

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;
/



给出几个环境的输出

whiterain

raw trace文件在附件。

whiterain

执行这段代码了：

580  23.33s

980  11.12s

Liu Maclean(刘相兵

580  23.33s

980  11.12s
vm  也是11s


单core 的主频   vm=980 > 580   大约等于 2 * 580的CPU

whiterain

单core的主频  980=580  

Liu Maclean(刘相兵

2个环境都看下

cat /proc/cpuinfo

whiterain

看了，频率一样。

Liu Maclean(刘相兵

DL580g7使用
处理器系列
英特尔® 至强® 7500 系列或者 6500 系列

whiterain

980 E7-2860
580 E7-4860
其实cpu一样，2860  qpi=2 E7-4860 qpi=4， cpu主频和二级缓存一样一样的。

whiterain

新的G7 已经可以用E7 了。

Liu Maclean(刘相兵

实际测试 和 规格有区别， 说明 硬件或者操作系统 可能存在问题