Excessive script time relaunch

James Sentman james at sentman.com
Fri Apr 24 08:52:18 EDT 2020


Ah well thats interesting and almost certainly the cause of the problem! 

It seems the json.isf is having a huge leak on your system. Mine has only been running for 2 days and it’s not terribly active getting only a few hits a minute from various things but it’s sitting there at 12.7mb for it’s real mem allocation and under the Memory tab of the activity monitor it only shows 3.6 as they don’t include loaded shared libraries with 0 bytes of compressed. I’ve never seen that one misbehave.

I need to narrow down the possibilities of where this is going wrong so I know where to add some logging or checking or just where to start looking for the problem since it’s not doing it here. If I can find the feature of it you’re using that I’m not then I’ll be able to duplicate it and fix it.

How active is your json server? What functions are you using with it? In my case I mostly have it receive pings from other systems to keep units on in XTension to let me know if they drop off line but it receives a few other values from various devices around the house and out in the world. Are you mostly having things control units via the built in stuff. Are you using it with a geofencing program? I use it for that as well but that only gets a few hits a day as we come and go, and few now days as we don’t come and go nearly as often. Are you using the feature that lets you pass json data to the ON script of a unit in XTension for processing something more complicated in a script? And are you using the feature that lets you send data back down that pipe from the script? I don’t use that on a regular basis so it’s possible that is where the issue is.

I’d love to know if just disabling and re-enabling the json interface solves the problem when it happens again or if the two things are unrelated. It’s unlikely as that is a really ludicrous amount of memory, I do think this is most likely the problem.

If I can’t figure out how to duplicate it here I can send a build with some functions to track it’s own allocations and various buffers and caches and make sure they are getting released as expected, or at least to report to the XTension log one way or the other so I can see from that. But it’s much easier to catch something if I have some idea which part of the program is actually causing it.


> On Apr 24, 2020, at 3:22 AM, ard jonker <ard.jonker at xs4all.nl> wrote:
> 
> Memory hog is json.isf with 4.92 GB (out of 4 GB physical, hmm, I thought the machine had 16?), a kernel task of 1.22 GB and XTension with 611 MB, then XTdb with 494 MB. In red, behind XTension is 'Application not responding'.

Thanks,
 James


James Sentman                       http://www.PlanetaryGear.org		http://MacHomeAutomation.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.machomeautomation.com/pipermail/xtensionlist/attachments/20200424/325fb3e7/attachment.html>


More information about the XTensionList mailing list