달력

4

« 2024/4 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

출처 : http://docs.sun.com/app/docs/doc/819-4673/gbpxu?l=ko&a=view


BEA WebLogic Server

Consider making the following changes:

 

JVM GC Parameter

For BEA WebLogic Server 8.1 SP4, to avoid the java.lang.OutofMemoryError reported by the WebLogic JVM 1.4.2_05, add the following JVM GC (garbage collection) parameter in the startWebLogic.sh JAVA_OPTIONS:

-XX:-CMSParallelRemarkEnabled

Set this parameter in addition to the other heap size and GC parameters that have been added for JVM 1.4.2 for Application Server 8.1 and Web Server 6.1.

For example, if Access Manager is installed in the default user_projects location (/usr/local/bea/user_projects/domains/mydomain/startWebLogic.sh):

JAVA_OPTIONS="-XX:+DisableExplicitGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled
-XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram
-XX:+PrintGCTimeStamps
-Xloggc:/usr/local/bea/user_projects/domains/mydomain/myserver/gc.log"

If you use WebLogic 9.x with Sun JVM 1.5 or later, then some of the GC algorithms can be safely removed. The following is a list of JVM options that can be used with Sun JVM 1.5 or later.

-XX:NewSize=336M -XX:MaxNewSize=336M
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+PrintClassHistogram
-XX:+PrintGCTimeStamps
-Xloggc:/opt/WebSphere/AppServer/logs/server1/gc.log
-XX:-CMSParallelRemarkEnabled 

Heap Size

Modify the commonEnv.sh script in the /usr/local/bea/weblogic81/common/bin directory for heap size increases in the section where $PRODUCTION_MODE" = "true" (which should be set to true, before running Access Manager in /usr/local/bea/user_projects/domains/mydomain/startWebLogic.sh):

# Set up JVM options base on value of JAVA_VENDOR
if [ "$PRODUCTION_MODE" = "true" ]; then
  case $JAVA_VENDOR in
  BEA)
    JAVA_VM=-jrockit
    MEM_ARGS="-Xms128m -Xmx256m"
  ;;
  HP)
    JAVA_VM=-server
    MEM_ARGS="-Xms32m -Xmx200m -XX:MaxPermSize=128m"
  ;;
  IBM)
    JAVA_VM=
    MEM_ARGS="-Xms32m -Xmx200m"
  ;;
  Sun)
    JAVA_VM=-server
    MEM_ARGS="-Xms2688M -Xmx2688M -XX:NewSize=336M -XX:MaxNewSize=336M"
   # MEM_ARGS="-Xms32m -Xmx200m -XX:MaxPermSize=128m"

Execute Queue Thread Count

Set the Execute Queue Thread count to be more than the number of CPUs. For example, consider using a value that is twice the number of CPUs. Set this value in either the console or in the /usr/local/bea/user_projects/domains/mydomain/config.xml file:

<ExecuteQueueName="MyExecute Queue" ThreadCount="8" ThreadsIncrease="4"/>

For more information, see “Modifying the Default Thread Count” in “WebLogic Server Performance and Tuning” at:

http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#1142218

Connection Backlog Buffering

A guideline for setting Connection Backlog Buffering is 8192 for a server with 4 Gbytes of physical memory (which is equivalent to the ConnectionQueue size tuning set in the Sun Java System Web Server 6.1 magnus.conf file).

For more information, see “Tuning Connection Backlog Buffering” in the “WebLogic Server Performance and Tuning” document at:

http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#1136287

:
Posted by 라면스프
2008. 11. 15. 13:09

WebLogic Tuning Guide on Linux Enjoy/etc2008. 11. 15. 13:09


출처 : http://www.adminschool.net/wiki/doku.php?id=service:was:weblogic:wltunning


WebLogic Tuning Guide on Linux

OS limit Setting

  1. vi /etc/security/limits.conf
    *       soft    nproc       16384
    *       hard    nproc       16384
    *       soft    nofile      65536
    *       hard    nofile      65536
    
  2. 필요에 따라서 .bash_profile 이나 .bashrc 를 수정한다.
    ulimit -Hn 8192
    ulimit -Sn 8192
    

