4

キュレーター フレームワークを使用して Zookeeper サーバーに接続していますが、奇妙な DNS 解決の問題が発生しています。スレッドの jstack ダンプは次のとおりです。

#21 prio=5 os_prio=0 tid=0x0000000001888800 nid=0x3a46 runnable [0x00007f25e69f3000]
java.lang.Thread.State: RUNNABLE
    at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
    at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
    at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
    at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
    at java.net.InetAddress.getAllByName(InetAddress.java:1192)
    at java.net.InetAddress.getAllByName(InetAddress.java:1126)
    at org.apache.zookeeper.client.StaticHostProvider.resolveAndShuffle(StaticHostProvider.java:117)
    at org.apache.zookeeper.client.StaticHostProvider.<init>(StaticHostProvider.java:81)
    at org.apache.zookeeper.ZooKeeper.<init>(ZooKeeper.java:1096)
    at org.apache.zookeeper.ZooKeeper.<init>(ZooKeeper.java:1006)
    at org.apache.zookeeper.ZooKeeper.<init>(ZooKeeper.java:804)
    at org.apache.zookeeper.ZooKeeper.<init>(ZooKeeper.java:679)
    at com.netflix.curator.HandleHolder$1.getZooKeeper(HandleHolder.java:72)
    - locked <0x00000000fd761f40> (a com.netflix.curator.HandleHolder$1)
    at com.netflix.curator.HandleHolder.getZooKeeper(HandleHolder.java:46)
    at com.netflix.curator.ConnectionState.reset(ConnectionState.java:122)
    at com.netflix.curator.ConnectionState.start(ConnectionState.java:95)
    at com.netflix.curator.CuratorZookeeperClient.start(CuratorZookeeperClient.java:137)
    at com.netflix.curator.framework.imps.CuratorFrameworkImpl.start(CuratorFrameworkImpl.java:167)

スレッドはネイティブ メソッドでスタックしているようで、決して戻りません。また、非常にランダムに発生するため、一貫して再現することはできませんでした。何か案は？

4

1 に答える 1

7

この問題の解決にも取り組んでいます。これは glibc のバグが原因のようです: https://bugzilla.kernel.org/show_bug.cgi?id=99671またはカーネルのバグ: https://bugzilla.redhat.com/show_bug.cgi?id=1209433に応じてあなたが尋ねる人;）

また読む価値があります: https://access.redhat.com/security/cve/cve-2013-7423およびhttps://alas.aws.amazon.com/ALAS-2015-617.html

これが実際に当てはまることを確認するには、gdb を Java プロセスにアタッチします。

gdb --pid <JavaProcessPid>

次にgdbから：

info threads

recvmsg を実行するスレッドを見つけます。

thread <HangingThreadId>

その後

backtrace

次のようなものが表示された場合は、glibc/kernel のアップグレードが役立つことがわかります。

#0  0x00007fc726ff27cd in recvmsg () from /lib64/libc.so.6
#1  0x00007fc727018765 in make_request () from /lib64/libc.so.6
#2  0x00007fc727018b9a in __check_pf () from /lib64/libc.so.6
#3  0x00007fc726fdbd57 in getaddrinfo () from /lib64/libc.so.6
#4  0x00007fc706dd9635 in Java_java_net_Inet6AddressImpl_lookupAllHostAddr () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-0.b17.el6_7.x86_64/jre/lib/amd64/libnet.so

更新: カーネルが勝ったようです。詳細については、 http ://www.gossamer-threads.com/lists/linux/kernel/2264958 のスレッドを参照してください。また、システムがカーネル バグの影響を受けていることを確認するためのツールもあります。この簡単なプログラムを使用できます: https://gist.github.com/stevenschlansker/6ad46c5ccb22bc4f3473

検証します：

curl -o pf_dump.c https://gist.githubusercontent.com/stevenschlansker/6ad46c5ccb22bc4f3473/raw/22cfe72f6708de1e3468c1e0fa3888aafae42db4/pf_dump.c
gcc pf_dump.c -pthread -o pf_dump
./pf_dump

出力が次の場合:

[26170] glibc: check_pf: netlink socket read timeout
Aborted

次に、システムが影響を受けます。出力が次のような場合:

exit success [7618] exit success [7265] exit success

その後、システムは問題ありません。AWS のコンテキストでは、新しいカーネルで AMI を (2016.3.2) にアップグレードすると、問題が解決したようです。

于 2016-08-11T10:42:24.900 に答える