1. 개요
예전 AIX 서버에 IBM JDK 1.6 32-bit 환경에서 WebLogic 10.3을 구성한 뒤, 프로젝트 요청으로 JDK를 64-bit로 변경했습니다. 즉, JAVA_HOME을 64-bit JDK 경로로 바꾼 상황입니다. 그런데 이후 WebLogic 기동 시 Performance Pack을 로딩하지 못하는 현상이 발생했습니다.
<2009. 12. 2 오후 8시 56분 32초 KST> <Error> <Socket> <BEA-000438> <Unable to load performance pack. Using Java I/O instead. Please ensure that libmuxer library is in :'/usr/java6_64/jre/lib/ppc64/default:/usr/java6_64/jre/lib/ppc64:/usr/java6_64/jre/lib/ppc64:/usr/java6_64/jre/lib/ppc64/default:/usr/java6_64/jre/lib/ppc64/j9vm:/usr/java6_64/jre/lib/ppc64:/usr/java6_64/jre/../lib/ppc64::/u01/weblogic/wls103/wlserver_10.3/server/native/aix/ppc:/usr/lib:/usr/lib'
로그의 핵심은 libmuxer 라이브러리를 찾거나 로딩하지 못해 WebLogic Native I/O 대신 Java I/O를 사용한다는 내용입니다. 서버가 즉시 기동 실패하는 문제는 아닐 수 있지만, WebLogic의 Performance Pack이 적용되지 않으므로 원인을 확인하는 것이 좋습니다.
2. 분석
분명 libmuxer.so 파일은 ./wlserver_10.3/server/native/aix/ppc/libmuxer.so에 존재하고 있었습니다. 그런데 문득 이 libmuxer.so가 32-bit용이 아닐까 하는 생각이 들었습니다. 그래서 JDK 64-bit가 설치된 상태에서 WebLogic 10.3을 다시 설치해 보니, 다음과 같이 64-bit용 libmuxer.so도 함께 설치되었습니다.
./wlserver_10.3/server/native/aix/ppc/libmuxer.so ./wlserver_10.3/server/native/aix/ppc64/libmuxer.so
즉, 기존 설치본에는 AIX PowerPC 32-bit용으로 보이는 ppc 디렉터리만 있었고, 64-bit JDK에서 필요한 ppc64 네이티브 라이브러리 디렉터리가 없었던 것으로 판단했습니다.
ppc64 디렉터리에는 libmuxer 이외에 다른 네이티브 파일도 있습니다.
# ls -tlr total 1744 -rw-r--r-- 1 weblogic weblogic 439714 12월 3일 10:01 wlkeytool -rw-r--r-- 1 weblogic weblogic 27513 12월 3일 10:01 wlauth -rw-r--r-- 1 weblogic weblogic 18384 12월 3일 10:01 libwlfileio2.so -rw-r--r-- 1 weblogic weblogic 7984 12월 3일 10:01 libwlenv.so -rw-r--r-- 1 weblogic weblogic 17299 12월 3일 10:01 libweblogicunix1.so -rw-r--r-- 1 weblogic weblogic 4163 12월 3일 10:01 libterminalio.so -rw-r--r-- 1 weblogic weblogic 20647 12월 3일 10:01 libnodemanager.so -rw-r--r-- 1 weblogic weblogic 23040 12월 3일 10:01 libmuxer.so -rw-r--r-- 1 weblogic weblogic 312513 12월 3일 10:01 libjmsc.so
3. 대응
기존 설치본에 필요한 64-bit 네이티브 라이브러리만 부분적으로 추가 설치하는 방식은 어려웠습니다. 따라서 다른 디렉터리에 WebLogic Server Core 구성 요소만 선택하여 설치한 뒤, 새로 생성된 ppc64 디렉터리를 기존 설치 경로로 옮기는 방식으로 대응했습니다.
Choose Products and Components: ------------------------------- Release 10.3.0.0 |_____WebLogic Server [1] x | |_____Core Application Server [1.1] x | |_____Administration Console [1.2] | |_____Configuration Wizard and Upgrade Framework [1.3] x | |_____Web 2.0 HTTP Pub-Sub Server [1.4] | |_____WebLogic JDBC Drivers [1.5] | |_____Third Party JDBC Drivers [1.6] | |_____WebLogic Server Clients [1.7] | |_____WebLogic Web Server Plugins [1.8] | |_____UDDI and Xquery Support [1.9] | |_____Server Examples [1.10] |_____Workshop [2] |_____Workshop for WebLogic [2.1] |_____Workshop Runtime Framework [2.2] *Estimated size of installation: 190.2 MB
이후 commEnv.sh에서 데이터 모델 설정도 확인합니다. 기존에는 다음과 같이 32-bit로 설정되어 있었습니다.
# Setup SUN_ARCH_DATA_MODEL SUN_ARCH_DATA_MODEL="32"
다음과 같이 64로 변경합니다.
# Setup SUN_ARCH_DATA_MODEL SUN_ARCH_DATA_MODEL="64"
확인 방법
조치 후에는 WebLogic을 재기동하고 기동 로그에서 BEA-000438 메시지가 더 이상 발생하지 않는지 확인합니다. 또한 로그에 참조되는 네이티브 라이브러리 경로가 ppc64를 포함하는지, 실제 해당 경로에 libmuxer.so가 존재하는지도 함께 확인하는 것이 좋습니다.
정리하면, 32-bit JDK에서 64-bit JDK로 변경할 때는 JAVA_HOME만 바꾸는 것으로 끝나지 않을 수 있습니다. WebLogic이 사용하는 네이티브 라이브러리도 JVM의 bit 수와 맞아야 하므로, AIX 환경에서는 server/native/aix/ppc64 디렉터리와 관련 설정을 함께 점검해야 합니다.
4. 기타
Performance Pack과 Native I/O는 OS 의존적인 영역이기 때문에 OS 버그의 영향을 받을 수 있습니다. 과거에는 PosixSocketMuxer 버그로 인해 WAS Hang이 발생한 사례도 있었습니다.
따라서 운영 환경에서는 단순히 Performance Pack을 활성화하는 것뿐 아니라, 적용 중인 OS 패치 수준과 WebLogic 패치 수준도 함께 관리하는 것이 안전합니다. 문제가 재현되거나 Hang이 의심되는 경우에는 스레드 덤프, WebLogic 서버 로그, OS 레벨의 에러 로그를 함께 확보해 분석해야 합니다.