4 Replies Latest reply: Sep 27, 2012 8:41 AM by Dude! RSS

    shmmax on linux not configured properly

    user12194321
      HI,

      Envirnomet details:

      lsb_release -a
      LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
      Distributor ID: RedHatEnterpriseServer
      Description: Red Hat Enterprise Linux Server release 5.8 (Tikanga)
      Release: 5.8
      Codename: Tikanga

      sqlplus -version

      SQL*Plus: Release 11.2.0.2.0 Production

      we have set shmmax=5g but in ipcs -m only 4096 is allocated

      $ cat /etc/sysctl.conf | grep shm
      #kernel.shmmax = 68719476736
      #kernel.shmall = 4294967296
      kernel.shmall = 4194304
      kernel.shmmax = 5368709120
      kernel.shmmni = 4096
      $ ipcs -m

      ------ Shared Memory Segments --------
      key shmid owner perms bytes nattch status
      0x00000000 4784129 root 644 80 2
      0x00000000 4816899 root 644 16384 2
      0x00000000 4849668 root 644 280 2
      0x00000000 4947974 oracle 660 4096 0
      0x00000000 4980743 oracle 660 4096 0
      0x1bc42f08 5013512 oracle 660 4096 0

      why it is only allocated 4mb and we have given maxsize as 5gb

      anything we missed ?

      FYI after setting shmmax we have rebooted the server

      Thanks
        • 1. Re: shmmax on linux not configured properly
          Osama_Mustafa
          Please Read MOs
          Maximum SHMMAX values for Linux x86 and x86-64 [ID 567506.1]

          you will find your answer there
          • 2. Re: shmmax on linux not configured properly
            user12194321
            Hi,

            I have read the docs but we have aroung 15gigs of physical memory

            $ cat /proc/meminfo
            MemTotal: 15401920 kB
            MemFree: 935976 kB
            Buffers: 472468 kB
            Cached: 11720080 kB
            SwapCached: 741664 kB
            Active: 6463324 kB
            Inactive: 7610368 kB
            HighTotal: 0 kB
            HighFree: 0 kB
            LowTotal: 15401920 kB
            LowFree: 935976 kB
            SwapTotal: 31744432 kB
            SwapFree: 31002768 kB
            Dirty: 160 kB
            Writeback: 0 kB
            AnonPages: 1139468 kB
            Mapped: 1249400 kB
            Slab: 269204 kB
            PageTables: 71164 kB
            NFS_Unstable: 0 kB
            Bounce: 0 kB
            CommitLimit: 39445392 kB
            Committed_AS: 5255764 kB
            VmallocTotal: 34359738367 kB
            VmallocUsed: 278524 kB
            VmallocChunk: 34359459431 kB
            HugePages_Total: 0
            HugePages_Free: 0
            HugePages_Rsvd: 0
            Hugepagesize: 2048 kB

            why only 4096 bytes allocated it shoule be more right for the oracle process ?

            Let me know if i am wrong

            Thanks
            • 3. Re: shmmax on linux not configured properly
              user12194321
              Any inputs please

              Thanks
              • 4. Re: shmmax on linux not configured properly
                Dude!
                Setting the kernel.shmmax parameter does not reserve or pre-allcoate shared memory to a process. SHMMAX is a safeguard parameter that sets the upper limit of how much shared memory a process can allocate when requested.

                There are two types of shared memory: /dev/shm and kernel hugepages.

                Your output is typical for a 11g database configuration that uses Automatic Shared Memory (AMM). You won't see the memory allocation for processes using /dev/shm in ipcs. Use df instead. For instance:

                POSIX /dev/shm (Oracle AMM):

                <pre>
                grep Huge /proc/meminfo
                HugePages_Total: 0
                HugePages_Free: 0
                HugePages_Rsvd: 0
                HugePages_Surp: 0
                Hugepagesize: 2048 kB

                # ipcs -m

                - Shared Memory Segments -
                key shmid owner perms bytes nattch status
                0x7400efd5 1703936 root 600 4 0
                0x00000000 2031617 root 644 80 2
                0x00000000 2064386 root 644 16384 2
                0x00000000 2097155 root 644 280 2
                0x00000000 2129924 gdm 600 393216 2 dest
                0x42e38fd0 2195461 oracle 660 4096 0

                # df -h | grep shm
                tmpfs 2.0G 1023M 956M 52% /dev/shm
                </pre>

                Kernel Hugepages:

                <pre>
                # grep Huge /proc/meminfo
                HugePages_Total: 1029
                HugePages_Free: 767
                HugePages_Rsvd: 107
                HugePages_Surp: 0
                Hugepagesize: 2048 kB

                # ipcs -m

                - Shared Memory Segments -
                key shmid owner perms bytes nattch status
                0x7400f580 1802240 root 600 4 0
                0x00000000 2097153 root 644 80 2
                0x00000000 2129922 root 644 16384 2
                0x00000000 2162691 root 644 280 2
                0x00000000 2195460 gdm 600 393216 2 dest
                0x350d8a94 2260997 oracle 660 4096 0
                0x071b99cc 2326534 oracle 660 773849088 31

                # df -h | grep shm
                tmpfs 2.0G 176M 1.8G 9% /dev/shm

                </pre>

                Please note that for performance reasons, kernel hugepages is preferred for any database that uses more than 4 GB of RAM. POSIX compliant shared memory /dev/shm memory uses standard 4 KB memory pages, whereas Hugepages uses 2 MB, which results in a much smaller page table, saving physical memory and better TLB performance (cache used for storing virtual-to-physical mapping information).

                Edited by: Dude on Sep 27, 2012 6:40 AM