We got a brand new SUN T5140, and I managed to get my hands on it to run some tests.
Glenn Fawcett wrote some interresting entries in his blog about these so called chip multithreading CPUs. 2 should be mentioned here, as they had influence to this test-case:
Oracle's vision of multi-core processors on Solaris and Virtual CPUs effect on Oracle SGA allocations.
I wanted to know which parameters are derived from cpu_count.
A fresh installed and patched RDBMS 11.1.0.7.0 was my victim.
I used this script to get my data:
#!/usr/bin/ksh -x integer i=1 while ((i <= 128)); do print " $i "; echo "*.compatible='11.1.0.0.0' *.control_files='/appl/oracle/oradata/BERX2/control01.ctl','/appl/oracle/oradata/BERX2/control02.ctl','/appl/oracle/oradata/BERX2/control03 .ctl' *.db_block_size=8192 *.db_name='BERX2' *.MEMORY_MAX_TARGET=16G *.SGA_TARGET=13G *.cpu_count=$i"> initBERX2.ora echo "startup pfile='/appl/oracle/product/11.1.0.7/dbs/initBERX2.ora' ; insert into init_parameters select $i , a.ksppinm , b.ksppstvl , c.ksppstvl from x\$ksppi a, x\$ksppcv b, x\$ksppsv c where a.indx = b.indx and a.indx = c.indx; commit; select distinct(\"CPUs\") from init_parameters; shutdown; exit;"> cpus/doit$i.sql sqlplus "/ as sysdba" @cpus/doit$i.sql >cpus/log$i.log sleep 5 (( i = i + 1)); done
Afterwards I just had to get the interresting data out:
select /*+ PARALLEL */ i."CPUs" || ',' || i."Parameter" || ',' || i."InstanceValue" from init_parameters i where "Parameter" in (select distinct(i1."Parameter") from init_parameters i1, init_parameters i2 where i1."Parameter" = i2."Parameter" and i1."CPUs" <> i2."CPUs" and i1."InstanceValue" <> i2."InstanceValue" ) order by i."CPUs", i."Parameter";
and waste my time in excel creating the graphs:
(the whole spool output can be found here.)
I hope everyone enjoys these graphs. I'm sure there can be done much more tests, so if you have an interresting testcase which can be automated such as mine, feel free to contact me.
1 Kommentar:
Martin, thanks for putting these up! Very interesting indeed. For instance, the log_buffer increases exponentially? Wow. Wonder what the "good reason" for that is. Also, interesting to note that for every 1.8 blocks the db_cache decreases, the shared_pool goes up. Why would db_cache go down at all? Why does shared_pool go up?
We have observed similar behavior with the various writers, especially when you attempt to shut down your database. *grin* It takes a lot longer.
One last observation, it is interesting how certain parameters quickly hit a ceiling (or a floor), and that any further changes in CPU_COUNT is completely irrelevant.
Thanks again for putting this up; good stuff. I applaud your curiosity. *grin*
Kommentar veröffentlichen