deleting user and memory

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

deleting user and memory

NorbertHartl
Hi,

I did some tests installing seaside 3 in my image under different users. Most of them weren't successful so I deleted those users. If I'm not misled I could not see memory being freed by deleting just the user. Is there anything else to do to cleanup?

thanks,

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

Dale Henrichs
Norbert Hartl wrote:
> Hi,
>
> I did some tests installing seaside 3 in my image under different users. Most of them weren't successful so I deleted those users. If I'm not misled I could not see memory being freed by deleting just the user. Is there anything else to do to cleanup?
>
> thanks,
>
> Norbert
>

Norbert,

I would assume as you did that things would be cleaned up ... what kinds
or objects are you seeing that are hanging around?

Dale
Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

NorbertHartl

On 20.07.2010, at 18:28, Dale Henrichs wrote:

> Norbert Hartl wrote:
>> Hi,
>> I did some tests installing seaside 3 in my image under different users. Most of them weren't successful so I deleted those users. If I'm not misled I could not see memory being freed by deleting just the user. Is there anything else to do to cleanup?
>> thanks,
>> Norbert
>
> Norbert,
>
> I would assume as you did that things would be cleaned up ... what kinds or objects are you seeing that are hanging around?
>
I just noticed the different object count the MFC gives. It went from 336xxxx live objects to 442xxxx while testing. Removing the user and MFC afterwards did not change the live objects count. That's why I am asking. I don't have detailled information about it.

But you state that removing the user from AllUsers should be sufficient? Then I try to figure out anything ;)

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

Dale Henrichs
Norbert Hartl wrote:

> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> Hi,
>>> I did some tests installing seaside 3 in my image under different users. Most of them weren't successful so I deleted those users. If I'm not misled I could not see memory being freed by deleting just the user. Is there anything else to do to cleanup?
>>> thanks,
>>> Norbert
>> Norbert,
>>
>> I would assume as you did that things would be cleaned up ... what kinds or objects are you seeing that are hanging around?
>>
> I just noticed the different object count the MFC gives. It went from 336xxxx live objects to 442xxxx while testing. Removing the user and MFC afterwards did not change the live objects count. That's why I am asking. I don't have detailled information about it.
>
> But you state that removing the user from AllUsers should be sufficient? Then I try to figure out anything ;)
>
> Norbert
>

Norbert,

I _assume_ that it should be sufficient ... I'm not completely familiar
with the ins and outs of removing users, so there could be bugs or extra
steps required.

Dale
Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

NorbertHartl
Dale,

I investigated it a bit further. My feelings were right the users are indeed still present. I looked at the code of creating a user and removing. To me it appears that if you delete a user from the AllUsers list the segment is not deleted as well. And the segment still holds a reference to user (owner). I scanned a lot of the classes but I couldn't find anything that lets me delete a segment. I think it is an action that should be taken carefully ;) Anyway the creation of one is inside a primitive. So I guess there is less I can do. Right?

Norbert


On 20.07.2010, at 19:00, Dale Henrichs wrote:

> Norbert Hartl wrote:
>> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>>> Norbert Hartl wrote:
>>>> Hi,
>>>> I did some tests installing seaside 3 in my image under different users. Most of them weren't successful so I deleted those users. If I'm not misled I could not see memory being freed by deleting just the user. Is there anything else to do to cleanup?
>>>> thanks,
>>>> Norbert
>>> Norbert,
>>>
>>> I would assume as you did that things would be cleaned up ... what kinds or objects are you seeing that are hanging around?
>>>
>> I just noticed the different object count the MFC gives. It went from 336xxxx live objects to 442xxxx while testing. Removing the user and MFC afterwards did not change the live objects count. That's why I am asking. I don't have detailled information about it. But you state that removing the user from AllUsers should be sufficient? Then I try to figure out anything ;) Norbert
>
> Norbert,
>
> I _assume_ that it should be sufficient ... I'm not completely familiar with the ins and outs of removing users, so there could be bugs or extra steps required.
>
> Dale

Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

Dale Henrichs
Norbert Hartl wrote:

> Dale,
>
> I investigated it a bit further. My feelings were right the users are
> indeed still present. I looked at the code of creating a user and
> removing. To me it appears that if you delete a user from the
> AllUsers list the segment is not deleted as well. And the segment
> still holds a reference to user (owner). I scanned a lot of the
> classes but I couldn't find anything that lets me delete a segment. I
> think it is an action that should be taken carefully ;) Anyway the
> creation of one is inside a primitive. So I guess there is less I can
> do. Right?
>
> Norbert
>
>
> On 20.07.2010, at 19:00, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>>>> Norbert Hartl wrote:
>>>>> Hi, I did some tests installing seaside 3 in my image under
>>>>> different users. Most of them weren't successful so I deleted
>>>>> those users. If I'm not misled I could not see memory being
>>>>> freed by deleting just the user. Is there anything else to do
>>>>> to cleanup? thanks, Norbert
>>>> Norbert,
>>>>
>>>> I would assume as you did that things would be cleaned up ...
>>>> what kinds or objects are you seeing that are hanging around?
>>>>
>>> I just noticed the different object count the MFC gives. It went
>>> from 336xxxx live objects to 442xxxx while testing. Removing the
>>> user and MFC afterwards did not change the live objects count.
>>> That's why I am asking. I don't have detailled information about
>>> it. But you state that removing the user from AllUsers should be
>>> sufficient? Then I try to figure out anything ;) Norbert
>> Norbert,
>>
>> I _assume_ that it should be sufficient ... I'm not completely
>> familiar with the ins and outs of removing users, so there could be
>> bugs or extra steps required.
>>
>> Dale
>

Norbert,

I've submitted Issue 151
(http://code.google.com/p/glassdb/issues/detail?id=151) to track the
problem. I looked in the System Admin Guide and noted that there is not
guidance for removing a user from topaz. There are instructions for
using the GBS tool, but the details of what the GBS tools does during
user removal isn't described...

Dale
Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

Dale Henrichs
Norbert,

The GBS remove user algorithm, installs another user into the owner slot
  of the segment, so you should be able to install DataCurator as the
owner of the segment thereby freeing up all of the objects owned by that
  user...

Dale

Dale Henrichs wrote:

> Norbert Hartl wrote:
>> Dale,
>>
>> I investigated it a bit further. My feelings were right the users are
>> indeed still present. I looked at the code of creating a user and
>> removing. To me it appears that if you delete a user from the
>> AllUsers list the segment is not deleted as well. And the segment
>> still holds a reference to user (owner). I scanned a lot of the
>> classes but I couldn't find anything that lets me delete a segment. I
>> think it is an action that should be taken carefully ;) Anyway the
>> creation of one is inside a primitive. So I guess there is less I can
>> do. Right?
>>
>> Norbert
>>
>>
>> On 20.07.2010, at 19:00, Dale Henrichs wrote:
>>
>>> Norbert Hartl wrote:
>>>> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>>>>> Norbert Hartl wrote:
>>>>>> Hi, I did some tests installing seaside 3 in my image under
>>>>>> different users. Most of them weren't successful so I deleted
>>>>>> those users. If I'm not misled I could not see memory being
>>>>>> freed by deleting just the user. Is there anything else to do
>>>>>> to cleanup? thanks, Norbert
>>>>> Norbert,
>>>>>
>>>>> I would assume as you did that things would be cleaned up ...
>>>>> what kinds or objects are you seeing that are hanging around?
>>>>>
>>>> I just noticed the different object count the MFC gives. It went
>>>> from 336xxxx live objects to 442xxxx while testing. Removing the
>>>> user and MFC afterwards did not change the live objects count.
>>>> That's why I am asking. I don't have detailled information about
>>>> it. But you state that removing the user from AllUsers should be
>>>> sufficient? Then I try to figure out anything ;) Norbert
>>> Norbert,
>>>
>>> I _assume_ that it should be sufficient ... I'm not completely
>>> familiar with the ins and outs of removing users, so there could be
>>> bugs or extra steps required.
>>>
>>> Dale
>
> Norbert,
>
> I've submitted Issue 151
> (http://code.google.com/p/glassdb/issues/detail?id=151) to track the
> problem. I looked in the System Admin Guide and noted that there is not
> guidance for removing a user from topaz. There are instructions for
> using the GBS tool, but the details of what the GBS tools does during
> user removal isn't described...
>
> Dale

Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

NorbertHartl
Dale,

does this mean you can only increase the number of segments? And a segment is not that much data? Is there a method the create a new user without creating a new segment? I could then install DataCurator first to free memory and reallocate the segment to a new user afterwards. Would that be possible?

thanks,

Norbert

On 29.07.2010, at 20:39, Dale Henrichs wrote:

> Norbert,
>
> The GBS remove user algorithm, installs another user into the owner slot  of the segment, so you should be able to install DataCurator as the owner of the segment thereby freeing up all of the objects owned by that  user...
>
> Dale
>
> Dale Henrichs wrote:
>> Norbert Hartl wrote:
>>> Dale,
>>>
>>> I investigated it a bit further. My feelings were right the users are
>>> indeed still present. I looked at the code of creating a user and
>>> removing. To me it appears that if you delete a user from the
>>> AllUsers list the segment is not deleted as well. And the segment
>>> still holds a reference to user (owner). I scanned a lot of the
>>> classes but I couldn't find anything that lets me delete a segment. I
>>> think it is an action that should be taken carefully ;) Anyway the
>>> creation of one is inside a primitive. So I guess there is less I can
>>> do. Right?
>>>
>>> Norbert
>>>
>>>
>>> On 20.07.2010, at 19:00, Dale Henrichs wrote:
>>>
>>>> Norbert Hartl wrote:
>>>>> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>>>>>> Norbert Hartl wrote:
>>>>>>> Hi, I did some tests installing seaside 3 in my image under
>>>>>>> different users. Most of them weren't successful so I deleted
>>>>>>> those users. If I'm not misled I could not see memory being
>>>>>>> freed by deleting just the user. Is there anything else to do
>>>>>>> to cleanup? thanks, Norbert
>>>>>> Norbert,
>>>>>>
>>>>>> I would assume as you did that things would be cleaned up ...
>>>>>> what kinds or objects are you seeing that are hanging around?
>>>>>>
>>>>> I just noticed the different object count the MFC gives. It went
>>>>> from 336xxxx live objects to 442xxxx while testing. Removing the
>>>>> user and MFC afterwards did not change the live objects count.
>>>>> That's why I am asking. I don't have detailled information about
>>>>> it. But you state that removing the user from AllUsers should be
>>>>> sufficient? Then I try to figure out anything ;) Norbert
>>>> Norbert,
>>>>
>>>> I _assume_ that it should be sufficient ... I'm not completely
>>>> familiar with the ins and outs of removing users, so there could be
>>>> bugs or extra steps required.
>>>>
>>>> Dale
>> Norbert,
>> I've submitted Issue 151 (http://code.google.com/p/glassdb/issues/detail?id=151) to track the problem. I looked in the System Admin Guide and noted that there is not guidance for removing a user from topaz. There are instructions for using the GBS tool, but the details of what the GBS tools does during user removal isn't described...
>> Dale
>

Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

