As mentioned before, this is a Sun T5440. So even though we have 256
"virtual" cpus, the database cpu_count is set to 3 for various reasons (on
our Dev box, we have so many databases we had to scale back memory
consumption, so we standardized cpu_count on all non-Prod environments).
No, 100 is not very realistic, but from my point of view, I was just trying
to find bottlenecks. For the most part it works beautifully. :)
BANIMP_SQL > show parameter parallel_
NAME TYPE VALUE
------------------------------------ ----------------
------------------------------
fast_start_parallel_rollback string LOW
parallel_adaptive_multi_user boolean TRUE
parallel_automatic_tuning boolean FALSE
parallel_degree_limit string CPU
parallel_degree_policy string MANUAL
parallel_execution_message_size integer 16384
parallel_force_local boolean FALSE
parallel_instance_group string
parallel_io_cap_enabled boolean FALSE
parallel_max_servers integer 3600
parallel_min_percent integer 0
parallel_min_servers integer 0
parallel_min_time_threshold string AUTO
parallel_server boolean FALSE
parallel_server_instances integer 1
parallel_servers_target integer 8
parallel_threads_per_cpu integer 2
recovery_parallelism integer 0
On Thu, Jul 16, 2015 at 2:18 AM, Stefan Koehler <contact@xxxxxxxx> wrote:
Hi Charles,
yes ALL means all ;-))
This sounds like some kind of adaptive PX features are kicking in. Can you
please post your "parallel_*" (show parameter parallel_) parameters?
Unfortunately my leased root server is down, so i can not build up a valid
test cases with 100 PX servers on my notebook, but just out of curiosity -
how many CPUs do you have in your database server? Is 100 a meaningful PX
request anyway?
Thanks.
Best Regards
Stefan Koehler
Freelance Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK