netty使用epoll报错:java.lang.UnsatisfiedLinkError: failed to load the required native library

Caused by: java.lang.UnsatisfiedLinkError: could not load a native library: netty_transport_native_epoll_x86_64

最近修改moquette代码, NettyAcceptor类中, 如果epoll为true, m_bossGroup = new EpollEventLoopGroup();会报错(原版本默认使用NIO)．代码和错误信息如下：

使用以下方法解决．最终测试，使用epoll性能远不如NIO(仅限本测试).

吞吐量上不去, 而且cpu占用高

极限都都到不了10w/s 感觉也就7w/s
用NIO能到差不多20W/s

原文：http://netty.io/wiki/native-transports.html

Netty provides the following platform specific JNI transports:

• Linux (since 4.0.16)
• MacOS/BSD (since 4.1.11)

These JNI transports add features specific to a particular platform, generate less garbage, and generally improve performance when compared to the NIO based transport.

Using the native transports

Note that you must specify the proper classifier for the dependency. os-maven-plugin in the extensions section in the pom.xml file will set os.detected.name and os.detected.arch properties automatically. For more information. refer to the homepage of the os-maven-plugin.

Using the Linux native transport

Because the native transport is compatible with the NIO transport, you can just do the following search-and-replace:

• NioEventLoopGroup → EpollEventLoopGroup
• NioEventLoop → EpollEventLoop
• NioServerSocketChannel → EpollServerSocketChannel
• NioSocketChannel → EpollSocketChannel

Because the native transport is not part of the Netty core, you need to pull the netty-transport-native-epoll as a dependency in your Maven pom.xml:

  
    
      
        kr.motd.maven
        os-maven-plugin
        1.5.0.Final
      
    
    ...
  

  
    
      io.netty
      netty-transport-native-epoll
      ${project.version}
      ${os.detected.name}-${os.detected.arch}
    
    ...
  

For using the native transport in a sbt project, please add line below to your libraryDependencies:

"io.netty" % "netty-transport-native-epoll" % "${project.version}" classifier "linux-x86_64"

Using the MacOS/BSD native transport

Because the native transport is compatible with the NIO transport, you can just do the following search-and-replace:

• NioEventLoopGroup → KQueueEventLoopGroup
• NioEventLoop → KQueueEventLoop
• NioServerSocketChannel → KQueueServerSocketChannel
• NioSocketChannel → KQueueSocketChannel

Because the native transport is not part of the Netty core, you need to pull the netty-transport-native-kqueue as a dependency in your Maven pom.xml:

  
    
      
        kr.motd.maven
        os-maven-plugin
        1.5.0.Final
      
    
    ...
  

  
    
      io.netty
      netty-transport-native-kqueue
      ${project.version}
      ${os.detected.name}-${os.detected.arch}
    
    ...
  

For using the native transport in a sbt project, please add line below to your libraryDependencies:

"io.netty" % "netty-transport-native-kqueue" % "${project.version}" classifier "osx-x86_64"

Building the native transports

If you already have the JAR file of the native transport, you should not need to build the native transport by yourself because the JAR file already contains the necessary shared library files (e.g. .so, .dll, .dynlib) and they will be loaded automatically.

Building the Linux native transport

To build the native transport, you need to use Linux with 64-bit kernel 2.6 or higher. Please also install the required tools and libraries:

# RHEL/CentOS/Fedora:
sudo yum install autoconf automake libtool make tar \
                 glibc-devel libaio-devel \
                 libgcc.i686 glibc-devel.i686
# Debian/Ubuntu:
sudo apt-get install autoconf automake libtool make tar \
                     gcc-multilib libaio-dev

Building the MacOS/BSD native transport

To build the native transport, you need to use MacOS 10.12 or higher. Please also install the required tools and libraries:

brew install autoconf automake libtool