[Glass] out of resources

[Otto Behrens]

Thanks. Not doing that explicitly, so it may be something else. Still looking...

On Thu, May 8, 2014 at 6:14 PM, Norm Green
<norm.green at gemtalksystems.com> wrote:
> Otto,
>
> Yes, this is unexpected.  You should only see stuck shared memory segments
> and semaphore arrays if you kill -9 the SPC monitor process.
>
> You should see if you can reproduce it:
>
> ipcs -a to verify there are no IPC resources in use
> start the stone with startstone
> stop the stone with stopstone (or however you normally shutdown GemStone)
> Repeat ipcs -a to see if the resources were released.  They should be.
>
> Norm
>
> On 5/8/14, 8:32, Otto Behrens wrote:
>
> Thanks for the response
>
> The way that we use shared memory resources, we have things setup so that
> the resources are deallocated when the last process detaches from the cache.
>
> So I would look around the system for rogue stoned, topaz or gem processes
> that may be hung/refusing to quit ... if you find some hanging around note
> their process ids and track down their log file...there should be
> information there as to why they are hung ...
>
> There are no rogue stoned, topaz, gem or shared cache monitor
> processes hanging around. The output from ipcs -m tells me that there
> are no processes attached. eg:
>
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
> 0x6a0180a5 819200     wonka      660        1059602432 0
> 0x16018585 1146881    wonka      660        1059602432 0
> 0x950180a5 163844     wonka      660        1059602432 0
> 0xfd0180a5 458757     wonka      660        1059602432 0
>
> The command
>
> ipcrm -m 819200
>
> frees up the memory instantly (the docs says that it frees up only
> after the last process detatches), which is consistent with the nattch
> count of 0.
>
> Another thing is if you 'kill -9' the shrpc monitor process, the shared
> memory segment will not be told to clean up when the last process detaches
> and the shared memore/semaphores will be left around.
>
> No shrpc process around
>
> While not recommended, it is "safe" to kill -9 the stoned process as a last
> resort, you will lose any transactions that are in progress and will need to
> restore from tranlogs on restart, but kill -9 on stoned should not corrupt
> the db  ... the shrpc monitor process is really the only process that it is
> not "safe" to use kill -9 on but even then the db will not be corrupted,
> like killing the stone, you will lose any transactions in progress AND you
> will leave shared memory resources around to be cleaned up manually ...
>
> AFAIK we are not killing processes. But we should have a very close
> look to make sure.
>
> What I can conclude from your response is that it is unexpected then
> that these resources are not freed up?
>
> Thanks
> Otto
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>