Activity Monitor - Google Chrome taking a lot of memory - google-chrome

My macbook started freezing recently and I thought it might be due to shortage of memory. So I opened the activity monitor for the first time and I noticed there are some weird things happening with Chrome. Why are there so many Google Chrome Helper processes??
Is there any reason why there as so many processes?
Many thanks for your help

Well, for one, each tab of Chrome runs independently. So you'll see quite a few processes running due to that.
Another thing to keep in mind is extensions. Each of them usually run in their own process as well. If you have a lot of extensions running, they add up rather quickly.

Related

Google Colab Pro+ freezes after clo

I got a Colab Pro+ because I wanted to use the background execution option.
I enabled the background execution and GPU type and started my code.
My code is a simple CNN on Tiny ImageNet, which requires several hours of training on a GPU.
I closed the browser, and after one-two hours, I returned, and everything was frozen!
How can I resolve this issue?
This happens to me as well and the best solution I've been able to come up with (which works inconsistently, but seems to help a lot more that otherwise) is to prevent my screen from locking. Let me explain.
I run Colab Pro+ on a Macbook laptop, and the battery-saving settings are ordinarily such that the screen locks when the laptop is idle for 5 mins, the lockscreen comes up. I noticed that for some reason Colab was much more likely to freeze and disconnect if I was away from the laptop than if I were working on it for hours as it ran, so to superficially mimic this, I changed my settings to never lock the screen. And I then I realized that with these settings Colab would freeze and disconnect much less frequently, and I could successfully let it run overnight and check it in the morning. [Edit: let me clarify that I have not tried this while closing the browser. So I can attest to the efficacy of my method if you leave the browser open].
I have to say though, that it's been bad for my laptop and it's unacceptable that this is necessary despite what we pay for Colab Pro+. Their product simply does not work as advertised and we have no recourse. If anyone has discovered a better solution (that works) I'm all ears.
An alternative that works for me is to make the navigator click with some interval. You can add the following script to the console. It works well with Colab Pro and Pro+ but remember that, if you use the free account, Colab will disconnect you after some hours.
To open the console press F12 or ctrl/command+shift+i.
function Clicking(){
console.log("Clicking");
document.querySelector("colab-connect-button").click()
}
setInterval(Clicking,50000)

Client crash occurring against moderately large data

I have loaded up a database with about 7.5M nodes having 33+M relationships - it's about 25 GB in total. So, it's reasonably large is my point. What I am finding since loading it is that periodically my Neo4j client is just falling over, leaving nothing more than Chrome's irritating "Aw snap - something went wrong" behind. I have checked the logs and found nothing significant there. How can I begin to track down what is happening on these failed queries?
The issue might be with your Chrome environment. This Google support page on the "Aw Snap!" error may be of help.
Also, if your queries return a lot of data or take too long to respond, the browser might be running out of memory or exceeding some internal timeouts. So, make sure the queries you make via a browser are tailored accordingly.

Application Pool slow to start with Google Chrome

this is one that is confusing me completely.
This issue doesn't happen with IE, Firefox, Safari ONLY with Google Chrome. (I haven't tested other browsers).
Basically I run my own web server, IIS 7.5, and have a number of development websites on it which will be published and used in production from the same server. As there are a number of websites I must use Dynamic Idle times for Application Pools as resources are restricted.
Usually this wouldn't be an issue and is the way to do things seemingly based on Microsoft's best practices however there seems to be a problem with Chrome loading pages once the application pool has timed out/gone idle.
Now I understand that it takes time for the application pool to restart, which they do within seconds and serve content not long after, but with Chrome the application pool takes close to a minute to start.
This doesn't happen on first load of the website however - it only happens with subsequent loads within the same browser/session.
As I said this does not happen with IE, Firefox or Safari, the other browsers I have tested, the application pool restarts almost immediately.
I had thought that maybe this was a server side issue but since the other browsers work fine I can only figure that it is Chrome at fault. Yet I still want to make sure it isn't actually a server side issue.
Any one have any ideas?
I've just realized I posted this on Stack where it should be on Server Fault.
Sorry.
Anyway, something I wrote in the question prompted me to investigate further and I found this doesn't seem to be an application pool issue, although it could be, but more so a PHP-CGI issue. It might even be localized to my own machine.

Long Saving and Loading Time with GAS Web App

I've been running into this problem with odd regularity. Code working fine, and then it starts taking a couple minutes to save or load. It's about 2000 lines, so only on the larger-side of average. Well this problem found its way into my day today again, and I finally found the cause.
It turns out that all of my "slow code" had been copy and pasted, generally when I've used Select All. I've been doing this as I deploy the apps to coworkers and the like, causing a far amount of frustration.
I know this may sound obvious, but it seems the best practice for installing apps into other accounts is to share the script at viewer level and then make a copy.
I've also gone back to other slow code, tracked down a good version and made a copy and updated bit by bit. Slow code now fast.

VS2008 partially freezing when switching to HTML design view

This is an odd freeze. When I switch from source view to design view for an HTML or ASPX file, the client area freezes, but I can still click on other tabs and menus.
What am I missing here? Really don't feel like reinstalling VS2008.
I had the same problem, and found one resolution.
In VS 2008, In a page that was using a master page, the either frequency while working in source view or switching to design view, IDE would freeze for 10-20 seconds.
In my master template, I had references to the Google hosted JQuery, Jquery UI, and one or two more scripts off site. These were placed directly in my master page's head section.
I downloaded the js and then by deleting any offsite references, my IDE would be smooth again in both design and source mode.
I also discovered I could put the scripts inside my ToolkitScriptManager (I'm using AjaxControlToolkit) and added the Mode="Release", and could place the http://www.google.com references for the scripts. The IDE is still working fine for me.
This is often due to the Design mode downloading external resources that are timing out. As #JonK mentioned, for him it was jQuery references. I have seen this when the ConnectionString was set to production databases that could not be accessed on my development machine, even though I wasn't debugging (running) the site only editing code, it would still try to connect and because it couldn't it would stall waiting for the timeout.
VS2008 is mostly single-threaded for UI operations like this, so if it is downloading a slow or non-existent network path it hangs like this.
VS2008 can make all kinds of network requests, so these two examples may not solve it for you. The best way I have found to diagnose the problem is to use the Microsoft tool Process Monitor, filter by the Process webdev.exe, and watch for I/O requests that are long running and/or throwing errors. In my case, I could find the place that was having a problem because there would be a 20 second gap in between the hundreds of I/O entries in Process Monitor. Then, just back-tracked from when that gap began and I eventually found the request that was causing the problem.
This may not be possible for you, but if you can, an upgrade to VS2010 would help; it does a much better job of running process on multiple threads in more places so you don't have to worry about this as much.
Have you tried restarting your computer and then reopening your project?