OS Kernel Tuning

  1. 현재 설정을 확인해 본다.
    # su -
    # sysctl -a
    
  2. 변경할 셋팅값을 /etc/sysctl.conf 에 입력한다.
    kernel.msgmni = 1024
    net.ipv4.tcp_max_syn_backlog = 8192
    
  3. 필요에 따라 다음 커널 값들을 수정(/etc/sysctl.conf)한다.(정확히 알지 못한다면 수정하지 말것.)
    # weblogic + apache2 (testing)
    ## net.ipv4.tcp_keepalive_time = 7200
    ## net.ipv4.tcp_keepalive_intvl = 75
    ## net.ipv4.tcp_keepalive_probes = 9
    #
    net.ipv4.tcp_fin_timeout = 15
    net.ipv4.tcp_keepalive_time = 60
    net.ipv4.tcp_keepalive_intvl = 60
    net.ipv4.tcp_keepalive_probes = 1
    
    

WebLogic Setting

  • JDBC Connection Pool > Connections 설정에 Test Reserved Connections 옵션을 체크한다.

: DB 연결이 끊어지고 다시 연결할때 DB 접속을 시도하는 옵션이다.
이 옵션이 체크되어 있지 않은 상태에서 DB 연결이 끊어지고 나면 DB 연결을 더 이상 하지 않는다.

  • Services > JMS > Connection Factories > cgQueue 에서 Target and Deploy 에서 Independent Servers의 Target을 선택한다.

: 이 옵션을 선택하지 않으면 아래와 같은 에러가 나올 수 있다.

<2007. 3. 30. 오후 4시 24분 20초 KST> <Warning> <J2EE> <BEA-160082> <There was an error while making the initial 
connection to the JMS resource named weblogic.jws.jms.QueueConnectionFactory from the EJB "StatelessContainer" 
inside application "beflyt". The server will attempt the connection again later. The error was 
javax.jms.JMSException: [J2EE:160048]JNDI lookup of the JMS connection factory 
weblogic.jws.jms.QueueConnectionFactory failed: javax.naming.NameNotFoundException: While trying to 
lookup 'weblogic.jws.jms.QueueConnectionFactory' didn't find subcontext 'jws' Resolved weblogic; remaining 
name 'jws/jms/QueueConnectionFactory'>

Memory Tuning

  1. JDK 변경
    • weblogic을 설치하면 기본적으로 jrockit 과 Sun JDK 가 설치되어 있다. 하나를 선택한다면 Sun JDK를 선택하는 것을 권고한다.
    • OS에서 제공하는 JDK가 있다면, OS 제공하는 JDK를 사용하는 것이 성능적으로 우수할 수 있다.
  2. MEM_ARGS 옵션 변경
    MEM_ARGS="-Xms1024m -Xmx1024m -XX:NewSize=367m -XX:MaxNewSize=367m -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SurvivorRatio=2"
    JAVA_VM="-server"
    

Servers/JDBC Tuning

  • 서버 설정값 Development and Production Startup Mode Tuning Defaults
Tuning Parameter Development Mode Default Production Mode Default
Execute Queue: ThreadCount 15 threads 25 threads
JDBC Connection Pool: MaxCapacity 15 connections 25 connections
  • 현재 회사에서 운영중인 서버 설정
