OS 또는 Network에서 IPv6을 지원한다면 IBM WebSphere Application Server는 IPv6으로 network 관련 처리를 진행합니다.
이때문에 성능 이슈가 발생하기도 하는데, 이때 IPv4 형식으로만 동작하게 설정하면 이와 유사한 문제가 해결됩니다.
(개발PC의 경우 window7인 경우 해당 설정이 필수 설정입니다.
IBM Websphere InfoCenter 내용
java.net.preferIPv4Stack
IPv6 지원을 사용 불가능하게 하려면 이 특성을 사용하십시오. IPv6 지원이 사용 가능한 운영 체제의 경우, WebSphere Application Server가 사용하는 기본 소켓은 IPv6 소켓입니다. IPv6 맵핑된 주소를 지원하는 IPv4 네트워크 스택에서는 IPv6 소켓을 사용하여 IPv4 및 IPv6 호스트로 연결하거나 이 호스토로부터의 연결을 허용할 수 있습니다.
이 특성을 true로 설정하면 JVM에서 이중 모드 지원이 사용 불가능하게 되며, 표준 WebSphere Application Server 기능이 중단될 수 있습니다. 따라서 이 특성을 사용하기 전에 전체 의미를 이해해야 합니다. 일반적으로 이 특성의 설정은 권장되지 않습니다.
이 사용자 정의 특성의 기본값은 false입니다(기본값이 true인 Windows® 운영 체제 제외).
java.net.preferIPv6Addresses
IPv4 지원을 사용 불가능하게 하려면 이 특성을 사용하십시오. 이 특성을 true로 설정하면 JVM에서 이중 모드 지원이 사용 불가능하게 되며, 표준 WebSphere Application Server 기능이 중단될 수 있습니다. 따라서 이 특성을 사용하기 전에 전체 의미를 이해해야 합니다. 일반적으로 이 특성의 설정은 권장되지 않습니다.
이 사용자 정의 특성의 기본값은 false입니다(기본값이 true인 Windows 운영 체제 제외).
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm.html
Slow performance or hang in HostName lookup due to high DNS traffic
http://www-01.ibm.com/support/docview.wss?uid=swg21170467
Problem(Abstract)
You see slow performance or what looks like a hang and high DNS traffic for HostName lookup.
SymptomThere are 2 symptoms you might see:
Calls to the method java.net.InetAddress.getLocalHost takes a long time or the Java™ Virtual Machine (JVM) hangs.
Slow response from the administrative console or from wsadmin command/script.
CauseThere are 2 possible causes:
Cause 1:
Starting with Java™ 1.4.1, the IP address is not cached by default. This can cause delays and performance degradation if the application relies on this caching mechanism, since a lookup is now performed each time.
The WebSphere Application Server runtime code calls the InetAddress.getLocalHost() method in several places which then causes the DNS lookup requests. Applications making outbound calls would also trigger DNS lookup requests
- OR -
Cause 2:
The problem could be lookup issues between IPv6 versus IPv4 in releases of the Java 2 SDK 1.4. The problem may be that the JVM performs both IPv6 and IPv4 queries. If the Domain Name System (DNS) server is not configured to handle IPv6 queries, the application might issue an unknown host exception. If the DNS is not configured to handle IPv6 queries properly, the application must wait for the IPv6 query to time out.
You might also notice that getting the wsadmin command prompt takes a long time or sometimes fails because of the preceding problem.
In addition, there is a known problem in Linux on OS/390 with IPv6 that will lead to a JVM crash. For more details, review the Related information section at the bottom of this technote.
............... SKIP ..........................
Solution to cause 2
There are two possible solutions, but you need to take thread dumps or javacores at the time of slow response or hang to verify. The following lines at the top of the stack for a hung thread mean that the thread is waiting for a response back from the DNS server for the IPv6 query, in which case there is a high probability that the DNS server is taking a long time OR is unable to resolve the IPv6 query.
Take thread dumps or javacores at the time of slow response or hang. The following lines at the top of the stack for the hung thread(s), means the thread(s) is waiting for a response back from DNS server for the IPv6 query. In which case there is a high probability that the DNS server is taking time OR is unable to resolve the IPv6 query.
at java.net.Inet6AddressImpl.getLocalHostName(Native Method)
at java.net.InetAddress.getLocalHost(InetAddress.java:1186)
at org.apache.soap.util.mime.MimeUtils.getUniqueValue(Unknown Source)
at org.apache.soap.rpc.SOAPContext.setRootPart(Unknown Source)
If you are using IPv4 and IPv6 addresses in your environment, it could mean that the DNS server is not set up correctly. In that case, contact your network administrator to look into that.
If you are sure that you will only communicate with IPv4 addresses, you can set the following Java property in each server:
-Djava.net.preferIPv4Stack=true
The implication is that the application will not be able to communicate with IPv6 hosts. To set this property for WebSphere Application Server, do the following:
1.Open the administrative console and navigate to:
Servers > Application Servers > server_name > Process Definition > Java Virtual Machine > Custom Properties(/Environment Entries)
2.Add the following name and value pair:
Name: java.net.preferIPv4Stack
Value: true
3.Click Apply, then save all changes.
4.Restart the application server.
WebSphere wsadmin SOAP connector leads to performance issue
http://www-01.ibm.com/support/docview.wss?uid=swg21239790
Problem(Abstract)IBM WebSphere Application Server wsadmin with SOAP connector leads to performance issue on federated configuration with even a single wsadmin command taking a very long time to complete.
CauseSome machines have both IPv6 and IPv4 protocol enabled and due to this the SOAP protocol defaults to attempt data transmission through IPv6, but this has performance overhead.
Resolving the problemThe solution is to use IPv4 by passing the following Java system property on the Java runtime:
-Djava.net.preferIPv4Stack=true
Enable the java.net.preferIPv4Stack property on both the wsadmin and dmgr process to see if it helps.
To set it on wsadmin, edit the wsadmin.sh file (note, you might want to make a backup copy first). Add "-Djava.net.preferIPv4Stack=true \" (without quotes) after the line of "$JAVA_HOME/bin/java" \.
Your resulting wsadmin.sh file should have the following:
"$JAVA_HOME/bin/java" \
-Djava.net.preferIPv4Stack=true \
-Xbootclasspath/p:"$WAS_BOOTCLASSPATH" \
To set it on the dmgr process, you can add a custom property from the administrative console:
System administration > Deployment manager > Java and Process Management > Process Definition > Java Virtual Machine > Custom Properties
Add a new property:
Name: java.net.preferIPv4Stack
Value: true
Save the change and restart dmgr
Important: Make this changes to all the servers including the NodeAgents and the AppServers (for example: server1) in that cell.
댓글 없음:
댓글 쓰기