gboudreau
High memory usage
Chrome's and the system's task manager shows that SabConnect++ is having an unusually high memory usage.
At the moment ProcessExplorer is showing it using 439,000K and Chrome's task manager shows 134,440K of Memory, 12,740K of Shared memory and 439,000K of Private memory.
My sabnzbd is online but sabconnect++ apparently can't reach it, if I don't open sab on a tab and enter the log in credentials.
I'm on Windows 7, 32bits running the latest version of Chrome.
Please let me know if you need additional information. Here's a screenshot of the task managers: http://pbrd.co/131a1AP
On the contrary here, Chrome (and sabconnect++) have been running for 13 days without any such difficulty, with the extension using 48KB of private memory. It is happily working and moaning where appropriate in an environment that has deliberately simulates network loss and latency.
Can you take and provide a heap snapshot from the extension?
- Right click on the extension icon and select "Inspect Pop-up"
- Select the "Profiles" tab then "Take Heap Snapshot" and start it
- In the left navigation, right click on the "Snapshot X" and select "Save Heap Snapshot"
Save and provide this as appropriate.
Depending on what is consuming memory, there is a risk it will contain sensitive information such as server URLs, usernames, passwords, API keys and recent sab download entries. Please be this in mind when choosing a mechanism to share the file.
Hi. After reporting the issue, I restarted the machine and only now I was able to reproduce it. My Chrome was left open in idle or with minimal usage for a some days now. The extension isn't connected to my remote sabnzbd because I have authentication+https set and I still haven't opened a sabnzbd window on chrome to enter the credentials.
The problem is... when I right-click the extension icon I don't have an "Inspect Pop-up" option.
Here's a screenshot: http://pbrd.co/12G6QIp
My bad,
From the Chrome tools menu, select tools and then extensions.
Ensure "Developer mode" is ticked. This will allow the inspection option in the menu.
If properly setup, auth should not be an issue. However HTTPS, do you have to accept a security exception when you visit the page?
Yes, I do. I'm using the default certificate configuration on Sabnzbd+ and I get the dark red page everytime I open a new Sabnzbd tab. Here's the snapshot: https://www.dropbox.com/s/mpzlscrzrwtempz/Heap-20130703T101742.heapsnapshot
Thanks,
The details clearly show ~100,000 XMLHttpRequest objects. Each using around 116 bytes, but will hold more than that outside of Javascript.
In comparison, I can't any clustered on mine and the same top level object is using 480KB to your 11MB.
Unfortunately, there are a number of possible causes here. The two common ones.
1: Connections are still open between client and server. Take a look at the following and see if it helps you see if this is the case https://code.google.com/p/sabconnectplusplus/issues/detail?id=139
2: The fact it's a self-signed cert means the code has no mechanism to work around this. XMLHttpRequest object cannot handle these situations as this is a deep rooted security implementation in Chrome.
For number 1, not much you can do other than avoid SSL, maybe periodically restart SAB.
For 2, you could create your own self-signed CA cert and then a self-signed cert from this, installing the CA onto your machine. This method has worked for me in other apps in the past, however, I have never done this with Chrome, so I don't know if it will be willing to accept a self-signed CA given the very same security that could be the cause.
Step one though, bounce your SAB process and free any part open connections.
In trying to test this, I have come to learn Chrome is a bag of.... expletives.
It would appear I cannot use the Dev console to debug any XMLHttpRequest objects. This means I cannot, other than adding listeners, which from the looks of things wont be getting fired at the all important time anyway.
Otherwise, it's going to take some time to switch to synchronous calls and force a response from a locked call.
Would be really handy to find out the output from netstat though and see if you have thousands of pending closure connections.
Again, the quickest way here is going to be a full self-signed CA and self-signed Cert, if Chrome will allow it.
It will. It's documented on the wiki: https://code.google.com/p/sabconnectplusplus/wiki/SSLConnection (Which I still need to move to Github...)