location Name values
JDBC Connection Pool: Connections Initial Capacity 25
JDBC Connection Pool: Connections Maximum Capacity 200
JDBC Connection Pool: Connections Capacity Increment 5
Servers: Execute Queue Thread Count 25
  • Thread Count 와 JDBC Connection Pool Count 는 일치시켜 주는 것이 성능상 좋다.
  • [{domain}] - [Servers] - [{server name}] - 'Configuration' - 'Tuning'
    1. MSI File Replication Enabled : 서버가 시작될때 어드민 콘솔에 접근이 안되면 이전 MSI 값으로 기동된다.
      NoStage 모드일때 적절한 값이다.
  • [{domain}] - [Servers] - [{server name}] - 'Logging' - 'Server'
    1. Server File Name : The name of the file that stores this server's current log messages.
      If the pathname is not absolute, the path is assumed to be relative to the root directory of the machine on which this server is running.
      필요가 없다면 '/dev/null'로 설정한다.
    2. Log to Stdout : Specifies whether the server should send messages to standard out
  • [{domain}] - [Servers] - [{server name}] - 'Logging' - 'Server'
    1. Enable HTTP Logging : 웹로그가 필요하지 않다면 체크를 해제한다.
  • [{domain}] - [Services] - [JDBC] - [Connection Pools] - 'Configuration' - '{Pool Name}' - “Configuration' - 'Connections' - 'Advanced Options'
    1. Allow Shrinking : 'Shrink Frequency(sec)'마다 JDBC Connection Pool을 확인하고 사용하지 않는 Pool은 연결해제시킨다.
    2. Enable Connection Leak Profiling : JDBC Connection leak을 수집, 해결한다.
    3. Test Reserved Connections : 'Test Table Name'에 있는 쿼리로 JDBC Connection Pool을 확인한다.
    4. Connection Reserve Timeout : The number of seconds (between -1 and a positive 32-bit integer) after
      which a call to reserve a connection from the pool will timeout.
      When set to 0, a call will never timeout.
      When set to -1, a call will timeout immediately.
    5. Connection Creation Retry Frequency : DB가 연결이 되지 않은 상태에서 시작할 수 있으며,
      정해진 간격으로 체크하면서 DB가 연결되면 Pool을 생성한다.
      300초면 적당할 듯하다.

Nostage -

WebLogic + Apache2 Tuning

WebLogic Debug

  1. vi setDomain.sh 이나 환경설정에서 MEM_ARGS 라인에 -verbosegc 옵션을 추가한다.
    #   MEM_ARGS="-Xms512m -Xmx512m" (기존)
    #   MEM_ARGS="-Xms512m -Xmx512m -verbosegc" (GC Memory Debug On)
    
 
:
Posted by 라면스프
2008. 10. 24. 18:42

JDBC로 인한 서버 Hang(정지) - weblogic Enjoy/etc2008. 10. 24. 18:42

출처:http://kr.bea.com/support/customer_support/service_pattern/pattern/JDBC_Causes_Server_Hang_Pattern.html


문제 설명
응용 프로그램 또는 WebLogic Server 자체에 사용되는 JDBC 커넥션에 의해 해당 커넥션을 통한 호출이 완료될 때까지 WebLogic Server Execute 스레드가 차단됩니다. JVM은 CPU가 자체적인 스레드 스케줄 메커니즘에 따라 실행 가능한 스레드에 할당되며 SQL 쿼리를 차단하는 스레드가 대기해야 하는지 확인합니다. 그러나 JDBC가 사용 중인 스레드는 SQL 쿼리에서 호출이 반환될 때까지 응용 프로그램용으로 할당됩니다.

트랜잭션 시간이 초과되더라도 해당 트랜잭션에 참가한 리소스가 수행하는 작업이 중단되거나 종료되지 않습니다. 작업은 진행되는 동안 중단 없이 실행됩니다. 트랜잭션 제한 시간에 따라 설정된 플래그에 의해 트랜잭션이 롤백만 가능한 것으로 표시되기 때문에 이 트랜잭션에 대한 이후의 모든 커밋 요청은 TimedOutException 또는 RollbackException이 발생하여 실패합니다. 그러나 위에서 언급한 것처럼 실행 시간이 긴 JDBC 호출로 인해 WebLogic Server Execute 스레드가 차단될 수 있으며 그 결과 모든 스레드가 차단되어 들어오는 요청을 처리할 Execute 스레드가 남지 않으면 인스턴스가 Hang(정지) 상태가 될 수 있습니다.

최신 버전의 WebLogic Server에서는 스레드가 특정 시간(디폴트값: 600초) 내에 반응하지 않는지 규칙적으로 확인하는 상태 검사 기능이 제공됩니다. 이러한 문제가 발생하면 로그 파일에 다음과 같은 오류 메시지가 출력됩니다.

