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.
Related
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)
I just wanted to check and see if anyone knows what is happening here...
Sometimes these min.js files time out at 10 seconds and throw a 504. This has happened at work and at home, wired and on wireless. It also seems to be random which library/libraries this happens to.
I'm assuming these are called to load automatically when I include the viewer3d file?
<script src="https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/viewer3D.min.js"></script>
Sorry about the troubles. Apparently the https://developer.api.autodesk.com servers were getting some unusually heavy traffic, and our logs are showing that during that time there were a couple of long latency requests. The engineering team is currently investigating that.
I have been putting out fires all day. Can't seem to make heads or tails of this error...
Today I started for the first time after months of using the same script. It is triggered when a new record is added to a google sheet.
It seems to work on and off but every few minutes I am getting a failure notice indicating "Service using too much computer time for one day".
Looking through the documentation and the post on Stack, it is clear I am not the first to deal with this issue, but there does not seem to be any concise answer to how to resolve. I looked for some way to reach some type of google assistance but am always directed back to stack overflow to submit my issue for consideration. Understand this could be an issue with my script, but cant seem to find what might be causing this issue. Also confusing the matter is that the script does seem to be firing 90% of the time.
My questions:
How do I check the "computer time" quota?
Should I turn off that script/trigger until 24 hours have passed?
Does anyone know how to get a hold of Google support directly?
I don't know of any way that the total script run time can be seen in a dashboard.
You can see duration times of individual script executions at:
https://script.google.com/home/executions
You could scroll through your executions to look for long durations times. That might indicate an endless loop in your code.
To calculate the total run time of all your running scripts, you'd need to use the Apps Script API.
https://developers.google.com/apps-script/api/how-tos/view-processes
https://developers.google.com/apps-script/api/concepts/processes
I don't have any code to list and compile all the durations.
If anyone does, that would be very interesting.
I don't know if deleting the trigger until the next day would gain you anything. I'm guessing that it shouldn't.
Google does not provide "on demand" support people to answer questions about Apps Script. Even G Suite customers don't get "on demand" support contacts for Apps Script. You can report bugs and request features through the Google Issue Tracker, but that won't get you direct contact with a Google support person. Even if you purchase a support plan, Google doesn't have people who are designated to support Apps Script. If you purchased a support plan, they might try to help you with an Apps Script question, but officially they aren't qualified to help, or obligated to provide Apps Script support. And even if a support person tries to help you with an Apps Script problem, the first thing they'll do is a search of Stack Overflow, and give you links to SO posts.
So, it's extremely unlikely that you're going to be able to talk with someone directly at Google.
The best thing to do is to review your code for performance issues. Avoid reading the writing data often. The ideal situation is to get all the data that you need just once, process it, and write it back once. Cache data if you can. Avoid lots of calls to Properties Service. Find what part of your code is taking the longest time, and try to improve it.
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.
I'm developing a WP8.1 SL app which uses background tasks (not agents!).
My task is triggered by a TimerTrigger - once every 30 minutes (which I believe is the minimum interval for Windows Phone, right?). It is doing a lot of work, and for some reason, sometimes it gets interrupted - that is, it stops in the middle of it. The way I know it's in the middle of it is because I log what's happening and the task's work is basically the same every time.
I deployed the app to my device yesterday to test a new approach, and everything was working fine - the background task was doing everything every time it was started - worked like a charm. Today my device needed a soft reset, so I did it (nothing was working, it happens from time to time since I updated to WP8.1). Since that moment, the background task gets interrupted every time, right in the middle of it, just as with the previous approach.
Any ideas what can cause this? I'm thinking it may be connected to the soft reset, because - 100% success rate before it, 0% after that.
What I've tried so far:
I'm logging errors, I have a try-catch around everything, I've subscribed to the UnobservedException event and to the task's Canceled event, and I'm logging the suspension count - none of these things help. There seem to be no errors, it's not suspended, and it's not canceled.
I'm logging the current memory usage from time to time, and it's about 16-17MB. On my device, the limit should be 30MB, so I don't think that's a problem.
I'm calling RequestAccessAsync wherever I can. I thought once should be enough, but since that soft-reset issue, i decided to put it in 1-2 other places to check if it's causing the issue. Well, it's not, or at least this didn't fix it.
What I'm not sure about:
I have no idea how to check the CPU time my task has consumed. I can't find a good/reliable way to do so. Also, I can't find any info that would explain why the task would be stopped in the middle sometimes, and other times - it would work fine.
Any ideas why my background task is sometimes stopped at the middle? I'm really having a hard time determining how to fix/improve the app and will it work at all.
Thanks.
So, I think I found what my problem was.
First of all, the background task just needed a lot of CPU time, more than the limit, and that's why it was getting killed in the middle.
The reason why it was working sometimes, was because sometimes the device on which I was testing treated the app as being in debug (or with attached debugger). In this case the restriction on CPU time is removed.
So, even if I uninstall the app and rebuild it in Release and redeploy, and start it without the debugger attached, the device was NOT enforcing the constraints. That only happens, if I have started the app with the debugger at least once (or maybe the first time) after it's deployed. Restarting the device (just power off and then turn on) fixes this.
While I was testing, using the same build of an app, its background task ran for 40 MINUTES on one device, and just 3-4 seconds on another. After I restarted the first device, the background task started behaving normally (running for just a few seconds).
So, if you want to test your background task for the CPU constraint:
You must be testing on a device, not on the Emulator.
Uninstall the app, if it's installed.
Restart the device.
Deploy a Release build of the app.
Run the app, so that it can register the background task, and then close it.
Wait for the background task to be invoked. (You could add a trigger that can be forced, like TimeZoneChanged or UserPresent, so that you could quickly test it.)
P.S. This may not be the perfect answer, but these are my observations, and they helped me solve my problem. This by far is the best method I have found for testing the CPU time, and it's far from perfect. So, if anyone has better ideas, please share them.