Are my netTalk Self Service Apps causing memory leak

[Richard I]

Bill-
Guess what !!
"Sophos has recently identified an issue where, in certain environments, a memory leak can occur in the HTTP proxy on the UTM. A number of causes have been identified and these have been fixed in the v9.005 release, which will improve the stability of the HTTP proxy for many affected customers. However, we have not yet identified and fixed all possible causes, but investigating and fixing these is a high priority."

Cheers
R

[bshields]

Great news!

[Bruce]

Richard,

You are reporting that the overall usage of memory on the machine is climbing.
but Task Manager shows you which processes in the machine are using what memory.
So from there it should be simple to understand which process is consuming the memory.

If it's the web server, then obviously one has to look at that - if it's another process then one loos at that and so on.

cheers
Bruce

[urayoan]

Hi Bruce:
  In my case, when this happens (and lately is very often), happens to the web server process. Lots of CPU and RAM consumed and even sits the server.

In my case (after reading the posts here), i did remove the option of use more than 4gb of ram and resource usage is better, but i don't know if this is gonna impact my clients at the long run.

Even one of my test was in a server without any Antivirus software installed (new server deployed for the server), and before the 4gm checkmark removed it doesn't even let the server work. OS was Windows Server 2016

All the test was using NetTalk ver. 10.19

[Bruce]

hi Ura,

There are no known leaks in the NetTalk code, but that of course does not prove they are not there. There have been a spate of memory leak reports lately, but so far none have turned out to be NetTalk code - usually it's something in the app itself.

There is a rather serious leak in the Clarion ODBC driver, introduced in the C10 build 12799.

It's been reported to SV (PTSS 42658) but despite a long thread on the newsgroups SV have been very silent on the issue. Feel free to lobby them about that if you like... <g>.

I think I need to describe it as a "memory leak in H5 apps" before they'll get around to fixing it <g>.

cheers
Bruce

[urayoan]

Cool. Thank God i did not use ODBC nor H5 

Bruce, any suggestions to track or pinpoint possible resource usage problems?

[Bruce]

>> any suggestions to track or pinpoint possible resource usage problems?

Finding memory leaks is tricky. Programs can "use" memory and that's ok. A "leak" are cases where it used memory, but ended up with stuff stored in memory that it won't use again.

It's like you mom coming to your room as a teenager and deciding which stuff you have is valuable to you, and which you'll never use again. To her it's all just "stuff".

TaskManager can help to keep an eye on memory usage. You can't be "exact" about it, but you can keep an eye on it to spot trends.

The WebStrain client app is also useful for being able to repeat the same calls over and over thousands of times. This helps isolate which calls are leaking memory. (Just be sure to think about session cookies - a web stress tester that doesn't preserve the session will use memory on each call - which will only come back when the session is deleted.)

Ideally you want to find some call which when called a zillion times causes the me usage in the app to grow. Maybe it's a page with some embed code, or a report, or a web service method. If you can narrow it down to 1 call then that's a good start.

Then you start commenting out embed code in that procedure and so on.

It's a long and tedious process, and ultimately helps if you have a bit of luck. It took Chuck weeks to narrow the cause down to the ODBC driver.

Cheers
Bruce