####<Nov 6, 2004 1:42:30 PM EST> <Warning> <WebLogicServer> <mydomain> <myserver> <CoreHealthMonitor> <kernel identity> <>
<000337> <ExecuteThread: '64' for queue: 'default' has been busy for "740" seconds working on the request "Scheduled Trigger",
which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>


이 오류 메시지는 단순히 관리자에게 상태를 알리기 위한 것으로 스레드가 중단되지는 않습니다. 멈춘 스레드는 요청 처리가 완료되어야 다시 실행됩니다. 이 경우 WebLogic Server의 로그 파일에 다음과 같은 메시지가 표시됩니다.

####<Nov 7, 2004 4:17:34 PM EST> <Info> <WebLogicServer><mydomain> <myserver> <ExecuteThread: '66' for queue: 'default'>
<kernel identity> <> <000339> <ExecuteThread: '66' for queue: 'default' has become "unstuck".>


상태 검사 기능의 간격은 변경할 수 있습니다. config.xml 파일의 <Server> 태그에서 StuckThreadMaxTime 속성을 확인하십시오. 자세한 내용은 http://e-docs.bea.com/wls/docs81/config_xml/Server.html#StuckThreadMaxTime 또는 http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#stuckthread의 WebLogic Server 관리 콘솔 도움말에서 "멈춘 스레드 검색" 단원을 참조하십시오.

페이지 맨 위

문제 해결
다른 프로그래밍 방법이나 JDBC 커넥션 풀 구성을 사용할 경우 JDBC 데드락(Deaklock) 또는 WebLogic Server 인스턴스 Hang(정지) 상태를 초래하는 JDBC 호출이 발생할 수 있습니다. WebLogic Server 인스턴스 Hang(정지) 상태를 해결하고 분석하는 방법에 대한 자세한 내용은 일반적인 서버 Hang(정지) 패턴을 참조하십시오.

이 패턴에서는 서버 Hang(정지) 상태의 원인이 되는 JDBC 호출과 기타 WebLogic Server 인스턴스 Hang(정지) 상태를 초래하는 일반적인 JDBC 관련 문제에 대해 설명합니다. 이 패턴의 참조 지원 패턴은 WebLogic Server 지원 패턴 사이트에서 확인할 수 있습니다.

항목 바로가기

문제 발생 원인
다음과 같은 경우 WebLogic Server 인스턴스 Hang(정지) 상태가 발생할 수 있습니다.
  • JDBC 코드에 DriverManager.getConnection()을 사용하는 경우
  • 데이터베이스에 대한 SQL 쿼리 결과가 반환되는 데 너무 오래 걸리는 경우
  • JDBC 커넥션 풀이 구성된 데이터베이스가 Hang(정지)되어 적절한 시간 내에 호출에 응답하지 않는 경우
  • 느리거나 오버헤드가 발생한 네트워크로 인해 데이터베이스 호출이 느려지거나 Hang(정지)되는 경우
  • 데드락으로 인해 모든 Execute 스레드가 Hang(정지)되어 계속 대기하는 경우
  • JDBC 커넥션 풀의 RefreshMinutes 또는 TestFrequencySeconds 속성으로 인해 WebLogic Server에서 Hang(정지) 기간이 발생하는 경우
  • JDBC 커넥션 풀 축소 및 데이터베이스 커넥션 재생성으로 인해 응답 시간이 길어지는 경우
페이지 맨 위

동기화된 DriverManager.getConnection()
이전의 JDBC 응용 프로그램 코드에서는 특정 드라이버를 사용하는 데이터베이스 커넥션을 검색하기 위해 DriverManager.getConnection() 호출을 사용하기도 했습니다. 이 방법은 데드락을 발생시키거나 커넥션 요청의 성능을 상대적으로 저하시킬 수 있으므로 사용하지 않는 것이 좋습니다. 이러한 문제가 발생하는 원인은 모든 DriverManager 호출이 클래스별로 동기화되어 있어 한 스레드의 특정 DriverManager 호출이 WebLogic Server 인스턴스의 스레드에서 발생하는 다른 모든 DriverManager 호출을 차단하기 때문입니다.

또한 SQLException 생성자에 의해 DriverManager 호출을 발생시키는 대부분의 드라이버에는 로깅을 위한 DriverManager.println() 호출이 포함되어 있기 때문에 DriverManager 호출을 보내는 다른 모든 스레드가 차단될 수 있습니다.

