As a background, today, my GWT hosted mode runs just mysteriously slowed down to the extent that it is virtually not working. Whenever I pause the application the relevant threads (the main thread, the code server, etc.) are waiting on some file I/O native method. After scratching my head for a while I tried to clean up my hard disk a bit. Then I just discovered in my user's Temp folder a 4 gigabyte file named gwt7155307955598297091byte-cache. I wonder what this file may be good for, and what will happen if I delete it completely. Will I have a performance issue the next time I start the dev mode waiting for the "byte-cache" to be recreated?
Looking at the gwt source code, it says it's "A global shared Disk cache", used by a linker (com.google.gwt.core.ext.linker package) and compiler (com.google.gwt.dev.javac package).
Related
I have encountered a critical issue that Unity Editor freezes. I've spent many hours debugging step by step of my codes but still can't find where the problem is. So I think maybe I should try thinking from another angle, generally speaking what reasons would cause Unity Editor freezes and not responding?
I can't find a general case discussion about this topic.
From my experience, infinite loop is one reason for sure. Deadlock is critical issue, but not sure if it causes Unity Editor freezes. Unity Editor bug that I encountered only makes the whole editor crashes, instead of freezing. Any other experiences are welcomed. Thank you!
In such case, what kind of tools or methods could I use to debug it? Right now since the editor freezes I can't use "print" to find out what happens after it freezes. So I use Visual studio to debug the Editor thread, in this way I can see all the prints that I wrote. It appears the game is still running, only the editor not responding. And I can use VS click "attach to Unity and play" and put some debugging points, then debug step by step.
The first thing that I would check out is for an infinite loop. At the hang/freeze moment, you can attatch the debugger of your choice and pause the execution. In the case that it is an infinite loop that it is executing, at the exec time pause you might find the execution in a forever running while (true) {...}
Other thing that I would check is the plugins in use. Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and hang. Source
To check that you can check the active threads in the visual studio command window af the freeze is reproduced:
View->OtherWindows->CommandWindow and type in this command:
Debug.ListCallStack /AllThreads /ShowExternalCode
In the stack you can check if some thread is there with no need, or if its related with the plugins mentioned above.
Also an interesting point is to check in the windows task manager (in the case that you are using windows) if the CPU usage is to 0%. It can lead you to the type of hang that is taking place.
Good luck.
Edit: I forgot to mention, you need to check also the unity logfiles
I notice this all the time, and its super frustrating.
Unfortunately, this could be any number of issues. I notice this issue most often when working in projects that are made for the Universal Windows Platform.
Try using the Task manager to monitor specific processes / threads running.
Some follow up questions:
What platform is your project currently targeting?
What version of Unity are you running? Have you tried other versions?
What are your computers specs? Is the OS up to date? Graphics Drivers?
Does it happen (or happen more often) when an external code editor is open? Perhaps try going to Preferences>External Editor > Regenerate Project files.
Are you using Unity Collab by chance? I've had issues where collab is stuck trying to communicate with Unity Servers / looking for changes. Try logging out of your Unity account through the editor, and log back in.
Have you tried looking for a Unity editor crash dump, or error log files? I think they can be found here C:\Users\username\AppData\LocalLow\Unity by default. Those files may give you more specific data concerning your problem.
Unity's new versions are getting more slower and slower. From my experience 2019 versions are the best and more stable.
I solved my issue. It's fundamentally an infinite loop.
It's not a simple case such as "while(true)". I'll try to explain.
My game was a PvP game, and I'm making a local AI. Usually my design pattern works fine, however I just turned off the simulation of "AI thinking time", and since the AI codes and server codes all run in local mode, the transmitting of data between server and client are replaced by local method call(meaning instantly executed before everything else).
There is a loophole in my server code. I use "Update" and a flag on server to change a specific game state, however in this particular case, it got into an infinite loop because the local method call is executed before the "Update". And because my AI now doesn't need real time to "think", it "acts" and transmits the event data to server right away. And since the transmitting doesn't need time any more, it calls the server method instantly, hence forming the infinite loop.
When running my code in debug mode, I keep getting 2 error messages:
Could not delete [path_to]\productiondb.log. May be locked by another process
I don't know what process might be locking it. It comes when I make changes to the code while my Pivotal tc Server is running in debug mode, but it dosent seem to create a lot's of trouble. Sometimes however, I get this warning:
Also due to some changes. I usally just restart the server and move on. This isen't the real problem, the real problem is that I get these messages when I havent doen any changes. Somethimes it accures when I run a certen part of the code, other times i occurs when I open certen codes in sts, however, it doen't seem to stop at the same place twice.
I am suspecting that this has something to do with git. I am using git to change between versions and doing tests. So I am thinking that STS has some of the code in memory from before I changed branche with git, and isen't updating it before I run or open the file with that code. But I am rather new to both sts and git, and can't be certan that it would work that way. If it is, does anyone know how to update sts after I have changed branch? If it is not, does anyone know what might causing it?
If you run an app in debug mode, the Eclipse Debugger tells the application when code gets changed and tries to use the debug API to swap in the new code into the running application. This is especially useful if you debug your code, hit a breakpoint, step through the code, fit the issue, change the code, and press save. At that moment, the Eclipse compiler updates the class file and tells the running JVM to swap in the new code. If that succeeds, the debugger will jump back to the last stack frame and the execution of your app will continue with the beginning of the method that you entered. This allows you to directly continue to debug and step through the updated code without restarting the app.
While this is a great feature of the JVM, it is very limited in terms of what scope of changes to the classes the JVM can deal with while doing this hot-swap. It is usually limited to method implementations. So adding new methods, adding or deleting members of the class, etc, are not supported. As a result, the above screenshot will appear. It means that the JVM wasn't able to hot-swap the changed code and will continue to run with the previously loaded code instead of the changed one.
My CPU is oscillating between 20 and 30% usage for CPU usage based on Windows Task manager. it is occurring for several hours now.
I expect this VS Code instance to do nothing.
How can I investigate what is going wrong?
I tried to open "Developer: Toggle Developer Tools", then go to performance tab and record. Unfortunately it is reporting that most of the time is in "idle" (which is what I would expect)
(I also tried to ask on Twitter without success https://twitter.com/apupier/status/1100348567926071296)
regards,
Based on the comments it seems that what the Task Manager reports is the total use of VS both on CPU utilization and memory.
A broad range of reasons could explain the observations you made.
1.Increased CPU and Memory usage by VS Studio.
2. Increased Fan Speed.
3. Your code being idle.
It can be the case that the VS Code or one of its plugins is actually doing something even if you do not actively use it. For sure if it is opened, even without being used the program will use some memory.
You can find more information on the CPU usage per VS Code Extension by typing: code --status in the command line. You can also try to execute: code --disable-extensions to run VS Code without any extensions to see if the CPU/Memory usage is reduced.
Results of the code --status will look like this
There are some related issues you could also see in GitHub, I checked before writing this answer:
100% core CPU usage without apparent reason
Excess CPU usage
Excess CPU usage editing C file
It is usually an extension. E.g. Python Intellisense. It is perhaps outsourcing processing for some scientific project aimed for the good of humanity. Fingers crossed.
Update 2022:
Earlier you could find them easily with VS Codes builtin Process Explorer. Help > "Open Process Explorer."
But the newer versions are very sneaky. They seem to have evolved making them difficult to catch while stealing your cpu. Disclaimer: the behavior may very well be even an unintentional glitch although it does not appear so.
Can you catch it in action?
Its as tough as catching a fly. As of Feb 2022, the moment you attempt to probe into the cpu usage either via vs code "help/Open Process Explorer" OR sometimes even win task manager, it stops/vanishes like a fly. Then it stays inactive for some hours or a day. You forget about it and get busy coding only to find the fans are going crazy because it has sneaked in to be active again. The newer version of the bug is perhaps programmed as such.
None the less with a lot of patience, you can sometimes catch them. Here is one instance and yet it vanished before i could scroll to catch the name.
VS Code Process manager
Solution:
I don't have a reason to probe it beyond a limit, but a small monitoring script should be able to catch the culprit.
Personally, I just had to remove the "Python extension for Visual Studio Code (Python IntelliSense - Pylance)" and that was enough to resolve.
IDE's a notoriously expensive to run. As soon as you open VS Code it loads the program from your hard drive, into RAM; acting as a staging point for all the processes VS Code uses to manage its environment. Things like,
Overhead of the Electron framework upon which it is built
Checking for external file changes that need to be synchronized to the editor
Render pipeline
Child processes to support any extensions you have running
Terminal instances (and by extension anything running in those terminals)
Here's a nifty little extension I found after some quick Googling. It will show you the subprocesses running in VS Code, and may help you identify exactly what is taking up the most bandwidth. Do keep in mind, that by killing some of those processes, you may begin to lose the associated functionality, and indeed possibly even cause VS Code to crash. The only sure-fire way to keep it from taxing your CPU, is to shut it down completely when you're not using it.
Perhaps you could try out another IDE like Sublime, IntelliJ, or Atom and see if they act more as you expect when idle. Personally, I really love the features of Jetbrain's IntelliJ (and similar: Webstorm, PhpStorm, etc).
I got the same problem. It might have something to do with the git operations. You might have DELETED many projects from your current folder, while git didn't register the deletion.
When you do something with the changes, git operations will use a lot of CPU.
The simplest solution is to create a new folder and start running VSCode in it. You can delete the whole old folder, or you can leave it alone. It's up to you.
My client has an old version of uClinux, kernel 2.6.22, running on a Blackfin STAMP board. The main application is divided into 14 processes, plus there's a webserver running on the board.
The bug we're seeing, the webserver keeps running happily along while the VOIP application seems to run out of file handles and can't create new sockets. I've tried every debugging technique I know of. I have a JTAG debugger but the memory is too small for debug symbols. I can't compile with Valgrind or anything like that. Any guesses?
Thanks,
Mike
It's likely you've got a file descriptor leak. Valgrind isn't the best tool for tracking that down anyway.
Start by doing 'ls -lah /proc/pid/fd'. That'll show you a list of file descriptors opened (and not yet closed) by the process.
If you've really got a file descriptor leak you should see a lot of entries there. It should also be immediately obvious which type of file descriptor you're leaking (file, socket, ...).
Once you know that you'll have a better idea of where in the code to look for the leak.
The fact that your file system is full may be another hint. If your application is creating a file and removing it, but not closing the file descriptor, you might have a bunch of files which you won't find in the tree but which still eat up space hanging around. In that case you'll see the file names in (the target of the symlinks in) /proc/pid/fd.
Is there some way to optimize the Netbeans IDE for PHP (and Symfony)? It's very good with code hinting, debugging etc, but the downside is that while writing code, the disk works intensively all the time which is disturbing and besides the editor slows down slightly because of the code hinting. I have 8GB memory, so it would be quite sufficient for all Netbeans needs. I mean, is it possible to somehow limit the disk usage but without limiting the code hinting? E,g, make it load all code hints to memory.
Here is a workaround which solves the problematic symptoms, i.e. the NetBeans editor now works without small delays from code hinting and the disk is quiet. I installed RAMDisk with 500MB capacity. Then I moved the .netbeans folder with user files to this RAMDisk, as described in wiki.netbeans.org/FaqWhatIsUserdir. Just FYI, moving the project folder itself made no difference, only .netbeans folder was necessary to move.
Try to deactivate the Local History plugin, maybe it is causing the high disk usage.
(Be careful if you don't have any vcs)
Although I've never have a problem with Netbeans and disk usage, maybe your disk is broke.
Kudos to #camcam for answering his own question and posting the RAM disk suggestion. In case there are other Mac users out there who want to do this on a Mac, here are instructions:
1) Create a 500MB RAM disk:
diskutil erasevolume HFS+ 'NetBeansRAMDisk' `hdiutil attach -nomount ram://1048576`
2) Locate the NetBeans application in the Finder, control-click on it and select "Show Package Contents"
3) Add this line to Contents/Resources/NetBeans/etc/netbeans.conf:
netbeans_default_cachedir="/Volumes/NetBeansRAMDisk"
(Note: the cachedir option was added in NetBeans 7.1.)
For more info, see:
http://bogner.sh/2012/12/os-x-create-a-ram-disk-the-easy-way/
http://wiki.netbeans.org/FaqAlternateUserdir
I have been using NetBeans since version 3.x I have never seen it access the disk all the time. I have regularly ~20 projects open with ~350.000 LOC
You should first make sure it's actually NetBeans that does the disk access (on Windows you can do this with ProcessExplorer, don't know about Linux).
If it's really NetBeans, you could try to give it more memory to cache more data in memory. See the NetBeans FAQ for details
And of course make sure your system is not swapping because you have too many programs open (even though it's very unlikely with 8GB RAM but not unseen...).
If you already configured NetBeans to use more memory, maybe you gave it too much and that's why the system is swapping (just a thought).
Is your project stored in Subversion? Do you use TortoiseSVN? With he default installation TortoiseSVN has a background process that caches information about the status of your versioned files. I have seen that scanning the whole harddisk in the background...