Dale Henrichs
Norbert Hartl wrote:

> Dale,
>
> does this mean you can only increase the number of segments? And a
> segment is not that much data? Is there a method the create a new
> user without creating a new segment? I could then install DataCurator
> first to free memory and reallocate the segment to a new user
> afterwards. Would that be possible?
>
> thanks,
>
> Norbert
>

Segments are a limited resource. It is possible to create a new user
without allocating a segment for the new user (see the user creation
protocol), but the default is to create a new segment when a new user is
created.

This came up in our discussion of the bug this morning ... the default
_should_ be that no segment is created unless you explicitly want one
... I think that you should be able to reuse the segment as long as you
realize that until the objects associated with the old segment owner
will be accessible to the new segment owner until they are garbage
collected...

You can reuse/share a segment for a new user by passing in the segment
as the defaultSegment arg.

nil is a valid value for the defaultSegment. The nil segment is readable
and writable by the world ...

Dale
Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

NorbertHartl

On 29.07.2010, at 21:48, Dale Henrichs wrote:

> Norbert Hartl wrote:
>> Dale,
>> does this mean you can only increase the number of segments? And a
>> segment is not that much data? Is there a method the create a new
>> user without creating a new segment? I could then install DataCurator
>> first to free memory and reallocate the segment to a new user
>> afterwards. Would that be possible?
>> thanks,
>> Norbert
>
> Segments are a limited resource. It is possible to create a new user without allocating a segment for the new user (see the user creation protocol), but the default is to create a new segment when a new user is created.
>
> This came up in our discussion of the bug this morning ... the default _should_ be that no segment is created unless you explicitly want one ... I think that you should be able to reuse the segment as long as you realize that until the objects associated with the old segment owner will be accessible to the new segment owner until they are garbage collected...
>
> You can reuse/share a segment for a new user by passing in the segment as the defaultSegment arg.
>
> nil is a valid value for the defaultSegment. The nil segment is readable and writable by the world ...
>
Ok, i resurrected a segment by doing

