Hi.
Recently I was involved in performance troubleshooting of one quite expensive system
that had performance problems during business hours.
I’ll not provide all details, but just post some pictures that will show resource usage:
Oracle memory allocation:
Linux memory allocation
or from other side:
cat /proc/meminfo MemTotal: 98848220 kB MemFree: 75109972 kB Buffers: 597460 kB
so, we have Buffer Cache sized as 368MB/(96GB*1024)=0,37% of the Total Memory!!!
To be crystal clear I have to say that this system use ASM as a storage…
So, why do you think ASM performance is so BAD ?…
Just to note – it’s 11.2.0.3 based system.
Oleksandr.
PS: sometimes I think that problems like this are based on special DNA structure…
UPDATE(2012-OCT-18):
ok, some additional comments on this system – it’s 1/4 Exadata in which ASSM feature is used and pressure from shared pool on the buffer cache was so strong, that at the end buffer cache became 256MB. It was on first node only! On the second node buffer cache was about 3.6BG and it worked like a lightning! 
So, SGA target was increased to 50GB and buffer pool was set from the bottom at 40GB limit.
ASM instance memory allocation use Huge Pages ?
Comment by Andrey — 08.09.2012 @ 11:11 |
Andrey,
grep Huge /proc/meminfo
HugePages_Total: 4100
HugePages_Free: 421
HugePages_Rsvd: 415
Hugepagesize: 2048 kB
DB
use_large_pages string TRUE
ASM
use_large_pages string ONLY
Comment by odenysenko — 10.09.2012 @ 11:37 |
Из той же серии – вопрос (реальный) от разработчика: какая разница, сколько джобов я запущу одновременно, 10 или 1000? Ведь они все равно в очередь все встанут, и по очереди выполнятся…
Comment by Juri — 13.09.2012 @ 06:58 |
Юра,
вопрос от разработчика практически правомерный,
потому как возможна ситуация когда так и будет отрабатывать
просто такое не всегда бывает, а разработчиков это уже не беспокоит…
на ситуацию с джобами похожа другая:
cpu_count integer 4
parallel_max_servers integer 160
и никого не волнует что снизу лежит один 5-й рейт из 3-х дисков…
Oleksandr
Comment by odenysenko — 13.09.2012 @ 09:42 |