<div dir="ltr">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.<div><br></div><div>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?</div><div><br></div><div>- Jackie</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 13 Nov 2024 at 01:54, David Bowen <<a href="mailto:dbowenrci@gmail.com">dbowenrci@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Jackie,</div><div><br></div><div>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?<br></div><div><br></div><div>Thanks,</div><div>David<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 23, 2024 at 9:01 AM David Bowen <<a href="mailto:dbowenrci@gmail.com" target="_blank">dbowenrci@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>Hope this helps.</div><div>David<br><img src="cid:ii_m2lvtilj0" alt="server_memory_consumption.PNG" width="561" height="165"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 23, 2024 at 5:40 AM Jackie Ng <<a href="mailto:jumpinjackie@gmail.com" target="_blank">jumpinjackie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">(Copy of reply for the mailing list)<br><br>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.<div><br></div><div>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.<br><div><br></div><div>- Jackie</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 23 Oct 2024 at 06:16, David Bowen <<a href="mailto:dbowenrci@gmail.com" target="_blank">dbowenrci@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Jackie,</div><div><br></div><div>As far as we can tell, we're not using the KingFdoClass metadata table. Are there other memory leak tests being conducted?</div><div><br></div><div>David<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2024 at 5:51 PM Jackie Ng via mapguide-users <<a href="mailto:mapguide-users@lists.osgeo.org" target="_blank">mapguide-users@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Are your King Oracle feature sources using the KingFdoClass metadata table feature for cleaner class names?</div><div><br></div><div>If so, a leak was identified and plugged on that front.</div><div><br></div><div><a href="https://trac.osgeo.org/fdo/changeset/8279" target="_blank">https://trac.osgeo.org/fdo/changeset/8279</a><br></div><div><br></div><div>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.</div><div><br></div><div>- Jackie</div><div><br></div>You wrote:<div><br></div><div><pre style="color:rgb(0,0,0)">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
</pre><br></div></div>
_______________________________________________<br>
mapguide-users mailing list<br>
<a href="mailto:mapguide-users@lists.osgeo.org" target="_blank">mapguide-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapguide-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapguide-users</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><a href="http://themapguyde.blogspot.com" target="_blank">http://themapguyde.blogspot.com</a></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><a href="http://themapguyde.blogspot.com" target="_blank">http://themapguyde.blogspot.com</a></div></div></div></div>