解释 VisualVM 分析会话的结果
我有一个应用程序，使用 this 将一些数据（80k 元组中大约 15mb）写入 SQLite 数据库Mac OS X 上的 jdbc-driver。这是使用事务完成的，其中最大的事务包含对一个表的大约 45k 插入。在分析应用程序时，有几件事看起来很奇怪：
- 如果我在开始时使用 System.in.read() 暂停应用程序，则进程分配的内存会持续缓慢增长。这是为什么？
- 当应用程序运行时，VisualVM 监视器中使用的堆空间始终在 80mb 左右。然而，在分析内存使用情况时，我总共得到了大约 10mb 的内存。谁能解释这个区别吗？
感谢您的任何帮助。
I have an application that writes some data (about 15mb in 80k tuples) into an SQLite database using this jdbc-driver on Mac OS X. This is done using transactions, the largest of which contains about 45k inserts into one table. When profiling the application, several things seems strange:
- If I pause the application right at the beginning using
System.in.read(), the memory allocated by the process keeps growing slowly. Why is that? - When the application runs, the heap space used is always at around 80mb in the VisualVM monitor. However, when profiling memory usage, I get a total of about 10mb. Can anyone explain this difference?
Thanks for any help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
内存使用中的拼图模式是由于通过 RMI 传输分析结果造成的。通过程序从实际内存分配中过滤确实非常令人困惑和烦人。请参阅 VisualVM 分析正在污染结果，了解如何过滤这些结果:-)
The jigsaw pattern in memory usage is due to the profiling results being transmitted over RMI. This is indeed very confusing and annoying to filter from real memory allocations by your program. See VisualVM profiling is polluting results to find out how to filter these :-)
关于你的第一个问题，你观察到缓慢增长的时间片是多长时间？当 Java 进程中的内存使用处于静态时，您通常会看到出现锯齿模式。您是否看到同一时间片内发生了任何 GC？如果不是，那就有更多证据支持这个想法。
对于第二个问题，如果没有更多信息，很难确定。您通常会期望在打开分析时应用程序的行为会有所不同，因为计时窗口发生变化，应用程序必须花费时间报告数据并执行其正常工作等。可能是在打开分析时打开时，会发生更多内存分配，因为您的代码现在已进行检测，这会触发 GC，从而降低堆使用率。当分析关闭时，尝试在应用程序中执行 System.gc() 并告诉我们您的堆使用情况报告。
With regards to your first issue, how long of a time slice did you observe the slow growth over. When memory usage is quiescent in a Java process you'll typically see a sawtooth pattern develop. Did you see any GC's occur in the same time slice? If not, then thats more evidence that supports this idea.
For problem number two, it's really hard to say for certain without more information. You would typically expect the application behaivor to differ when profiling is turned on because timing windows change, the application has to spend time reporting data and doing its normal work, etc. It could be that when profiling is turned on, more memory allocations happen because your code is now instrumented, and this triggers a GC which lowers the heap usage. Try doing a System.gc() in your application when profiling is turned off and tell us what your heap usage reports.