4 Replies Latest reply on May 16, 2012 1:34 PM by 937685

    AMM changes in

      We are doing some testing on a server with 32GB of RAM running Oracle Enterprise Linux v5.4 (2.6.18-194.el5). Our baseline test, using, had /dev/shm sized at 24GB and memory_target set at 24GB. This test had no problems and we saw no swapping at all (si/so in vmstat... monitoring our swap partition with iostat). We then wiped that installation and installed, set our parameters just like we did on, and imported our data. Now after we are running a reporting workload for about 10 minutes, the system starts swapping to the point that it thrashes the disk. I've been hunting through release notes and readmes and I can't seem to find any documented changes to AMM w/

      We see only about 12GB of data in /dev/shm, but we see 20+GB of data on the individual running oracle processes on Linux (using pmap).

      Why are the same AMM settings causing swapping on when they worked fine on Are there new parameters that we need to be modifying? We even toned down memory_target and memory_max_target to 18GB but we still end up swapping.
        • 1. Re: AMM changes in

          What happens if you don't set memory_target and switch back to using the SGA and PGA parameters?

          Worth a try to see if it's that parameter causing the issue.

          • 2. Re: AMM changes in
            I made the following changes:
            alter system set sga_max_size=12288M scope=spfile;
            alter system set sga_target=10240M scope=spfile;
            alter system set pga_aggregate_target=10240M scope=spfile;
            alter system reset memory_target scope=spfile;
            alter system reset memory_max_target scope=spfile;

            And restarted the instance. We do still run into the same problem. After about 10-20 minutes of reporting activity we start massively paging. I was watching nmon, iostat, and EM and have the following observations:

            94MB free RAM (w/out file system buffers... in other words, consumed active memory). The breakdown according to nmon is:
            Active: 24220MB
            Inactive: 462MB
            Mapped: 9285MB
            PageTables: 6644MB

            SGA allocation from EM:
            Shared Pool: 1568MB
            Buffer Cache: 8032MB
            Large Pool: 512MB
            Java Pool: 32MB
            Other: 96MB

            Current PGA allocated: 6414MB
            Maximum PGA Allocated: 17340MB

            So PGA seems to have grown to 1.7 times the amount I gave it as a target. This is likely the issue.
            • 3. Re: AMM changes in
              When you did the import, have all of the stats been set correctly? Perhaps there are tables without stats and it's ful scanning them into PGA to do the sorting parts of your reporting queries?

              I'd check that the import was OK and there were no errors.
              • 4. Re: AMM changes in
                The import finished successfully. I manually gathered stats and manually created all the indexes.