<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Shared memory issues in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850156#M274701</link>
    <description>There is only 1 map for all 32bit shared memory segments and each segment must be contiguous. If someone uses (the very bad) kill -9 command to terminate a program, old segments will be left behind. Also, the segments can't be moved so small segments can end up in the middle of an otherwise large chunk of memory.&lt;BR /&gt; &lt;BR /&gt;While you can experiment with ipcrm but you can easily destory an active segment as there are no locks to prevent removing a segment that is in use. A reboot will solve the problem, but if it comes back again, you'll need to look at memory windows to isolate certain applications so they have their own memory map. The program shminfo will show the actual map contents. Get a copy from:&lt;BR /&gt; &lt;BR /&gt;&lt;A href="ftp://hprc.external.hp.com/sysadmin/programs/shminfo" target="_blank"&gt;ftp://hprc.external.hp.com/sysadmin/programs/shminfo&lt;/A&gt;</description>
    <pubDate>Thu, 24 Aug 2006 17:40:51 GMT</pubDate>
    <dc:creator>Bill Hassell</dc:creator>
    <dc:date>2006-08-24T17:40:51Z</dc:date>
    <item>
      <title>Shared memory issues</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850154#M274699</link>
      <description>&lt;BR /&gt;I have some 32 bit applications (omniback, and others) that are reporting errors similar to the following:&lt;BR /&gt;&lt;BR /&gt;Cannot allocate shared memory pool (IPC Cannot Create Shared Memory Segment&lt;BR /&gt;System error: [12] Not enough space&lt;BR /&gt;&lt;BR /&gt;I can't see that I'm even close to the 2gb limit of shared memory for 32bit apps.  Here is some additional info.&lt;BR /&gt;&lt;BR /&gt;Kernel parms:&lt;BR /&gt;shmem 1&lt;BR /&gt;shmmax 0x7FFFFFFF&lt;BR /&gt;shmni  1024&lt;BR /&gt;shmseg 1024&lt;BR /&gt;&lt;BR /&gt;ipcs reports:&lt;BR /&gt;Shared Memory:&lt;BR /&gt;m       1024 0x33440e7e --rw-------      root       sys    2153624&lt;BR /&gt;m          1 0x4e0c0002 --rw-rw-rw-      root      root      61760&lt;BR /&gt;m          2 0x4130639c --rw-rw-rw-      root      root       8192&lt;BR /&gt;m      11267 0xffffffff --rw-r--rw-      root      root      22908&lt;BR /&gt;m          4 0x0c6629c9 --rw-r-----      root      root   18163120&lt;BR /&gt;m          5 0x06347849 --rw-rw-rw-      root      root      77384&lt;BR /&gt;m       7174 0x00000000 D-rw-------      root      root    2153624&lt;BR /&gt;m          7 0x6d440081 --rw-rw-rw-      root      root      47120&lt;BR /&gt;m       6152 0x00000000 D-rw-------       web       mis      46084&lt;BR /&gt;m       2057 0x5e280032 --rw-------      root      root        512&lt;BR /&gt;m      46090 0x52624801 --rw-rw----      root  informix  588267520&lt;BR /&gt;m      16395 0x52624802 --rw-rw-rw-      root  informix    1130496&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Any ideas what might be causing this?&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Huck</description>
      <pubDate>Thu, 24 Aug 2006 14:16:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850154#M274699</guid>
      <dc:creator>John Huck</dc:creator>
      <dc:date>2006-08-24T14:16:24Z</dc:date>
    </item>
    <item>
      <title>Re: Shared memory issues</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850155#M274700</link>
      <description>Hi:&lt;BR /&gt;&lt;BR /&gt;Fragmentation in the shared memory pool is one cause of this error.&lt;BR /&gt;&lt;BR /&gt;Regards!&lt;BR /&gt;&lt;BR /&gt;...JRF...</description>
      <pubDate>Thu, 24 Aug 2006 14:23:33 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850155#M274700</guid>
      <dc:creator>James R. Ferguson</dc:creator>
      <dc:date>2006-08-24T14:23:33Z</dc:date>
    </item>
    <item>
      <title>Re: Shared memory issues</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850156#M274701</link>
      <description>There is only 1 map for all 32bit shared memory segments and each segment must be contiguous. If someone uses (the very bad) kill -9 command to terminate a program, old segments will be left behind. Also, the segments can't be moved so small segments can end up in the middle of an otherwise large chunk of memory.&lt;BR /&gt; &lt;BR /&gt;While you can experiment with ipcrm but you can easily destory an active segment as there are no locks to prevent removing a segment that is in use. A reboot will solve the problem, but if it comes back again, you'll need to look at memory windows to isolate certain applications so they have their own memory map. The program shminfo will show the actual map contents. Get a copy from:&lt;BR /&gt; &lt;BR /&gt;&lt;A href="ftp://hprc.external.hp.com/sysadmin/programs/shminfo" target="_blank"&gt;ftp://hprc.external.hp.com/sysadmin/programs/shminfo&lt;/A&gt;</description>
      <pubDate>Thu, 24 Aug 2006 17:40:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850156#M274701</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2006-08-24T17:40:51Z</dc:date>
    </item>
    <item>
      <title>Re: Shared memory issues</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850157#M274702</link>
      <description>Thanks, I downloaded shminfo... but what am I looking at exactly? I've attached the output. I see a lot of OTHER and FREE lines, and a few that show SHMEM id=&lt;NUM&gt;. Nothing looks unusualy to me though and it doesn't look like there are even that many in use.&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;/NUM&gt;</description>
      <pubDate>Fri, 25 Aug 2006 10:43:03 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850157#M274702</guid>
      <dc:creator>John Huck</dc:creator>
      <dc:date>2006-08-25T10:43:03Z</dc:date>
    </item>
    <item>
      <title>Re: Shared memory issues</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850158#M274703</link>
      <description>You are looking for the free space. Unfortunately, you need to know how much RAM is being requested by Omniback and that depends on the size of the backup (all the filenames, sizes, paths, etc are stored in shared memory). If you find that the largest free area in the shminfo map is 200 megs, then that is your problem. You can stop Informix to free up some space, then run Omniback. Biut Manipulatintg the programs to fit into this (very restrictive) memory map is a big job. I would suggest creating a memory window to handle Omniback, perhaps another to handle Informix. Now each app sees an empty map with lots of empty space.</description>
      <pubDate>Fri, 25 Aug 2006 11:42:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/shared-memory-issues/m-p/3850158#M274703</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2006-08-25T11:42:58Z</dc:date>
    </item>
  </channel>
</rss>

