Re: oracle database memory access becomes slow after restart

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
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
> --
> http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l


Other related posts: