[Glass] out of resources

[Norm Green]

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:

 1. ipcs -a to verify there are no IPC resources in use
 2. start the stone with startstone
 3. stop the stone with stopstone (or however you normally shutdown
    GemStone)
 4. 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140508/4ba44772/attachment.html>