Re: oracle database memory access becomes slow after restart
- From: Николаев Андрей Серапионович <Andrey.Nikolaev@xxxxxxxx>
- To: eagle.f@xxxxxxxxx
- Date: Sun, 19 Aug 2012 15:02:37 +0400 (MSK)
Hello!
This seems very similar to problem discussed in MOS Note
"Oracle database restart takes longer on high end systems running Oracle
Solaris[TM] [ID 1003483.1]"
I have met this issue several times when the SGA occupied almost all RAM.
The workaround is:
set pg_contig_disable=1 in /etc/system and reboot the Solaris.
Also decrease of SGA can help.
Best Regards.
Andrey Nikolaev
http://andreynikolaev.wordpress.com
_________
> From: Eagle Fan <eagle.f@xxxxxxxxx>
> To: oracle-l@xxxxxxxxxxxxx
> Sent: Monday, August 13, 2012 8:16 PM
> Subject: oracle database memory access becomes slow after restart
>
> Hi:
> We are seeing this problem several times on Sun T3-1 servers. We also see
> the problem 1~2 times on Sun T4-1 Server
>
> The server has 128G memory, database version is 11.2.0.2, 10.2.0.4 or
> 10.2.0.3. SGA is set as about 105G.
>
> After database restart, the access to memory becomes slow. It doesn't
> always
> happen, usually it happens on the servers which are up for a long time.
>
> For example: 11.2.0.2 version:
>
> Before restart:
>
> select count(*) from x$kslei;
>
> COUNT(*)
> ----------
> 1142
>
> *Elapsed: 00:00:06.57*
>
> After restart:
> select count(*) from x$kslei;
>
> COUNT(*)
> ----------
> 1142
>
> *Elapsed: 00:00:43.33*
>
> And we also see mutex, latch problem on the databases. I think that's the
> result of the slow memory access.
>
> If we reboot the server and then restart the database, it's back to
> normal.
>
> A possible reason is memory fragmentation. Here is the explanation from
> oracle support:
>
> *S**ince T3 has page size of 4 MB and Solaris kernel has single thread
> free
> memory coalescing thread, it takes 15-20 minutes to coalesce the free
> memory
> to create large contiguous free memory chunk after we shutdown the Oracle
> database. Since we immediately start bringing up the database before the
> free memory is coalesced, the next shared memory segment allocation is
> fragmented and thus causes more memory latency compared to 1 single large
> memory chunk. *
>
> The granule size is set as 128M in our database. The current solution is
> we
> do database failover instead of database restart. But it's more
> complicated
> and we need to make sure the inactive node is just rebooted before
> failover.
> Includes the inactivate nodes restart time, it takes much more time than
> database restart.
>
> Do you have the same problem on T3 server? How do you deal with it?
>
> Is there any way to check the OS memory fragmentation status?
>
> Thanks.
>
>
> --
> Eagle Fan
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
> --
> //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
