We are using Nashorn to use javascript from java (JDK 1.8 U66),after some profiling we are seeing a larger data is getting occupied by jdk.nashorn.internal.scripts.JO4P0
Object. Would like to know if any one have any idea?
jdk.nashorn.internal.scripts.JO4PO and other similar instances are used to represent scripts objects from your scripts. But, you need to provide more info for further investigation. I suggest you please write to nashorn-dev openjdk alias with profiler output + more info. about your application (like to project, if open source, would be useful
Related
Context:
I have an Node.js application which memory seems to very high, I don't know if that is memory leak or not, because it is reduced after certain period time, but some times on heavy load it keeps on increasing takes much longer to get reduced.
So going through the articles and couple of videos, i figured that i have to heap snapshot and analyse what is causing the memory leak.
Steps:
I have taken 4 snap shots as of now in my local to reproduce the memory leak.
Snapshot 1: 800MB
Snapshot 2: 1400MB
Snapshot 3: 1600MB
Snapshot 4: 2000+MB
When i uploaded the heapdump files to chrome dev tools I see there a lot of information but i don't know how to proceed from there.
Please check below screenshot, it says there is constructor [array] which has 687206 as shallow Size & Retained Size is 721414 in the columns, so when expanded that constructor i can see there are 4097716 constructors created ( refer the second screenshot attached below ).
Question
What does internal array [] means ? Why is there 4097716 created ?
How can a filter out the constructor which created by my app and showing me that instead of some system/v8 engine constructor ?
In the same screenshot one of the constructor uses global variable called tenantRequire function, this is custom global function which is being used internally in some places instead of normal Node.js require, I see the variable across all the constructor like "Array", "Object". This is that global tenantRequire code for reference. It is just patched require function with trycatch. Is this causing the memory leak somehow ?
Refer screenshot 3, [string] constructor it has 270303848 as shallow size. When i expanded it shows modules loaded by Node.js. Question why is this taking that much size ? & Why is my lodash modules are repeated in that string constructor ?
Without knowing much about your app and the actions that cause the high memory usage, it's hard to tell what could be the issue. Which tool did you use to record the heap snapshot? What is the sequence of operations you did when you recorded the snapshot? Could you add this information to your question?
A couple of remarks
You tagged the question with node.js and showed Chrome DevTools. That's ok. You can totally take a heap snapshot of a Node.js application and analyze it in Chrome DevTools. But since both Node.js and Chrome use the same JS engine (V8) and the same garbage collector (Orinoco), it might be a bit confusing for someone who reads the question. Just to make sure I understand it correctly: the issue is in a Node.js app, not in a browser app. And you are using Chrome just to analyze the heap snapshot. Right?
Also, you wrote that you took the snapshots to reproduce the memory leak. That's not correct. You performed some action which you thought would cause a high memory usage, recorded a heap snapshot, and later loaded the snapshot in Chrome DevTools to observe the supposed memory leak.
Trace first, profile second
Every time you suspect a performance issue, you should first use tracing to understand which functions in your applications are problematic (i.e. slow, create a lot of objects that have to be garbage-collected, etc).
Then, when you know which functions to focus on, you can profile them.
Try these visual tools
There are a few tools that can help you with tracing/profiling your app. Have a look a FlameScope (a web app) and node-clinic (a suite of tools). There is also Perfetto, but I think it's for Chrome apps, not Node.js apps.
I also highly recommend the V8 blog.
Hi first time at investigating memory leak in a Node.js application. By reading thru a heapdump snapshot in Chrome Profiler, I see that there is an entry for (compiled code), see attached. I thought Javascript is not compiled, unlike Java. Can anyone shed some lights?
Further, unlike JProfiler and with the way the code was written (without a formal constructor), it is very hard to find the leak, and so far the info the snapshot provides is not quite useful, I have searched for sometime and so far not too much useful info on reading these snapshots, any suggestions?
Thanks!
(compiled code) indeed refers to the code generated by V8's JIT compiler. All JavaScript VMs employed by browsers today are using tiered adaptive JIT compilation - it wouldn't be possible to achieve good performance otherwise. In fact V8 never had an interpreter at all.
That refers to host objects that are implemented in C++, such as the DOM, or the JS built-in functions.
In a huge C++ builder 2010 application with several DLL's being built and linked etc. What would be the best way to trace down memory leaks that accumulate over a long period of time? Say that the application has to be running for a week or something on the target machine before it becomes an issue. Let's assume that there is no profiling application available like AQ Time or something similar. Just using the standard IDE and perhaps some code.
My initial idea was to write a macro to use in all classes that keeps track of the number of instances and space used of each class type to start with.
The RTL uses FastMM as its memory manager. FastMM supports memory leak reporting and tracing. The native version of FastMM that is included in the RTL is a stripped down version, but it does support minimal leak reporting. You can set the RTL's global ReportMemoryLeaksOnShutdown variable to true at run-time and FastMM will generate a basic leak report when the app is closed. For more advanced usage, you can download the full version of FastMM and add it to your app, which will replace the RTL's native version. You can then configure FastMM as desired.
I'm using lwIP on an embedded device, and I feel that I may be running into some bugs related to running out of memory. I know that the mem_malloc function itself will return null when a memory allocation fails, but is there any way to get a rough assessment of the available memory at an arbitrary point in time? It would be great to be able to monitor it directly, to determine which usage patterns are leaking memory.
Thanks.
Define MEM_STATS and look at the memory statistics via stats_display_mem. See stats.h, stats.c, and opt.h among other places. That should get you started.
In LwIP version 2.1.3, You need to define MEM_STATS, but also LWIP_STATS. To output the stats, when you have defined LWIP_STATS_DISPLAY, you can use MEM_STATS_DISPLAY().
I have a new Ubuntu Linux Server 64bit 10.04 LTS.
A default install of Mysql with replication turned on appears to be leaking memory.
However, we've tried going back to an earlier version and memory is still leaking but I can't tell where.
What tools/techniques can I use to pinpoint where memory is leaking so that I can rectify the problem?
Valgrind, http://valgrind.org/, can be very useful in these situations. It runs on unmodified executables but it does help tremendously if you can install the debugging symbols. Be sure to use the --show-reachable=yes flag as the leaked memory may still be reachable in some way but just not the way you want it. Also --trace-children in case of a fork. You'll likely have to track down in the start-up script where the executable is called and then add something like the following:
valgrind --show-reachable=yes --trace-children=yes --log-file=/path/to/log SQL-cmdline sqlargs
The man page has lots of other potentially useful options.
Have you tried the MySQL mailing list? Something like this would certainly be of interest to them if you can reproduce it in a straightforward manner.
You can use Valgrind as ninjalj suggests, but I doubt you'll get that close to anything useful. Even if you see a real leak (and they will be hard enough to validate), tracking down the root cause through the C call stacks will likely be very annoying (for example if the leak is triggered by a particular SQL pattern or stored procedure, you'll be looking at the call stack from the resultant optimized query, and not the original calls, which are likely in a different language).
Normally you might have no recourse, and have to resort to tracking it down through callstacks and iterative testing, but you have the source code to MySQL (including the source for the exact default package install), so you can use more advanced tools like MemoryScape (or at least build with symbols in order to provide Valgrind more food for thought).
Try using valgrind.
A very good and powerful tool, which is installed/available for most distributions is Valgrind.
It has a plethora of different options and is pretty much (as far as I've seen) the default profiler under linux systems.