DriverManager.getConnection()에 의해 데이터베이스에 대해 만들어진 커넥션이 반환될 때까지는 상당히 오래 걸립니다. 데드락이 발생하지 않더라도 한 스레드가 커넥션을 가져올 때까지 다른 모든 호출은 대기해야 합니다. WebLogic Server와 같은 멀티 스레드 시스템의 경우 이러한 방법은 바람직하지 않습니다.

이 정보는 http://forums.bea.com/bea//thread.jspa?forumID=2022&threadID=200063365&messageID=202311284&start=-1#202311284에서 발췌한 내용입니다.
DriverManager.getConnection()을 사용해서는 안 된다는 점은 http://e-docs.bea.com/wls/docs81/faq/jdbc.html#501044의 설명서에도 명확히 기술되어 있습니다.

JDBC 코드에 JDBC 커넥션을 사용하려면 WebLogic Server JDBC 커넥션 풀을 사용하고 풀에 대한 DataSource를 정의하여 DataSource에서 커넥션을 가져와야 합니다. 그러면 데이터베이스가 다운되는 등의 문제가 발생한 경우에 리소스 공유, 커넥션 재사용, 커넥션 새로 고침과 같은 풀의 이점을 활용할 수 있습니다. 또한 DriverManager 호출 시에 데드락 발생을 방지할 수 있습니다. WebLogic Server에서 JDBC 커넥션 풀, DataSource 및 기타 JDBC 개체를 사용하는 방법에 대한 자세한 내용은 http://e-docs.bea.com/wls/docs81/jdbc/intro.html#1036718http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1054307을 참조하십시오.

DriverManager.getConnection() 호출에서 차단된 스레드의 일반적인 유형은 다음과 같습니다.
"ExecuteThread-39" daemon prio=5 tid=0x401660 nid=0x33 waiting for monitor entry [0xd247f000..0xd247fc68]
  at java.sql.DriverManager.getConnection(DriverManager.java:188)
  at com.bla.updateDataInDatabase(MyClass.java:296)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
  at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:945)
  at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:909)
  at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
  at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:392)
  at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:274)
  at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)



페이지 맨 위

장시간 실행되는 SQL 쿼리
장시간 실행되는 SQL 쿼리는 호출하는 응용 프로그램에 결과를 반환할 때까지 Execute 스레드를 점유합니다. 따라서 응용 프로그램 로드에 의해 요청된 호출을 동시에 여러 개 처리할 수 있도록 WebLogic Server 인스턴스를 구성해야 합니다. 이 경우 제한 요인은 JDBC 커넥션 풀의 Execute 스레드 및 커넥션 수입니다. 또한 가장 중요한 일반 규칙은 리소스 사용량을 최적화하기 위해서는 풀의 커넥션 수를 Execute 스레드 수와 동일하게 설정해야 한다는 것입니다. JTS를 사용하는 경우 실제로 활성화되지 않은 트랜잭션에 대해 커넥션이 확보될 수 있으므로 풀에 커넥션 수를 좀 더 많이 설정해야 합니다.

장시간 실행되는 SQL 호출에서 Hang(정지)되는 스레드의 경우 스레드 덤프에 Hang(정지) 상태의 데이터베이스와 매우 유사한 스택이 표시됩니다. 자세한 내용은 다음 단원에서 비교해 보십시오.

Hang(정지) 상태의 데이터베이스
데이터베이스를 사용하는 응용 프로그램의 성능은 해당 데이터베이스의 성능에 의해 가장 크게 좌우됩니다. 따라서 Hang(정지) 상태의 데이터베이스는 WebLogic Server 인스턴스의 Execute 스레드 중 대부분 또는 일부를 차단시킬 수 있으며 결과적으로 서버 Hang(정지) 상태를 발생시킵니다. 이러한 문제를 진단하려면 Hang(정지) 상태의 WebLogic Server 인스턴스에서 5개 내지 10개의 스레드 덤프를 통해 Execute 스레드가 현재 SQL 호출에 참가하고 있는지, 그리고 데이터베이스의 결과를 기다리고 있는지 확인해야 합니다. 다음은 현재 SQL 쿼리를 보낸 스레드에 대한 스택 트레이스의 일반적인 예입니다.

