Technical Blog Post
A-I-A-I-OOOOOOO - Troubleshooting Native Memory Issues
When it comes to troubleshooting native memory issues, typically where WebContainer transport is concerned, two troubleshooting methods are quite popular:
1) Disable AIO
Both troubleshooting steps aim to avoid the large native memory footprint that may occur when using AIO or Asynchronous data transfer. Much of the underlying native memory consumers in the WebContainer I/O are the directByteBuffers (DBBs) that host the I/O memory. You can read about the troubleshooting methodology in the above links. What I want to outline here are clarifications regarding AIO, NIO, DBBs, Synchronous and Asynchronous Transport that often arise when discussing the use of one or both of the troubleshooting methods:
- Both AIO and NIO use direct byte buffers (DBB) to transport data.
- Both AIO and NIO can be synchronous or asynchronous.
- AIO keeps additional threads outside the threadpool listening for incoming requests (but return quickly if there is no incoming work).
- NIO only keeps threads outside of the threadpool when there is work to complete.
- AIO scales better than NIO due to a more efficient use of threads.
- AIO additional threads consume more system resources (native memory, java memory, CPU) to manage these threads.
- NIO uses less system resources than AIO at the cost of less scalability.
- WebContainer custom property: com.ibm.ws.webcontainer.channelwritetype=sync means the WebContainer will use synchronous I/O when interfacing to the TCP Channel AIO or NIO implementation.
- Synchronous I/O means the thread that made the I/O request will wait/block until returning to the caller with the final results of the request.
- Synchronous I/O does not mean that AIO will be disabled.
- In synchronous IO, there is no need to allocate additional DBB memory to store the data overflow as each write will wait for the previous write to complete.
- DBB memory is stored in native memory and is released after use with explicit gc calls or on the next full gc.
- In synchronous I/O, additional buffers are not created because the WebContainer waits for the OS to finish processing before continuing.
- Asynchronous I/O behavior means that the calling thread may return before the read or write is complete, allowing for a thread to continue processing another event. A callback on a new thread will then be used to complete the write or read.
- Asynchronous I/O may carry DBB native memory overhead if system I/O is unable to keep up with the workload.
- If AIO DBB native memory is a concern, use WebContainer custom property: com.ibm.ws.webcontainer.channelwritetype=sync.
I hope this helps clarify the sometimes subtle differences in AIO, NIO, Synchronous and Asynchronous transport!
Thanks to Manuel Saldana for assistance in clarifying the points in this list!