| segment user |
System abortTransaction.
segment := Segment allInstances detect: [:each| each owner userId = 'oldUserId'].
user := AllUsers addNewUserWithId: 'newUserId' password: 'xxx' defaultSegment: nil.
segment owner: user.
user defaultSegment: segment.

Assigning the segment on creation time of the user does not work. I think gemstone ist complaining about the mismatch of the user created and the owner of the segment. Doing it in separate steps works ok.

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

Dale Henrichs
Norbert Hartl wrote:

> On 29.07.2010, at 21:48, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> Dale,
>>> does this mean you can only increase the number of segments? And a
>>> segment is not that much data? Is there a method the create a new
>>> user without creating a new segment? I could then install DataCurator
>>> first to free memory and reallocate the segment to a new user
>>> afterwards. Would that be possible?
>>> thanks,
>>> Norbert
>> Segments are a limited resource. It is possible to create a new user without allocating a segment for the new user (see the user creation protocol), but the default is to create a new segment when a new user is created.
>>
>> This came up in our discussion of the bug this morning ... the default _should_ be that no segment is created unless you explicitly want one ... I think that you should be able to reuse the segment as long as you realize that until the objects associated with the old segment owner will be accessible to the new segment owner until they are garbage collected...
>>
>> You can reuse/share a segment for a new user by passing in the segment as the defaultSegment arg.
>>
>> nil is a valid value for the defaultSegment. The nil segment is readable and writable by the world ...
>>
> Ok, i resurrected a segment by doing
>
> | segment user |
> System abortTransaction.
> segment := Segment allInstances detect: [:each| each owner userId = 'oldUserId'].
> user := AllUsers addNewUserWithId: 'newUserId' password: 'xxx' defaultSegment: nil.
> segment owner: user.
> user defaultSegment: segment.
>
> Assigning the segment on creation time of the user does not work. I think gemstone ist complaining about the mismatch of the user created and the owner of the segment. Doing it in separate steps works ok.
>
> Norbert
>
>

Norbert,

That's good to know ... as a result of your reports here, we'll be
cleaning up our new user/remove user procedures without relying on the
GBS implementation.

Dale
Reply | Threaded
Open this post in threaded view
|

Re: deleting user and memory

NorbertHartl

On 30.07.2010, at 18:25, Dale Henrichs wrote:

> Norbert Hartl wrote:
>> On 29.07.2010, at 21:48, Dale Henrichs wrote:
>>> Norbert Hartl wrote:
>>>> Dale,
>>>> does this mean you can only increase the number of segments? And a
>>>> segment is not that much data? Is there a method the create a new
>>>> user without creating a new segment? I could then install DataCurator
>>>> first to free memory and reallocate the segment to a new user
>>>> afterwards. Would that be possible?
>>>> thanks,
>>>> Norbert
>>> Segments are a limited resource. It is possible to create a new user without allocating a segment for the new user (see the user creation protocol), but the default is to create a new segment when a new user is created.
>>>
>>> This came up in our discussion of the bug this morning ... the default _should_ be that no segment is created unless you explicitly want one ... I think that you should be able to reuse the segment as long as you realize that until the objects associated with the old segment owner will be accessible to the new segment owner until they are garbage collected...
>>>
>>> You can reuse/share a segment for a new user by passing in the segment as the defaultSegment arg.
>>>
>>> nil is a valid value for the defaultSegment. The nil segment is readable and writable by the world ...
>>>
>> Ok, i resurrected a segment by doing
>> | segment user |
>> System abortTransaction.
>> segment := Segment allInstances detect: [:each| each owner userId = 'oldUserId'].
>> user := AllUsers addNewUserWithId: 'newUserId' password: 'xxx' defaultSegment: nil.
>> segment owner: user.
>> user defaultSegment: segment.
>> Assigning the segment on creation time of the user does not work. I think gemstone ist complaining about the mismatch of the user created and the owner of the segment. Doing it in separate steps works ok.
>> Norbert
>
> Norbert,
>
> That's good to know ... as a result of your reports here, we'll be cleaning up our new user/remove user procedures without relying on the GBS implementation.
>
That's great. In the meantime I can confirm that it was the reference from segment that kept a UserProfile from being garbage collected. I assigned a new user to an existing profile like shown above. At the same time the segment is assigned to the new user the old UserProfile is not connected anymore. A markForCollection and a scan for allInstances before and afterwards confirmed it. Dale, thanks, I know I was lucky the instance has been collected shortly after the MFC ;)

Norbert