"ExecuteThread: '4' for queue: 'weblogic.kernel.Default'" daemon prio=5 tid=0x8e93c8 nid=0x19 runnable [e137f000..e13819bc]
  at java.net.SocketInputStream.socketRead0(Native Method)
  at java.net.SocketInputStream.read(SocketInputStream.java:129)
  at oracle.net.ns.Packet.receive(Unknown Source)
  at oracle.net.ns.DataPacket.receive(Unknown Source)
  at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
  at oracle.net.ns.NetInputStream.read(Unknown Source)
  at oracle.net.ns.NetInputStream.read(Unknown Source)
  at oracle.net.ns.NetInputStream.read(Unknown Source)
  at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931)
  at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
  at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:375)
  at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1983)
  at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:1250)
  - locked <e8c68f00> (a oracle.jdbc.ttc7.TTC7Protocol)
  at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2529)
  at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2857)
  at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:608)
  - locked <e5cc44d0> (a oracle.jdbc.driver.OraclePreparedStatement)
  - locked <e8c544c8> (a oracle.jdbc.driver.OracleConnection)
  at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:536)
  - locked <e5cc44d0> (a oracle.jdbc.driver.OraclePreparedStatement)
  - locked <e8c544c8> (a oracle.jdbc.driver.OracleConnection)
  at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:80)
  at myPackage.query.getAnalysis(MyClass.java:94)
  at jsp_servlet._jsp._jspService(__jspService.java:242)
  at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
  at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
  at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:607)
  at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:400)
  at weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:154)
  at jsp_servlet._jsp.__mf1924jq._jspService(__mf1924jq.java:563)
  at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
  at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
  at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
  at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350)
  at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
  at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
  at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635)
  at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
  at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
  at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)


스레드는 실행 상태가 됩니다. 여러 스레드 덤프의 스레드를 비교하여 SQL 호출로부터 적절한 시간 내에 응답을 받는지 아니면 동일한 호출에서 장시간 Hang(정지)되어 있는지 확인해야 합니다. 스레드 덤프에서 SQL 호출 응답 시간이 너무 긴 것으로 확인되면 해당 데이터베이스 로그를 통해 이러한 성능 저하나 Hang(정지) 상태가 데이터베이스 문제 때문에 발생한 것인지 확인해야 합니다.

페이지 맨 위

느린 네트워크
WebLogic Server와 데이터베이스 간의 통신이 이루어지고 적절한 시간 내에 요청이 처리되기 위해서는 네트워크가 정상적으로 작동하고 안정적이어야 합니다. 따라서 네트워크가 느리면 SQL 쿼리의 결과를 기다리는 Execute 스레드가 Hang(정지)되거나 차단될 수 있습니다. 관련 스택 트레이스는 Hang(정지) 상태의 데이터베이스 단원의 예제와 비슷합니다. WebLogic Server 스레드 덤프만 분석해서는 SQL 쿼리가 Hang(정지)되거나 느려지는 근본 원인을 알 수 없습니다. 스레드 덤프는 SQL 호출의 성능에 문제가 있음을 파악할 수 있는 초기 징후라 할 수 있습니다. 다음 단계로 SQL 호출 성능 저하의 원인이 데이터베이스 문제인지 아니면 네트워크 문제인지를 확인해야 합니다.

데드락
데이터베이스 수준의 데드락과 응용 프로그램 수준의 데드락은 스레드를 Hang(정지) 상태로 만들 수 있습니다. 응용 프로그램 수준 데드락이 있는지 알아보려면 스레드 덤프를 확인해야 합니다. 이 작업을 수행하는 방법은 ServerHang - 응용 프로그램 데드락(Deadlock) 패턴을 참조하십시오. 데이터베이스 데드락은 데이터베이스 로그 또는 WebLogic Server 로그 파일의 SQL Exception을 통해 확인할 수 있습니다. 다음은 관련 SQL Exception의 예입니다.

