什么是映射缓冲池/直接缓冲池以及如何增加它们的大小? [英] What is Mapped Buffer Pool / Direct Buffer Pool and how to increase their size?
问题描述
VisualVM 的截图是我在运行 IO 密集型 JVM 程序(用 Scala 编写)时截取的，堆大小为 4 GB，只有 2 GB 正在使用.JVM 程序使用内存映射文件.
映射缓冲池"和直接缓冲池"是什么意思?
那些水池似乎已经满了.由于 JVM 程序使用内存映射文件，如果池更大，我会看到性能提高吗?如果是这样，如何增加它们的大小?
所有映射文件的大小约为 1.1GB.
直接缓冲
直接缓冲区是一个块内存通常用于将 Java 连接到操作系统 I/O 子系统，例如作为操作系统在从套接字或磁盘接收数据时写入数据的地方，Java 可以直接从中读取数据.
与操作系统共享缓冲区比将数据从操作系统复制到 Java 的内存模型的原始方法要高效得多，这会使数据受到垃圾收集和低效率的影响，例如在迁移时重新复制数据从伊甸园 -> 幸存者 -> 终身 -> 到永久一代.
在屏幕截图中，您只有一个 16KB 的直接缓冲区.Java 将根据需要增加此池，因此蓝色区域位于块顶部的事实仅仅是声明到目前为止分配的所有缓冲内存都在使用中.我不认为这是一个问题.
映射缓冲池
映射缓冲池是 Java 为其 FileChannel 实例.
每个 FileChannel 实例都有一个与操作系统共享的缓冲区(类似于具有所有效率优势的直接缓冲区).内存本质上是文件一部分的 RAM 窗口.根据模式(读、写或两者)，Java 可以直接读取和/或修改文件的内容，操作系统可以直接向磁盘提供数据或将修改后的数据刷新到磁盘.
这种方法的其他优点是操作系统可以在它认为合适的时候直接将此缓冲区刷新到磁盘，例如当操作系统关闭时，并且操作系统可以锁定文件的该部分以防止计算机上的其他进程.
屏幕截图表明您有大约 680MB 的空间被 12 个 FileChannel 对象使用.同样，Java 会增长，因为 Scala 需要更多(并且 JVM 可以从操作系统获得额外的内存)，因此所有 680MB 都在使用中这一事实并不重要.鉴于它们的大小，在我看来，该程序已经经过优化，可以有效地使用这些缓冲区.
增加映射缓冲池的大小
Java 为 FileChannel 缓冲区分配垃圾收集空间之外的内存.这意味着像 -Xmx 这样的正常堆大小参数在这里并不重要
FileChannel 中缓冲区的大小通过 map 方法.改变这将需要改变你的 Scala 程序
一旦缓冲区达到阈值大小(大约 10 到 100 KB 的数量级)，增加 FileChannel 缓冲区大小可能会也可能不会提高性能 - 这取决于程序如何使用缓冲区:
- 否:如果文件从头到尾精确读取一次:几乎所有时间都在等待磁盘或处理算法
- 可能:但是，如果算法经常多次扫描文件重访部分，增加大小可能提高性能:
- 如果修改或写入文件，更大的缓冲区可以将更多的写入合并到单个刷新中.
- 如果读取文件，操作系统可能已经缓存了文件(磁盘缓存)，因此任何收益都可能微不足道.错误地增加 JVM 的大小可能会因为缩小有效磁盘缓存大小而降低性能
- 在任何情况下，应用程序都必须经过专门编码才能获得任何好处，例如通过在缓存中实现自己的逻辑记录指针.
尝试分析应用程序并寻找 I/O 等待(Jprofiler 和 YourKit 擅长于此).可能文件 I/O 实际上不是问题 - 不要成为 过早优化的受害者.如果 I/O 等待占总运行时间的很大一部分，那么可能值得尝试更大的缓冲区大小
更多信息
https://blogs.oracle.com/alanb/entry/monitoring_direct_buffers
另请注意，JVM 上报告了一个错误，说 FileChannel 不擅长释放内存.Prevent OutOfMemory when using java.nio.MappedByteBuffer 中有详细说明 >
The screenshot of VisualVM was taken when I ran an IO intensive JVM program (written in Scala), heap size was 4 GB and only 2 GB were in-use. The JVM program uses memory mapped file.
What does "mapped buffer pool" and "direct buffer pool" mean?
Those pools seem to be very full. Since the JVM program uses memory mapped file, will I see increased performance if the pools were larger? If so, how to increase their size?
The size of all mapped files are about 1.1GB in size.
Direct Buffer
A direct buffer is a chunk of memory typically used to interface Java to the OS I/O subsystems, for example as a place where the OS writes data as it receives it from a socket or disk, and from which Java can read directly.
Sharing the buffer with the OS is much more efficient than the original approach of copying data from the OS into Java's memory model, which then makes the data subject to Garbage Collection and inefficiencies such as the re-copying of data as it migrates from eden -> survivor -> tenured -> to the permanent generation.
In the screenshot you have just one buffer of 16KB of direct buffer. Java will grow this pool as required so the fact the blue area is at the top of the block is merely a statement that all buffer memory allocated so far is in use. I don't see this as an issue.
Mapped buffer pool
The mapped buffer pool is all the memory used by Java for its FileChannel instances.
Each FileChannel instance has a buffer shared with the OS (similar to the direct buffer with all the efficiency benefits). The memory is essentially an in-RAM window onto a portion of the file. Depending on the mode (read, write or both), Java can either read and/or modify the file's contents directly and the OS can directly supply data to or flush modified data to disk.
Additional advantages of this approach is that the OS can flush this buffer directly to the disk as it sees fit, such as when the OS is shutting down, and the OS can lock that portion of the file from other processes on the computer.
The screenshot indicates you have about 680MB in use by 12 FileChannel objects. Again, Java will grow this is Scala needs more (and the JVM can get additional memory from the OS), so the fact that all 680MB is all in use is not important. Given their size, it certainly seems to me that the program has already been optimized to use these buffers effectively.
Increasing the size of the mapped buffer pool
Java allocates memory outside the Garbage Collection space for the FileChannel buffers. This means the normal heap size parameters such as -Xmx are not important here
The size of the buffer in a FileChannel is set with the map method. Changing this would entail changing your Scala program
Once the buffer has reached a threshold size, of the order 10s-100s of KB, increasing FileChannel buffer size may or may not increase performance - it depends on how the program uses the buffer:
- No: If the file is read precisely once from end to end: Almost all the time is either waiting for the disk or the processing algorithm
- Maybe: If, however, the algorithm frequently scans the file revisiting portions many times, increasing the size might improve performance:
- If modifying or writing the file, a larger buffer can consolidate more writes into a single flush.
- If reading the file, the operating system will likely have already cached the file (the disk cache) and so any gains are likely marginal. Perversely increasing the size of the JVM might decrease performance by shrinking the effective disk cache size
- In any case the application would have to be specifically coded to get any benefits, for example by implementing its own logical record pointer onto the cache.
Try profiling the application and look for I/O waits (Jprofiler and YourKit are good at this). It may be that file I/O is not actually a problem - don't be a victim of premature optimization. If I/O waits are a significant portion of the total elapsed time, then it might be worth trying out a larger buffer size
Further information
https://blogs.oracle.com/alanb/entry/monitoring_direct_buffers
Also be aware that there is a bug reported on the JVM saying that FileChannel is not good at releasing memory. It's detailed in Prevent OutOfMemory when using java.nio.MappedByteBuffer
这篇关于什么是映射缓冲池/直接缓冲池以及如何增加它们的大小?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
