[mapguide-users] MGOS 4 Memory Leak

Jackie Ng jumpinjackie at gmail.com
Wed Nov 13 06:09:39 PST 2024


You could try to data crunch the access.log file, taking note of the
operations performed and their timestamps and see if there's any patterns
or correlations to your memory usage graph that can be inferred.

For example, when the memory usage spikes in your graph does it correspond
to a certain set of operations done in that time period in your access.log?

- Jackie

On Wed, 13 Nov 2024 at 01:54, David Bowen <dbowenrci at gmail.com> wrote:

> Hi Jackie,
>
> Any thoughts on the pattern shown in the graph provided in the previous
> email? Is there anything else, you could think of, that we could try to
> capture that would help diagnosing the issue?
>
> Thanks,
> David
>
> On Wed, Oct 23, 2024 at 9:01 AM David Bowen <dbowenrci at gmail.com> wrote:
>
>> Thanks Jackie. To provide some further insight into what the memory
>> consumption looks like, I've included a screengrab of the memory
>> consumption from the server that has the issue. Each day, memory is
>> consumed but not released until the MGOS services are restarted every night.
>>
>> Hope this helps.
>> David
>> [image: server_memory_consumption.PNG]
>>
>> On Wed, Oct 23, 2024 at 5:40 AM Jackie Ng <jumpinjackie at gmail.com> wrote:
>>
>>> (Copy of reply for the mailing list)
>>>
>>> The only tests are new provider test cases I've added exercising the
>>> provider under API usage scenarios of a regular FDO client application.
>>> This is my only avenue for finding possible leaks given the absence of
>>> solid and reproducible data and scenarios where leaks are definitely
>>> happening.
>>>
>>> I'm still fleshing out this provider test suite in the hopes of finding
>>> more leaks, but if I don't find any more after fleshing out this suite
>>> there's not much else I can do.
>>>
>>> - Jackie
>>>
>>> On Wed, 23 Oct 2024 at 06:16, David Bowen <dbowenrci at gmail.com> wrote:
>>>
>>>> Hi Jackie,
>>>>
>>>> As far as we can tell, we're not using the KingFdoClass metadata table.
>>>> Are there other memory leak tests being conducted?
>>>>
>>>> David
>>>>
>>>> On Thu, Oct 10, 2024 at 5:51 PM Jackie Ng via mapguide-users <
>>>> mapguide-users at lists.osgeo.org> wrote:
>>>>
>>>>> Are your King Oracle feature sources using the KingFdoClass metadata
>>>>> table feature for cleaner class names?
>>>>>
>>>>> If so, a leak was identified and plugged on that front.
>>>>>
>>>>> https://trac.osgeo.org/fdo/changeset/8279
>>>>>
>>>>> This was leaking on every DescribeSchema request where the connection
>>>>> was configured with the KingFdoClass metadata table. The more rows in that
>>>>> table, the more leaks per request.
>>>>>
>>>>> - Jackie
>>>>>
>>>>> You wrote:
>>>>>
>>>>> Forgot to mention that once the memory starts to be consumed it's a run
>>>>> away event, meaning that it doesn't seem to stop until the services fail
>>>>> and have to be restarted.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mapguide-users mailing list
>>>>> mapguide-users at lists.osgeo.org
>>>>> https://lists.osgeo.org/mailman/listinfo/mapguide-users
>>>>>
>>>>
>>>
>>> --
>>> http://themapguyde.blogspot.com
>>>
>>

-- 
http://themapguyde.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20241114/96e972a1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server_memory_consumption.PNG
Type: image/png
Size: 206653 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20241114/96e972a1/attachment.png>


More information about the mapguide-users mailing list