java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource
  at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:170)
  at oracle.jdbc.oci8.OCIDBAccess.check_error(OCIDBAccess.java:1614)
  at oracle.jdbc.oci8.OCIDBAccess.executeFetch(OCIDBAccess.java:1225)
  at oracle.jdbc.oci8.OCIDBAccess.parseExecuteFetch(OCIDBAccess.java:1338)
  at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1722)
  at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1647)
  at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2167)
  at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:404)


일반적으로 데이터베이스에서 데드락이 감지되고 원인이 된 하나 이상의 트랜잭션을 롤백하여 데드락을 해결하기까지는 다소 시간이 걸리기 때문에 롤백이 끝날 때까지 하나 이상의 Execute 스레드가 차단될 수 있습니다.

RefreshMinutes 또는 TestFrequencySeconds
데이터베이스 성능 저하, SQL 호출 속도 저하 또는 최다 커넥션이 주기적으로 반복되는 경우 JDBC 커넥션 풀에 설정된 RefreshMinutes 또는 TestFrequencySeconds 구성 속성이 원인일 수 있습니다. 자세한 내용은 JDBC 문제 조사 패턴을 참조하십시오. WebLogic Server 인스턴스와 데이터베이스 사이에 방화벽이 없는 경우 외에는 이 기능을 사용하지 말아야 합니다.

풀 축소
새로운 커넥션 요청은 데이터베이스, 운영 체제 커널 및 WebLogic Server에 상당한 리소스 오버헤드를 발생시키므로 데이터베이스에 대한 커넥션을 한 번 열면 가능한 한 오랫동안 유지해야 합니다. 따라서 이러한 오버헤드를 최소한으로 유지하려면 운영 시스템에서 풀 축소를 사용하지 말아야 합니다. 풀 축소를 사용하면 유휴 풀 커넥션이 닫히게 되고 풀에서 커넥션 요청을 처리할 수 없는 경우에 다시 열립니다.

이와 같은 작업에는 다소 시간이 걸릴 수 있으므로 관련 응용 프로그램 요청에 시간이 예상 외로 많이 걸려 사용자가 시스템이 Hang(정지)되었다고 판단할 수 있습니다. JDBC 커넥션 풀 구성을 최적화하는 방법에 대한 자세한 내용은 JDBC 문제 조사 패턴을 참조하십시오.

페이지 맨 위

Hang(정지) 상태의 WebLogic Server 인스턴스 분석
Hang(정지) 상태의 WebLogic Server 인스턴스를 분석하는 방법에 대한 자세한 내용은 일반적인 서버 Hang(정지) 패턴을 참조하십시오.

시스템이 Hang(정지)되는 경우 대개 문제를 파악하려면 먼저 Hang(정지) 상태의 시스템에서 스레드 덤프를 확인하는 것이 좋습니다. 예를 들어 여러 스레드가 어떤 작업을 수행하고 있는지, 왜 Hang(정지)되었는지 등을 확인합니다. 일반적으로 스레드 덤프는 운영 시스템에서 생성할 수 있지만 오래된 JVM 버전(1.3.1_09 이전 버전)의 경우 스레드 덤프를 생성하는 동안 크래시가 발생할 수 있으므로 주의해야 합니다. 또한 WebLogic Server 인스턴스에 막대한 수의 스레드가 있는 경우 스레드 덤프를 완료하는 데 상당한 시간이 소요되고 그 동안 나머지 스레드가 잠기게 됩니다.

지연 시간이 몇 초 이내인 스레드 덤프를 두 개 이상(5-10개) 생성하십시오. 그러면 다른 스레드의 진행 상태를 확인할 수 있습니다. 또한 시스템이 실제로 Hang(정지)되어 작업이 전혀 진행되지 않거나 처리가 느려 시스템이 Hang(정지)된 것처럼 보이는 경우 이러한 내용이 표시됩니다.

스레드 덤프를 생성하는 방법에 대한 자세한 내용은 "일반적인 서버 Hang(정지)" 지원 패턴 또는 http://e-docs.bea.com/wls/docs81/cluster/trouble.html의 설명서를 참조하십시오.

