Сегодня делал небольшое исследование - сравнивал производительность двух серверов.
В частности, сделал такой самый простой тест, чтобы замерить скорость одного ядра:
set timing on
create table test (
Client_ID NUMBER,
NAME Varchar2(3),
FAMILY Varchar2(5),
DOLLARS NUMBER,
PASSWORD Varchar2(4),
BIRTHDAY DATE
) tablespace users;
insert into test
select
rownum ID,
DBMS_RANDOM.STRING ('A',3),
DBMS_RANDOM.STRING ('A',5),
DBMS_RANDOM.VALUE (0,1000),
DBMS_RANDOM.STRING ('X',4),
SYSDATE-DBMS_RANDOM.VALUE (6000,30000)
from dual connect by rownum <= 1000000;
select sum(bytes)/1048576 from user_segments where segment_name='TEST';
SUM(BYTES)/1048576
------------------
61
select count(*) from test;
select count(*) from test;
select count(*) from test;
select count(*) from test;
Табличка была целиком в памяти и время выполнения запроса стаблизировалось на цифре 10-20мс как на исходной так и второй системах:
SQL> set timing on
SQL> select count(*) from test;
select count(*) from test;
select count(*) from test;
COUNT(*)
----------
1000000
Elapsed: 00:00:00.03
SQL>
COUNT(*)
----------
1000000
Elapsed: 00:00:00.02
SQL>
COUNT(*)
----------
1000000
Elapsed: 00:00:00.01
Для того, чтобы повысить точность измерений решили включить трассировку и посмотреть время в микросекундах. После включения трассировки
alter session set events '10046 trace name context forever';
значения на обоих узлах стали 50-60мс:
PARSING IN CURSOR #139778252768168 len=25 dep=0 uid=84 oct=3 lid=84 tim=1327404119420870 hv=297253644 ad='2a99a2da8' sqlid='7b2twsn8vgfsc'
select count(*) from test
END OF STMT
PARSE #139778252768168:c=0,e=80,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1950795681,tim=1327404119420868
EXEC #139778252768168:c=0,e=30,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1950795681,tim=1327404119420975
FETCH #139778252768168:c=52992,e=54137,p=0,cr=7729,cu=1,mis=0,r=1,dep=0,og=1,plh=1950795681,tim=1327404119475172
STAT #139778252768168 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=7729 pr=0 pw=0 time=54134 us)'
STAT #139778252768168 id=2 cnt=1000000 pid=1 pos=1 obj=107338 op='TABLE ACCESS FULL TEST (cr=7729 pr=0 pw=0 time=75924 us cost=2093 size=0 card=1013983)'
Вот какое влияние оказывает трассировка на трассируемый процесс.
В частности, сделал такой самый простой тест, чтобы замерить скорость одного ядра:
set timing on
create table test (
Client_ID NUMBER,
NAME Varchar2(3),
FAMILY Varchar2(5),
DOLLARS NUMBER,
PASSWORD Varchar2(4),
BIRTHDAY DATE
) tablespace users;
insert into test
select
rownum ID,
DBMS_RANDOM.STRING ('A',3),
DBMS_RANDOM.STRING ('A',5),
DBMS_RANDOM.VALUE (0,1000),
DBMS_RANDOM.STRING ('X',4),
SYSDATE-DBMS_RANDOM.VALUE (6000,30000)
from dual connect by rownum <= 1000000;
select sum(bytes)/1048576 from user_segments where segment_name='TEST';
SUM(BYTES)/1048576
------------------
61
select count(*) from test;
select count(*) from test;
select count(*) from test;
select count(*) from test;
Табличка была целиком в памяти и время выполнения запроса стаблизировалось на цифре 10-20мс как на исходной так и второй системах:
SQL> set timing on
SQL> select count(*) from test;
select count(*) from test;
select count(*) from test;
COUNT(*)
----------
1000000
Elapsed: 00:00:00.03
SQL>
COUNT(*)
----------
1000000
Elapsed: 00:00:00.02
SQL>
COUNT(*)
----------
1000000
Elapsed: 00:00:00.01
Для того, чтобы повысить точность измерений решили включить трассировку и посмотреть время в микросекундах. После включения трассировки
alter session set events '10046 trace name context forever';
значения на обоих узлах стали 50-60мс:
PARSING IN CURSOR #139778252768168 len=25 dep=0 uid=84 oct=3 lid=84 tim=1327404119420870 hv=297253644 ad='2a99a2da8' sqlid='7b2twsn8vgfsc'
select count(*) from test
END OF STMT
PARSE #139778252768168:c=0,e=80,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1950795681,tim=1327404119420868
EXEC #139778252768168:c=0,e=30,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1950795681,tim=1327404119420975
FETCH #139778252768168:c=52992,e=54137,p=0,cr=7729,cu=1,mis=0,r=1,dep=0,og=1,plh=1950795681,tim=1327404119475172
STAT #139778252768168 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=7729 pr=0 pw=0 time=54134 us)'
STAT #139778252768168 id=2 cnt=1000000 pid=1 pos=1 obj=107338 op='TABLE ACCESS FULL TEST (cr=7729 pr=0 pw=0 time=75924 us cost=2093 size=0 card=1013983)'
Вот какое влияние оказывает трассировка на трассируемый процесс.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.