Description
For sites using only IPv4, you may find better performance and simplicity in configuring the environment to use only IPv4, wherever possible. This wiki page provides guidance on forcing applications to use IPv4 when possible.
Many OSs will enable IPv6 by default, even if the environment is only using IPv4. Configuring the OS to disable IPv6 would help to prevent these sorts of problems.
Known Problems
There are some known problems with applications trying to use IPv6, when the environment is really only configured for IPv4.
1. IPv6 changes the way that Round-Robin A-records are used, and instead forces an ordered priority weighting of A-records. This can cause high-availability techniques dependent on round-robin A-records to fail or work incorrectly. If using IPv4/IPv6 dual-stack, then the JVM will use getaddrinfo() instead of gethostbyname(). getaddrinfo() will sort the DNS results in an ordered way, due to RFC 3484 [1]. Some OSs provide /etc/gai.conf configuration options in an attempt to configure record handling.
2. The JVM can be blocked by an infinite loop problem between the JVM and libc when using the IPv6 getaddrinfo() libraries with IPv4 addresses. This issue is discussed in more detail here:
http://bugzilla.zimbra.com/show_bug.cgi?id=68432
http://old.nabble.com/-Bug-libc-12926--New%3A-getaddrinfo%28%29-make_request%28%29-may-spin-forever-td31913044.html
http://sourceware.org/bugzilla/show_bug.cgi?id=12926
In the JVM, following is what the threads look like. You will see many threads in the thread dump file locked in a state similar to this:
"btpool0-41529" prio=10 tid=0x00002aaac45dd000 nid=0x7db9 in Object.wait() [0x0000000047155000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at java.net.InetAddress.checkLookupTable(InetAddress.java:1267)
- locked <0x00000006e385b000> (a java.util.HashMap)
at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1190)
These threads are waiting for the Lookup Table object to be released from another thread that holds it. Here's the thread holding it:
"btpool0-41526" prio=10 tid=0x00002aaac5904800 nid=0x7db6 runnable [0x0000000044c02000]
java.lang.Thread.State: RUNNABLE
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:850)
at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1201)
at java.net.InetAddress.getAllByName0(InetAddress.java:1154)
at java.net.InetAddress.getAllByName(InetAddress.java:1084)
at java.net.InetAddress.getAllByName(InetAddress.java:1020)
at java.net.InetAddress.getByName(InetAddress.java:970)
You'll see that's running Inet6AddressImpl.lookupAllHostAddr. Because of a bug between Java and libc, this lookup can enter an infinite loop when a certain race condition occurs. This occurs infrequently, but can cause deadlocks where all threads of one type (such as LMTP threads) or even all JVM threads can end up blocked.
With java.net.preferIPv4Stack set to true, Java will not execute this code and the problem should be avoided.
Configuration
1. Java processes can be configured to prefer the IPv4 stack. The default is to prefer the IPv6 stack, so it requires a specified JVM argument to prefer IPv4:
-Djava.net.preferIPv4Stack=true
This would need to be added to your existing mailboxd_java_options. Your existing configuration may vary depending on your performance tuning [see http://wiki.zimbra.com/wiki/Performance_Tuning_Guidelines_for_Large_Deployments], so be careful to append this option to whatever is there currently:
# su - zimbra
$ zmlocalconfig mailboxd_java_options
$ zmlocalconfig -e mailboxd_java_options="-server -Djava.awt.headless=true -Dsun.net.inetaddr.ttl=60 -XX:+UseConcMarkSweepGC -XX:NewRatio=2 -XX:PermSize=192m -XX:MaxPermSize=192m -XX:SoftRefLRUPolicyMSPerMB=1 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/zimbra/log -Djava.net.preferIPv4Stack=true"
For more reference background on this, please review here:
http://bugzilla.zimbra.com/show_bug.cgi?id=13161#c55
2. Configuring the OS to disable IPv6
Each OS may have unique recommendations for disabling IPv6. This article does not currently include all OS-level recommendations, but please do a web search and determine methods for disabling the IPv6 interfaces, modules, and stack for your OS of choice.
分享到:
相关推荐
操作系统实验六:死锁问题实验报告。通过本实验观察死锁产生的现象,考虑解决死锁问题的方法。从而进一步加深对于死锁问题的理解。掌握解决死锁问题的几种算法的编程和调试技术。练习怎样构造管程和条件变量,利用...
车辆行驶死锁问题,在Linux下用C语言完成下面模型:设有一个T型路口,其中A,B,C,D各处可容纳一辆车,车型方向如图所示。找出死锁并用有序分配法消除之,要求资源编号合理。
死锁的四个条件: (1) 互斥条件:一个资源每次只能被一个进程使用。 (2) 请求与保持条件:一个进程因请求资源而...先写一个会造成死锁的哲学家问题。当所有哲学家同时决定进餐,拿起左边筷子时候,就发生了死锁。
操作系统死锁问题 C语言实现 有详细代码 都能实现
进程死锁的检测:资源分配图的化简判断是否有死锁发生
关于Oracle数据库死锁问题的研究与讨论
db2死锁问题.doc db2死锁问题.docdb2死锁问题.docdb2死锁问题.docdb2死锁问题.docdb2死锁问题.docdb2死锁问题.docdb2死锁问题.docdb2死锁问题.docdb2死锁问题.docdb2死锁问题.doc
山东大学 操作系统实验6 死锁问题实验的程序
解决死锁问题的三种方法:预防死锁,检测死锁及避免死锁。
一、数据库死锁的现象 程序在执行的过程中,点击确定或保存按钮,程序没有响应,也没有出现报错。 二、死锁的原理 当对于数据库某个表的某一列做更新或删除等操作,执行完毕后该条语句不提 交,另一条对于这一列...
Java解决死锁问题eclipse代码版
有关银行家算法的实现,它是用来解决操作系统中的死锁问题的有效方法!
在两个城市南北方向之间存在一条铁路,多列火车可以分别从两个城市的车站 排队等待进入车道向对方城市行驶,该铁路在同一时间,只能允许在同一方向上行 车,如果同时有相向的火车行驶...您能构造一个管程来解决这个问题吗?
安全性算法,银行家算法,避免进程死锁的问题,这是我用C语言编的程序,运行通过。
包含了操作系统的三个死锁问题,哲学家问题,消费者生产者问题,管道等,解决方法。绝对可用。
Oracle数据库死锁问题研究.pdf
编译的存储过程的时候,程序死住,等待一会出现ora-04021错误解决办法。文档中有查询思索的语句,以及杀掉死锁进程的方法。
db2死锁问题分析及解决方案,可以快速解决数据库问题。
用银行家算法预防死锁 #include using namespace std; #define MAXPROCESS 50 /*最大进程数*/ #define MAXRESOURCE 100 /*最大资源数*/ int AVAILABLE[MAXRESOURCE]; /*可用资源数组*/ int MAX[MAXPROCESS]...
有关死锁的介绍。包括死锁的定义,如何处理死锁,死锁如何预防,如何避免等