또한 전체 WebLogic Server 인스턴스가 Hang(정지)된 것인지 아니면 응용 프로그램이 Hang(정지)된 것인지를 확인하십시오. 스레드 덤프를 분석하면 앞의 문제 발생 원인 단원에서 설명한 여러 가지 원인 중에서 인스턴스 Hang(정지)의 실질적인 원인을 알아낼 수 있습니다. 예를 들어 모든 스레드가 getConnection()과 같은 DriverManager 메쏘드에 있는 경우 근본 원인을 파악한 다음에 DriverManager.getConnection() 대신 DataSource 또는 Driver.connect()를 사용하도록 응용 프로그램을 변경해야 합니다.

Samurai라는 유용한 도구를 사용하여 스레드 덤프를 분석하고 여러 스레드 덤프 간에 스레드 진행 상태를 모니터할 수 있습니다. Samurai는 dev2dev 웹 사이트 http://dev2dev.bea.com/resourcelibrary/utilitiestools/adminmgmt.jsp에서 다운로드할 수 있습니다.

또한 dev2dev 웹 사이트 http://dev2dev.bea.com/products/wlplatform81/articles/thread_dumps.jsp에 있는 스레드 덤프 분석에 관한 백서를 통해 스레드 덤프와 서버 Hang(정지)에 대해 자세히 알아볼 수 있습니다.

페이지 맨 위

JDBC 코드 및 JDBC 커넥션 풀 구성 최적화를 위한 팁과 유용한 정보
JDBC 코드 개발 또는 JDBC 커넥션 풀 구성 시에 일반적인 문제 발생을 방지하고 리소스 사용량을 최적화하여 서버 인스턴스 Hang(정지)이 발생하지 않도록 하는 데 도움이 되는 몇 가지 모범 사례를 적용할 수 있습니다.

JDBC 프로그래밍
WebLogic Server에서 리소스 사용량을 최적화하고 데이터베이스 리소스를 절약하려면 응용 프로그램의 JDBC 호출에 JDBC 커넥션 풀을 사용해야 합니다. 응용 프로그램 코드에서 만들어지고 제거되는 커넥션은 불필요한 오버헤드를 발생시킵니다. JDBC 프로그래밍에 대한 자세한 내용은 http://e-docs.bea.com/wls/docs81/jdbc/rmidriver.html#1028977을 참조하십시오. 또한 JDBC 성능 조정에 대한 자세한 내용은 http://e-docs.bea.com/wls/docs81/jdbc/performance.html#1027791을 참조하십시오.

JDBC 코드 및 JDBC 리소스 사용량을 최적화하는 데 유용한 포괄적인 JDBC 관련 정보는 dev2dev Java Database Connectivity 페이지(http://dev2dev.bea.com/technologies/jdbc/index.jsp)를 참조하십시오.

JDBC 커넥션 풀 구성
JDBC 문제 조사 패턴에는 운영 환경의 커넥션 풀 구성에 대한 권장 사항이 나와 있습니다. Hang(정지)이나 성능 저하를 방지하려면 이러한 구성 팁을 고려해야 합니다.

페이지 맨 위

알려진 문제
사용하고 있는 WLS 버전의 릴리스 정보를 주기적으로 검토하여 서비스 팩에서 알려진 문제나 해결된 문제를 확인하고 JDBC 서버 Hang(정지) 관련 문제를 검색할 수 있습니다. 간편하게 다음을 참조하십시오.
드라이버가 현재 실행 중인 명령문이 반환될 때까지 기다려야 하기 때문에 특정 JDBC 커넥션에 대해 트랜잭션 롤백 호출이 바로 처리되지 않는 CR134921 오류는 WLS 8.1 SP3에서 해결되었습니다.

검색하면 릴리스 정보뿐 아니라 추가 도움말에서 언급된 기타 지원 솔루션 및 CR 관련 정보도 알 수 있습니다. 계약 고객은 http://support.bea.com/에 로그인한 다음 Browse 포틀릿에서 Solutions 및 Bug Central을 검색하여 제품 버전별로 사용 가능한 최신 CR을 찾을 수 있습니다.
:
Posted by 라면스프