I tried to search this, but couldn't find, exactly what I am looking for
so someone please provide me an explanation on IDEA14's capture memory snapshot
It is added to 14 version for convenience reporting in case of memory troubles.
Snippet from How to report IntelliJ IDEA performance problems:
In case of memory related issues (memory usage goes high, garbage is not collected, etc) please use the Memory snapshot button in the menu near the CPU snapshot button. If it's not possible to get the snapshot because of the application crashing with OutOfMemory errors, please add the
-XX:+HeapDumpOnOutOfMemoryError
option to the IntelliJ IDEA JVM options. On the next OOM error the .hrpof dump will be produced and saved by the JVM (usually in the application working directory which is IDEA_HOME\bin).
Upload this dump to our FTP as described above in the CPU snapshot section.
Please note that memory snapshot may contain the sensitive source code from your project.
If you are uploading to a public service, use some password protection or enctyption. JetBrains FTP server is write only and you don't need to protect files uploaded there.
Additional link:
Reporting performance problems
Related
Playing on a linux hosted AzerothCore rev. be423a91b535 master branch.
Whenever as a paladin I hit a target with my abilities and then someone else swings at it the entire server crashes. The only error that shows up in log is this.
We've tested this with multiple characters on multiple accounts and and in all instances after casting either of my judgement of light, or judgement of mana causes the server to crash completely when another character swings at said target.
It does not happen if I do not use these abilities and just attach the target at the same time with another player.
This is a clean server recently set up, no additional modules or changes beyond lowering guild signing size.
error image
I've also gotten a snapshot of the server config if that has useful information.
Server config
Apparently there was a module added QAston Proc, and this causes world crashes. If anyone else has this issue updating should clear it up as the commit was removed.
I'm working on a labview program that will talk to box via VISA commands. When I use the instrument assistant in the labview Instrument I/O palette as an open window, it will send and receive information perfectly. When I close the window and try to run it within the context of the larger program (containing only that) it says that the VISA resource is busy.
I have also tried using the Open/write/close option from the Instrument I/O palette, and that also will not allow me to access the resource. I've tried all three directly after restarting the instrument in question, so I'm pretty sure it's not actually busy.
Does anyone have experience with a similar problem, and if so how did you fix it?
We have recently planned to switch from SQLite to Realm in macOS and iOS app due to db file corruption issue with SQLite so we first started with macOS app. All coding changes were smooth and app started working fine.
Background about app and DB usage - app really uses DB very heavily and performs too many read and writes to DB in each minute and saves big xml's to it. In each minute it writes / updates around 10-12 records (at max) with xml and reads 25-30records too. After each read it deletes data along with xml from database and my expectation is once data is deleted it should free up space and reduce file size but looks like it is growing continuously.
To test the new DB changes we kept app running app 3-4 days and DB file size went to 64.42GB and app started being slow. Please refer the attached screen shot.
To further debug, I started app with new DB file and size was 4KB but within 5min it goes to 295KB and never reduced in size even records were continuously added and deleted.
To further clarify, app uses NSThreads to perform various operations and those threads writes and reads data to DB but with proper begin\commit transactions. I also read at 'Large File Size' at https://realm.io/docs/java/latest/#faq and tried to find compactRealm but can't find it in objective c.
Can anybody please advise.
Update - I Give up on Realm
After 15days of efforts, Finally I have stopped usage of Realm and starting to fix/workaround db file corruption issue with SQLite. Realm Huge DB file issue was fixed by making changes to code for threads but then I started getting Too many open files error after running the app for 7-8 hours.
Debugged for whole week and made all possible changes and at some point looks like all was good as xcode were not showing any open files. But again I started getting Too many open files crash and then debugged with instrument and found there were so many open files to realm database, lock, commit and cv files.
I am sure there are no leaks in app and xcode also does not shows those open files in Disk usage as well. I decided to invoke lsof command in code before and after Realm calls and most of the it doesn't increase open file count but sometime n between it increases. In My app it started from 120 files to 550 in around 6 hours. Xcode looks all fine via Disk usage but instrument shows open files.
No good support from Realm team, sent email to them, just got one response. Made many changes to code following their suggestions and doesn't work at all so gave up on it. I think it's good for small apps only.
I am using weblogic server and was trying to get the JFRs for my Weblogic Server. The command line arguments I use are:
-XX:FlightRecorderOptions=defaultrecording=true,dumponexit=true,dumponexitpath=/my/path,repository=/some/path
There are 2 disadvantages here:
1) There is a maximum of 3 JFRs stored and data before that are lost.
2) When there is an OOM, I execute a script to kill the server with signal 11 (SIGSEGV). This does not dump the currently recording JFR.
How do I go about getting the data at the time of crash and retain all the JFR data? Space is not an issue here. If I specify maxage=0, then the JFR is never dumped. If I specify maxsize, the files are deleted once the limit is reached.
I assume JDK 7/8, since it is 2018 and you are on WLS, which means recordings can only be dumped in the Java shutdown hook. Try SIGTERM
kill -l 15
In JDK 9 and later, a dump can also be written (in native) if the JVM crashes. The file is located where the Java process was started and is called hs_err_pidXXX.jfr
JDK 10 added support for Old Object Sample events, which can be used to diagnose memory leaks. If the application exits due to an OutOfMemoryError, it will write an OOS event with paths to GC roots (regardless if you have enabled the event or not). It should provide information to solve the memory leak.
JDK 11.03 or later contains a command line tool, which can be used to print the contents of a recording file.
$ jfr print --events OldObjectSample hs_oom_pidXXX.jfr
By looking at the allocationTime you can see when objects were allocated. Memory leaks are typically allocated through out the lifetime of the application, so if you ignore the early samples (static objects) and late samples (short-lived objects) you are likely to find a leaking object and its path to the GC root. Just follow the reference chain until you find a reference that should not be there.
Does anyone know what apis Apple is using for it's Get Info panel to determine free space in Lion? All of the code I have tried to get the same Available Space that Apple is reporting is failing, even Quick Look isn't displaying the same space that Get Info shows. This seems to happen if I delete a bunch of files and attempt to read available space.
When I use NSFileManager -> NSFileSystemFreeSize I get 42918273024 bytes
When I use NSURL -> NSURLVolumeAvailableCapacityKey i get 42918273024 bytes
When I use statfs -> buffer.f_bsize * buffer.f_bfree i get 43180417024 bytes
statfs gets similar results to Quick Look, but how do I match Get Info?
You are probably seeing a result of local Time Machine snapshot backups. The following quotes are from the following Apple Support article - OS X Lion: About Time Machine's "local snapshots" on portable Macs:
Time Machine in OS X Lion includes a new feature called "local
snapshots" that keeps copies of files you create, modify or delete on
your internal disk. Local snapshots compliment regular Time Machine
backups (that are stored on your external disk or Time Capsule) giving
you a "safety net" for times when you might be away from your external
backup disk or Time Capsule and accidentally delete a file.
The article finishes by saying:
Note: You may notice a difference in available space statistics between Disk Utility, Finder, and Get Info inspectors. This is
expected and can be safely ignored. The Finder displays the available
space on the disk without accounting for the local snapshots, because
local snapshots will surrender their disk space if needed.
It looks like all the programmatic methods of measuring available disk space that you have tried give the true free space value on the disk, not the space that can be made available by removing local Time Machine backups. I doubt command line tools like df have been made aware of local Time Machine backups either.
This is a bit of a workaround, not a real api, but the good old unix command df -H will get you the same information as in the 'get info' panel, you just need to select the line of your disk and parse the output.
The df program has many other options that you might want to explore. In this particular case the -H switch tells the program to spit out the numbers in human readable format and to use base 10 sizes.
Take a look here on how to run command lines from within an app and get the output inside your program: Execute a terminal command from a Cocoa app
I believe that the underpinnings of both df and the get info panel are very likely to be the same thing.