|
WebLogic Server Administration Best Practices
by Balamurali Kothandaraman07/15/2004
Creating WebLogic Configuration/Domain
도메인은 단일 관리단위를 통해 관리하는 웹로직 서버 자원의 논리적 그룹입니다. 도메인은 모든 자원 및 응용프로그램의 정보를 XML기반으로 구성보관소에 저장합니다. 웹로직에서 응용프로그램을 배포하고 실행하기 위해서는 제일 먼저 도메인을 생성 하여야 합니다. 새로운 도메인의 생성을 위해서는 도메인 구성 마법사를 사용하기를 권장합니다. 도메인의 생성을 위해 스크립트를 사용한다면, 사일런트모드의 도메인 구성 마법사를 권장합니다. 웹로직 서버의 도메인은 함께 제공되는 OOB(Out of box) 도메인 템플릿이나, 사용자 정의 템플릿을 이용하여 생성할 수 있습니다.사용자 정의 도메인 템플릿을 생성하기 위해서는 구성템플릿빌더를 사용하시기 바랍니다. 이 프로그램은 단일모드의 자바 프로그램으로 사용자정의 구성 및 확장기능을 생성 할 수 있습니다. 도메인을 생성하거나 업데이트하기 위해서는 구성 및 기능 확장을 이용할 수 있습니다.도메인 구성 마법사의 속성:
·마법사는 구성 대상에 도메인을 생성하거나 확장하기 위한 전반적인 프로세스를 안내합니다.
·마법사는 OOB로 사전 구성된 도메임 템플릿이나 사용자 정의된 도메인 템플릿을 이용하여 도메인을 생성하거나 확장시킬 수 있습니다.
·마법사는 config.xml파일을 생성하여 기본적인 보안 사항 및 시작 스크립트등을 세팅하게 됩니다.
·마법사는 그래픽 모드, 콘솔모드, 사일런트 모드로 시작할 수 있습니다.
마법사를 그래픽 모드로 실행시키기 위해서는 다음과 같은 명령을 실행 합니다.:%BEA_HOME%\weblogic81\common\bin\config.cmd%BEA_HOME%\weblogic81\common\bin\config.sh도메인 구성 템플릿 빌더의 속성:
·마법사는 구성 템플릿(JAR 파일)을 생성하거나 확장하기 위한 전반적인 프로제스를 안내 합니다.
·구성마법사는 도메인 구성 템플릿의 생성뿐만 아니라 도메인의 생성까지 이용할 수 있습니다.
구성템플릿 빌더는 그래픽모드에서만 실행됩니다. 구성템플릿 빌더를 실행하기 위해서는 다음의 명령을 실행 합니다.:%BEA_HOME%\weblogic81\common\bin\config_builder.cmd%BEA_HOME%\weblogic81\common\bin\config_builder.shTips
·만일 웹로직 도메인과 구성이 복수의 물리적인 서버로 분산될 경우 도메인 구성 마법사는 관리서버가 있는 하드웨어에서만 실행 되어져야 합니다.
·매니지드 서버의 하드웨어에서 도메인 구성 마법사의 실행은 필요 하지 않습니다.
·웹로직 도메인은 웹로직 서버가 설치된 디렉토리의 외부에 생성하십시오. (기본 도메인은 %BEA_HOME%\user_projects\domains에 생성 됩니다. )
·관리서버를 시작 하기 위한 스크립트를 생성할 때에 스크립트(startWebLogic.cmd/sh)에서 도메인 디랙토리안의 Weblogic Server 클래스를 실행 시키지 못하면 –Dweblogic RootDirectory=path 명령줄 옵션을 추가하여 도메인의 위치를 지정하여 주십시요.
·매니지드 서버를 실행 시킬 때 (startManagedWebLogic.cmd/sh), -Dweblogic.RootDirectory 가 서버의 루트디렉토리로 설정이 되어 있다면 로그파일이나 관리서버 독립 구성 파일(MSI file) 도 그곳에 저장 될 것입니다.
Server Start-up관리서버의 모든 구성내역은 구성 저장소(config.xml)에서 불러 집니다. 모든 관련된 매니지드 서버는 기동시에 반드시 관리서버에 연결 되어 져야 합니다. 독립 관리서버는 구성 내역을 로컬 저장소(msi-config.xml)에서 불러 올 수 있습니다. 만약 웹로직이 Unix 시스템에서 실행이 된다면 루트유저 권한으로 실행 시켜야 하는 것을 피하기 위해 웹로직 서버프로세스에 UID 또는 GID를 할당 할 수 있습니다. 만일 웹로직 서버 사용자가 1024 보다 높은 포트를 사용한다면 루트 권한이 필요하지는 않습니다. Tips자동으로 서버를 기동하기 위한 스크립트를 작성하고자 한다면 다음의 사항들을 유념하여 주시기 바랍니다.
·도메인에서 관리서버는 관련된 매니지드 서버보다 먼저 시작 되어야만 합니다.
·관련된 매니지드 서버를 기동시킬때에는 매니지드 서바가 관리서버에 연결되어 구성을 다운로드 받을 수 있어야 합니다.
·매니지드 서버를 독립실행모드로 기동시키고자 할때에는 msi-config.xml 파일이 서버의 루트디렉토리에 올바로 위치하고 있는지 확인하여 주시기 바랍니다.
·유닉스환경에서는 로그아웃 한 뒤에도 서버가 백그라운드로 계속 실행 될 수 있도록 ‘nohup’ 을 이용하여 웹로직 서버가 기동 될 수 있도록 시작 스크립트를 작성하여 주십시오.
·OS에서 웹로직 서버를 설치하는 계정과 실행하는 계정을 분리하여 주십시오.
·Boot.properties 파일을 이용하여 사용자 정보를 암호화하여 보관하고,, 사용자 정보를 시작 스크립트에 하드코딩 하지 않도록 하여 주십시오.
·만일 유닉스 시스템에서 구성을 할 때 루트권한이 필요한 1024포트보다 낮은 포트를 사용코자 한다면 post Bind - UID 나 post Bind - GID를 할당하여 주시기 바랍니다,
·장비의 재 기동 후, 웹로직 도메인의 관리서버를 자동으로 기동시키고자 한다면 OS에서 제공하는 데몬 프로세스의 기능을 사용하십시오.
oWindows services
oUNIX daemon processes
·도메인 구성마법사를 통해 도메인을 생성할 때 도메인의 관리서버를 서비스로 만들 수 있습니다.
·또한 도메인 폴더에 위치해 있는 installservice.cmd 와 uninstallservice.cmd 스크립트를 이용하여 윈도우 서비스 컨트롤 매니저(SCM)에 추가하거나 삭제할 수도 있습니다.
·관리서버와 매니지드 서버가 동일한 장비에 있다면 관리서버와 매니지드 서버간에 OS차원의 서비스 종속성(Service dependency)을 설정하시기 바랍니다.
·적절한 런레벨에 Weblogic 기동 명령을 넣을 수 있도록 rc 스크립트를 구성하시기 바랍니다..
Startup and Shutdown Classes웹로직 서버는 시작 및 정상종료(graceful shutdown)시에 클래스를 구동시킬 수 있도록 구성할 수 있습니다. 시작 클래스는 서버가 모든 서브시스템을 초기화 시킨 후 클라이언트가 접근하기 위해 포트를 오픈하기 전에 불러져 실행 됩니다. 비슷하게 종료 클래스들도 서버가 정상종료(graceful shutdown) 프로세스를 시작하기 전에 불러지게 됩니다. Unlike application files startup and shutdown classes have to be manually made available in the deployed server's local classpath.Tips
·서버레벨의 시작 클래스는 웹로직 인스턴스가 시작되는 동안 배포될 수 있도록 시스템 클래스패스에 등록 되도록 하여 주십시오.
·한 도메인 안에서 시스템 레벨의 클래스는 관리서버에서 매니지드서버로 자동 배포되지 않습니다. 어플리케이션 레벨의 클래스는 같은 도메인 내의 관리서버에서 매니지드 서버로 배포될 수 있습니다.
·어플리케이션 레벨의 시작 클래스는 어플리케이션이 재배포 될 때 다시 불러 집니다.
·서버레벨의 시작 클래스는 동적으로 다시 불러지지 않고, 각각의 웹로직 서버가 재기동 될 때에만 다시 불러집니다.
·서버레벨의 시작 클래스보다는 어플리케이션 레벨의 시작 클래스를 사용하시기 바랍니다.
Node Manager웹로직 서버에서 제공되는 노드매니저는 매니지드서버를 자동으로 시작될 수 있도록 하거나 문제가 생긴 매니지드 서버를 재기동 시키기 위해 사용합니다. 노드매니저는 관리서버나 커맨드라인 명령어(Weblogic.Admin START)를 통해 매니지드서버를 원격으로 시작할 수 있도록 하여 줍니다. 이는 OS의 특정 원격 로그인 기능이 없이도 관리서버와의 통신을 통해 실행 됩니다. 매니지드 서버를 시작하거나 종료 시키는 기능 외에도 노드매니저는 노드매니저에 의해 실행된 서버들의 상태를 모니터링 할 수 있도록 하여 줍니다. 노드매니저가 설정이 되어 있으면 문제가 발생할 시에 자동으로 매니지드서버를 재시작 되도록 할 수 있습니다.Tips
·노드매니저를 사용할때에는 매니지드서버의 구성파일의 환경설정을 이용하기 보다는 remote-start 항목에 명시적으로 구성하시기 바랍니다..
·노드매니저는 요청을 관리서버에서만 받습니다. 관리서버가 동작하지 않는 상태에서 노드매니저를 통해 원격의 매니지드 서버를 재기동 시키는 것은 불가능 합니다.
·노드매니저를 서비스나 데몬으로 구성하십시오.
·매니지드 서버를 자동으로 재구동 시키도록 하여 주십시오.
·문제가 생긴 인스턴스를 내리는데 실패한다면 노드매니저가 재기동을 시도하기전에 자동 종료(auto kill)시키도록 구성하십시오.
·한 서버의 노드매니저는 해당 서버에 있는 복수개의 매니지드서버에 의해 함께 이용될 수 있습니다.
·하나의 노드 매니저는 또한 한 머신에 있는 복수개의 도메인에서도 함께 사용할 수 있습니다.
WebLogic Server Shutdown Process비정상적인 JVM의 종료는 소켓이나 세그먼트와 같은 리소스에 락이 걸리는 문제를 일으킵니다. OS상에서 웹로직 서버의 프로세스를 강제 종료 시키는 것은 비정상 종료에 해당합니다.
웹로직 서버는 다음과 같이 정상 종료(graceful shutdown) 시킬 수 있습니다.
·관리콘솔의 “Graceful Shutdown" 링크를 이용합니다.
·weblogic.Admin SHUTDOWN 명령을 이용합니다.
·JMX를 통해 ServerMBean 클래스의 stop 메소드를 구동 시킵니다.
Tips
·운영서버를 정상적으로 종료시키기 위해서는 웹로직 관리콘솔이나 weblogic.Admin 유틸리티를 이용합니다.
·정상종료는 사용자의 세션을 비정상적으로 종료시키지 않습니다. HTTP세션이 끝나거나 time out 되기를 기다린 후에 종료 됩니다.
·웹로직 서버는 세션을 무시하고 종료할 수 있도록 설정 될 수 있습니다.
·정상종료의 timeout은 조절 가능합니다. 기본설정은 모든 작업이 끝날 때까지 무기한 기다립니다.
·만일 정상종료요청이나 서버를 내리는 요청에 응답하지 않고 대기 상태로 있다면 강제 종료(Force Shutdown)시켜 주십시오.
·데몬으로 설정시에 rc 스크립트에 서버의 리부팅이나 종료시에 웹로직이 정상 종료 될 수 있는 항목이 설정되어 있는 지 확인하시기 바랍니다.
·노드매니저가 설정되어 있을때, 노드매니저를 중지한다고 해서 노드매니저에 의해 구동된 서버들이 종료 되지는 않습니다. 매니지드 서버들은 제 각기 종료 시켜 주어야 합니다.
Backup and Recovery장애에 대비하여 웹로직 도메인은 마이그레이트 시키거나 복구하기 위해 정기적으로 관리 서버와 전체 도메인 디렉토리를 백업하여야 합니다. 이경우 하드웨어나 시스템 장애시에도 단지 도메인 디렉토리를 복원함으로써 관리서버를 구동시킬 수 있게 됩니다. 관리서버의 장애에 대비하여 관리서버는 운영중인 매니지드서버들의 모든 정보를 running-managed-servers.xml 에 보관하고 있습니다. 재기동시에 관리서버는 이 파일을 읽어 기존에 운영중인 매니지드 서버와 접속을 시도 하게 됩니다. 탐색모드는 기동중인 매니지드서버가 없다면 초기 기동시간을 증가시킵니다. 하지만 언제나 탐색모드를 사용합니다.
관리서버에서 정기적으로 기본적으로 관리/백업되어야 할 중요 파일들입니다.
·config.xml도메인 구성 저장.
·config.xml.booted성공적으로 수행된 깨끗한 도메인 구성 백업 파일.
·boot.properties관리서버를 기동시키기 위한 암호화된 유저네임과 암호.
·running-managed-servers.xml현재 동작중인 매니지드 서버의 리스트. 매니지드 서버가 운영중에 관리서버가 재시작 되었을 때 매니지드 서버를 탐색하기 위한 용도로 사용.
·domain/configArchive/도메인 구성파일들의 복사본들이 들어 있음. 관리툴을 이용하여 관리서버를 업데이트할 때 기존의 config.xml 파일을 복사함.
·domain\adminserver\ldap\ldapfiles도메인의 관리서버에 의해 사용중인 Embedded LDAP 데이터 파일.
·*.ldift files웹로직 도메인의 LDAP서버를 도메인 생성시로 되돌릴 경우 사용되는 파일들.
·domain/adminserver/ldap/backup/EmbeddedLDAPBackup.zip웹로직 도메인의 내장 LDAP 서버의 백업. 내장 LDAP 은 myrealm의 보안 제공자(security provider)인 기본 보안 영역(realm)의 사용자, 그룹, 롤, 정책들을 보관합니다.
·Batch/Shell ScriptssetEnv.cmd/sh, startWebLogic.cmd/sh, startManagedWebLogic.cmd/sh.
Scripting Administration Tasks도메인 구성을 관리하기 위한 스크립트를 생성하기 위해서는 :
·Weblogic.Admin 유틸리티의 배치파일의 커맨드를 순차적으로 실행시켜주는 BATCHUPDATE 커맨드를 사용하십시요. 이 커맨드는 모든 명령어들이 하나의 JVM에서 실행되도록 하여 줍니다.
· -Dweblogic.system.BootIdentityFile 옵션을 사용하여 사용자이름과 암호가 텍스트 스크립트안에 하드코딩 되지 않도록 하여 주십시오
·Operating System의 스크립트내에 작성시에는 weblogic.Admin 커맨드의 아래 내용을 이용하여 반환값을 검토하도록 하십시오.
o%ERRORLEVEL% (Windows)
o$? (bash shell)
·weblogic.Admin의 –adminurl 옵션으로 관리서버에서 매니지드서버의 MBeans 구성과 MBeans 의 런타임값을 추출합니다.
·config.xml 파일을 직접 수정하는 것은 권장하지 않습니다.
·만일 config.xml을 수정해야만 한다면, 아래의 사항에 유념하시기 바랍니다.
o수정하기 전에 우선 원본파일을 백업 하여 두시기 바랍니다.
o오류를 방지하기 위해 XML 에디터를 사용하시기 바랍니다.
o관리서버가 동작중에 수정하지 않도록 하여 주시기 바랍니다.
·구성 정보를 만들고 이를 빌드작업을 통합할 시에는 wlconfig Ant 작업을 사용하시기 바랍니다.
·관리서버가 동작중이거나 멈추어져 있을 시에 도메인 구성을 변경하고자 할 경우에는 WebLogic Scripting Tool (WLST)을 이용하시기 바랍니다. (dev2dev.bea.com)
·WLST는 웹로직 서버로의 강력한 쉘 환경을 제공하며 스크립트 Jython을 사용합니다.
·WLShell 유틸리티와 같은 서드파티 프로그램을 이용하여 구성을 관리할 수도 있습니다. (www.wlshell.com)
·WLShell은 웹로직 서버로 유닉스 쉘과 비슷한 인터페이스를 제공합니다. 웹로직 서버 MBean 을 위한 유사 파일시스템을 사용합니다.
Logging로그는 서버의 시작과 종료, 새로운 어플리케이션의배포, 서브시스템의 장애와 같은 이벤트 정보를 기록합니다. 로그 메시지는 이벤트를 발생시킨 사용자의 ID 뿐만 아니라 시간, 날짜의 정보도 포함합니다. 각 웹로직 서버 인스턴스는 서버로그, HTTP 접근 로그, JDBC로그 및 JTA로그를 따로 관리 할 수 있습니다.Tips
·로그파일이 너무 커져서 서버가 재 실행 되는 것을 방지하기 위해 로그 로테이션기능을 사용하십시오.
·정해진 시간에 파일이 급속히 증가되는 경우가 있을 수 있으므로 로그 로테이션은 시간기준이 아닌 사이즈 기준으로 시키는 것을 고려하시기 바랍니다.
·상호작용으로 디버깅을 하지 않고, 웹로직 서버를 백그라운드 서비스(윈도우나 유닉스)로 구동시킬 경우, 아래 명령을 사용하여 stdout 과 stderr 메시지를 파일로 리다이렉트 시킵니다.
o-Dweblogic.Stdout="stdout-filename"
o-Dweblogic.Stderr="stderr-filename"
·운영모드에서는 JDBC의 로그를 하지 않음으로써 서버의 추가적인 파일 I/O를 피할 수 있습니다.
·노드매니저를 통해 매니지드서버를 기동시킬 경우, 노드매니저는 서버의 stdout을 캡처하여 파일로 보관합니다. 관리콘솔을 통해 해당 파일의 내용을 볼 수 있습니다.
·웹로직 서버의 로그파일을 수시로 점검하시어 평상시의 내용에 익숙해 지도록 하면 비정상정인 로그내역을 쉽게 파악할 수 있습니다.
JDBC웹로직 서버에서 데이터베이스로 JDBC 컨넥션의 풀링은 어플리케이션의 성능을 향상시킵니다. 컨넥션 풀은 어플리케이션 별로 새로운 데이터베이스로의 컨넥션을 만드는 과정을 없애 줍니다. JDBC 컨넥션 풀은 사용하고자 하는 데이터베이스로의 바로 사용가능한 컨넥션을 제공해 줍니다.컨넥션 풀을 사용할 경우 데이터베이스로의 컨넥션 수는 동적으로 조절됩니다. 하지만 데이터베이스의 컨넥션 생성에는 많은 자원이 필요하게 되므로, 로드가 많은 상황에서 JDBC 컨넥션이 증가 되는 경우 상황을 더욱 나쁘게 만들게 됩니다.컨넥션풀은 prepared statements와 callable statements를 재사용하기 위해 캐싱하여 성능을 증가 시킵니다. prepared statements와 callable statements의 재사용은 데이터베이스 서버의 CPU사용을 줄여 줍니다.서로 다른 어플리케이션은 다른 장비나 하드웨어로 나누어 웹로직 서버장비의 프로세싱이 떨어지지 않도록 하고 데이터베이스는 독자적인 서버를 이용하여 주십시오. Tips
·가능하다면 데이터베이스 컨넥션 풀의 사이즈를 초기값과 최대값이 같도록 설정하여 컨넥션수가 절대 증가하지 않도록 하시기 바랍니다.
·컨넥션의 최대값은 적어도 실행스레드 큐의 수와 같도록 설정하시기 바랍니다.
·컨넥션이 풀에서 다시 사용되기 전까지 몇 초 동안 비활성상태로 있을 수 있을 지를 정하여 비활성 연결 타임아웃시간을 설정하십시오.
·컨넥션 릭 플로파일링 옵션은 컨넥션풀에서 릭이 생기는 연결을 보여줍니다. BEA에서는 운영환경에서는 이 옵션을 사용하지 말 것을 권장합니다. 이 옵션은 아주 많은 자원을 사용하고, 컨넥션 풀의 동작을 느리게 합니다.
·일반적인 질의수행을 의한 컨넥션 테스트를 사용하려면 Test Reserved Connections 만 사용하십시오.
·"Test Table Name"에 실제 사용할 테이블을 사용하지 말고 dual과 같은 더미 테이블을 사용하십시오.
·prepared 와callable statements 의 성능을 향상 시킬 수 있도록 statement 캐시를 사용하십시오.
·캐시에는 LRU (least-recently-used) 알고리즘을 사용하십시오. 이 알고리즘은 캐시에서 사용 빈도가 낮은 statement를 제거하는 알고리즘입니다.
·Connection Creation Retry Frequency 는 컨넥션풀을 생성하거나 웹로직을 기동시킬 시 DB에 연결하지 못할 경우 DB로의 컨넥션을 재시도할 때 사용 됩니다.
·웹로직이 동작중에 데이터베이스가 재시작 하게 되면, Test Frequency는 0에서부터 증가될 수 있습니다. 이때 모든 커넥션은 종료되고 물리적으로 연결이 가능한 커넥션을 다시 맺게 됩니다. 모든 커넥션이 재생성되면 Test Frequency는 0으로 돌아가고 테스트는 중지 됩니다.
·커넥션 풀의 사용을 위해 DataSource를 이용한다면 TxDataSource 의 생성을 위해 Honor Global Transaction 옵션을 사용하십시오.
·Non-Tx DataSource를 사용하는 경우는 현재의 트랜잭션을 포함하기를 원치 않는 데이터 베이스 작업이 필요할 경우 뿐입니다.
·웹로직의 JMS JDBC 공간으로 커넥션 풀을 사용할 시에는 non-XA 데이터베이스 드라이버로 설정하십시오.
JMS웹로직서버의 JMA아키텍처는 웹로직 하나의 도메인에 복수의 JMA서버를 생성할 수 있도록 되어 있습니다. 하지만 가각의 JMS서버는 오직 하나의 서비스로 하나의 웹로직 서버를 통해서만 초기화 될 수 있습니다. 하나의JMS서버는 복수의 목적지를 가질 수 있습니다. 영구 저장소(디스크기반의 파일이나 JDBC를 통한 데이터베이스)는 영구적인 메시지 데이터만을 저장 할 수 있습니다. 만일 하나의 JSM가 복수의 목적지를 저장하여야 한다면 목수의 목적지를 하나의 JMS 안에 설정하십시오. 하지만 각 목적지별로 나누어 저장하고자 한다면 복수의 JMS 서버 아래에 만드셔야 합니다.Tips
·JMS 파일 스토어가 가상메모리를 풀어줄 수 있도록 direct-write synchronous write 정책을 사용하십시오. 하지만, direct-write는 동시 JMS 클라이언트의 수가 많지 않을 경우에만 성능이 많이 향상 됩니다.
·파일 저장소를 별도의 디스크로 분리하거나 별도의 디스크 컨트롤러에 위치 시키십시오.
·파일 저장소의 고가용성을 위하여 SAN(Storage Area Network) 나 멀티포트디스크, 또는 디스크 미러링등을 사용할 수 있습니다.
·JMS JDBC 저장소를 위한 커넥션풀에 XA JDBC 드라이버를 사용하지 마십시오. JMS JDBC 스토어는 XA 리소스 다라이버를 지원하지 않습니다. 웹로직 JMS는 고유의 XA자원을 사용합니다.
·Expiration Scan 간격을 이용하여 목적지를 스캔하여 기간이 만료된 메시지들이 가상머신에서 제거되도록 하십시오. 하지만, 너무 잦은 스캐닝은 스캐닝 오버헤드가 발생할 수 있습니다. 적절하게 조절하여 사용하십시오.
·커넥션 팩토리의 MessagesMaximum 를 설정하여 비동기 메시지 파이프라인의 사이즈를 조절하십시오.
·메시지 빌드업을 방지하기 위해 Time To Live 값을 커넥션 팩토리 수준에서 설정하십시오.
·운영모드에서는 기본 JMS 커넥션 팩토리를 disable 시켜 놓고 어플리케이션별 JMS 커넥션 팩로리를 설정하십시오.
·각기 다른 JMS서버에 설정된 물리적으로 다른 목적지에 대한 JMS메시지간의 로드밸런스를 위해서는 분산 목적지(distributed destination)를 설정하시기 바랍니다.
·분산 목적지를 배포할때에는 클러스트안의 각 JMS 서버와 member destination 의 설정을 유사하게 하십시오.
Message Paging퍼시스턴트와 논퍼시스턴트 메시지는 페이징이 설정되어 있지 않는한 서버 메모리를 사용하게 됩니다. 메시지 페이징은 퍼시스턴트 메시지 캐시가 메모리에 있더라도 퍼시스턴트 및 논퍼시스턴트메시지를 위한 서버의 메모리를 풀어주는 프로세스입니다. 페이지 아웃된 메시지는 사용한 메모리를 풀어주지 않습니다. 메시지헤더와 메시지 속성은 검색, 정렬 및 필터링을 위해 메모리에 남아 있게 됩니다. 트랜잭션의 세션에서 보내지는 메시지는 해당 세션이 커밋 된 후에만 페이징 될 수 있습니다. 그 전에는 메시지가 메모리에 있게 됩니다.Tips
·JMS 페이징이 설정되어 있지만 페이징 공간이 설정되어 있지 않다면, WLS 8.1은 페이징 공간을 자동으로 생성합니다. 하지만 페이징 공간을 명시적으로 설정하기를 권장합니다. (공간의 위치를 임의대로 설정할 수 있습니다.)
·JMS 페이징을 통해 JVM의 힙 사이즈를 증가시키지 않아도 웹로직 서버인스턴스가 가질 수 있는 메시지 데이터의 양이 증가 됩니다.
·비록 페이징을 통해 퍼포먼스가 떨어지기는 하지만, 그 영향은 퍼시스턴트 메시지를 페이징 할때보다 논퍼시스턴트 메시지를 페이징할 때 줄어듭니다.
·웹로직 JMS서버의 쿼터를 항상 설정하십시오. 쿼터를 통해 메시지가 서버의 메모리를 넘어서게 되는 것을 방지하게 됩니다.
Flow ControlJMS 서버를 설정한 후에 하나또는 그 이상의 커네션팩토리를 설정하여 사전에 정의된 값과 함께 커넥션을 생성 할 수 있습니다. Flow Control 기능을 이용하여 JMS 서버 또는 목적지에 부하가 걸리기 시작했다고 판단될 시에 메시지 발생을 느리게 떨어트릴 수 있습니다.
Tips
·부하가 걸리는 웹로직 외부의 프로세스의 대상에 메시지 생성을 줄이도록 플로우 컨트롤을 설정하십시오.
·서버내에 플로우 컨트롤을 설정할 때에는 서버 쓰레드의 수행도 느리게 하지 않도록 주의 하시기 바랍니다.
Deployment웹로직 서버는 단일의 배포용 묶음파일이나 묶음 파일의 내부 구조대로 구성된 디렉토리 구조 형태로 배포단위의 저장이 가능합니다. 묶음 파일은 모든 어플리케이션과 모듈의 클래스, 정적파일, 디렉토리 배보 설명파일들이 하나의 파일에 포함합니다. 사용자 응용프로그램은 매니지드 서버 인스턴스에 배포하십시오. 이렇게 함으로써 관리용 어플리케이션 (관리콘솔)과 도메인 설정을 사용자 응용프로그램과 분리시킵니다. 운영모드와 다중 서버 환경에서 자동 배포기능을 사용하지 마십시오. 웹로직 도메인이 운영모드로 동작중일때에는 자동 배포기능이 비활성화 됩니다. 만일 전체 구성상에 스크립트를 생성하여 응용프로그램을 배포한다면 wldeploy Ant 태스크를 사용하십시오.
만일 어플리케이션이나 모듈을 배포할때 On Future Redeploys 옵션으로 한다면 Initialize Roles and Polices From DD 로 설정하기 전에 Ignore Roles and Policies Form DD one or more times로 설정하십시오. Security policies 와 security roles 는 관리 콘솔을 통해 설정할 수 있습니다. 하지만 이러한 관리콘솔을 통한 변경은 배포 디스크립터에 정의된 내용을 오버라이드하게 됩니다. Tips
·Use production mode to run production applications.
·Avoid deploying user applications on admin server instance.
·To specify the server's default Web application, use an empty context-root element or an element with a value "/" in the weblogic.xml or application.xml file.
·Changing security policies for an application after deployment in the admin console overrides the policies in the deployment descriptor.
RedeploymentOnce you deploy an application, you can redeploy the application itself or selected parts of the application. Redeploying an entire application involves unloading all its classes and then deploying the application again with the changed files. Redeploying an application in production is a serious undertaking that can affect performance, so plan application updates carefully.If a Web application is in production and in use, redeploying causes WebLogic Server to lose all active HTTP sessions. HTTP session can be restore by turning a special property ON in the WebLogic specific deployment descriptor file (weblogic.xml).Tips
·If you have modified only static files, it is possible to refresh them without redeploying the entire application.
·Use command-line option to partially redeploy an expanded application (weblogic.Deployer … -redeploy <files>…).
·For changing deployment parameters without changing the application, use alternate deployment descriptors.
·To simplify re-distributing application archives to multiple WebLogic Server instances during redeployment use stage mode deployment.
·A managed server with all application staged can be started and be made fully functional in independence mode if admin server is not available.
Enterprise ApplicationWebLogic optimizes EJB access, if the client is within the same enterprise application classes and libraries can be shared across all archive applications within the enterprise application. So consider creating enterprise archives rather than deploying related applications independently. Also Enterprise-wide settings can be used, rather than multiple local settings in deployment descriptors. Create JDBC resources in the WebLogic Server domain, using the WebLogic console, rather than employing the weblogic-application.xml technique.Tips
·Avoid deploying EJB archives and related Web applications as separate independent applications in WebLogic Server.
·Improved runtime performance can be achieved when Web components access EJB components within the same enterprise application.
·The enterprise can be deployed as one deployment unit.
·Do not place application-specific classes or JAR files in the system classpath (to avoid having to restart the server for reloading them).
·When using WebLogic Server 8.1, use the new APP-INF/lib and APP-INF/classes directories in the enterprise-application directory structure, to simplify the packaging of utility classes and utility archives.
Pre-compilationProduction and test deployments should include precompiled JSP pages and EJBs (use weblogic.appc or weblogic.jspc/weblogic.ejbc with earlier weblogic versions). They can catch compile-time errors in applications long before you deploy them. Also offline compilation validates the deployment descriptors for compliance with current specifications. Deploying compiled applications reduces deployment time and subsequent server restart time. Development deployments intended for use on the developer's workstation can use on-the-fly compilation.Tips
·To precompile JSP files during application deployment or server startup, enable the precompile parameter in weblogic.jar.
·To disable pagecheck and recompilation at runtime in a production environment, set pageCheckSeconds to -1.
·You can use weblogic.appc or weblogic.ejbc (deprecated) to compile EJBs outside the server VM. This reduces the subsequent server restart time.
·Use the weblogic.Deployer utility, or its associated Ant task, wldeploy, in scripts to automate deployment in production environments.
Deployment Descriptor EditingChanging the deployment descriptor of a J2EE application takes effect only when the application is redeployed. The WebLogic admin console provides a way to change some deployment descriptor attributes without redeploying the application. To take advantage of this feature, you must to deploy the application in exploded directory structure (non-archived format), when the domain is running in development mode.To change descriptor values of the application after deployment (as exploded format) go to Web Application Module > Your Application > Configuration tab > Descriptor tab.Tips
·Use tools provided with WebLogic Server to generate and edit XML deployment descriptors.
·WebLogic Builder generates descriptors; it includes an interface for editing descriptors.
·DDInit is a command-line utility for generating deployment descriptors for WebLogic Server applications.
·ddcreate is an Ant task that can be used for creating deployment descriptors for enterprise applications.
EJBA stateless session EJB free pool improves performance and throughput as beans are created at server startup or deployment time. WebLogic Server uses a cache of bean instances to improve the performance of stateful session EJBs. The cache stores active EJB instances in memory so that they are immediately available for client requests.Using application-level/combined cache will result in reduced fragmentation, better utilization of memory and heap space. But the use of application-level/combined cache is limited to entity EJBs in an enterprise application. For an application that requires high throughput, use bean-level caching. Bean-level caching is effective because tasks do not compete for control of the one thread of control in a combined cache.To make use of WebLogic provided optimization of calls made to EJB components within an application, set <enable-call-by-reference> to true.The same can also be achieved by writing local interfaces for EJBs for access within the same enterprise application.Concurrency strategies for entity EJBs include:Database:Improves throughput by deferring to database (for EJB 1.1 and 2.0, this is the default and recommended mechanism)Exclusive:Avoids deadlocks; use it only if a high level of consistency is required on non-clustered serversOptimistic:No lock will be held in the EJB container or database during transaction. But the EJB container ensures that the data being updated by a transaction has not been changed.Read-only:Container does not attempt to save a bean's state at the end of a transaction; use this for EJBs that do not make any change to persistent data. With the read-only strategy, use <read-time-out-seconds> to invalidate cached bean data in the container; this updates the data from the persistent store when a timeout occurs.Tips
·Consider the number of execute threads, to configure maximum number of beans in the free pool.
·To limit the memory used by a stateful session EJB, set the maximum number of beans that can reside in the cache (max-beans-in-cache).
·Too small cache causes frequent activation and passivation.
·Too large a cache wastes memory.
·LRU algorithm keeps a bean in the passive state after it passes the ideal number timeout seconds.
·To avoid the associated overhead of passivating stateful session EJBs, use the not recently used (NRU) algorithm
·Local interfaces for EJBs provide optimized access for server-side EJB clients.
·Combined cache enables the administrator to tune just one cache, rather than multiple caches, in weblogic-application.xml.
·Message-driven beans that use container-managed transactions must use XA connection factories.
SecurityNever use development mode for production servers; development mode relaxes the security constraints for all servers in a domain. When using compatibility security, disable guest logins in production, so that guest logins cannot be used to access WebLogic resources in a WebLogic Server domain.When you are creating a security policy, if inherited policy statements are present in the Inherited Policy Statement box of the Policy Editor page, the new policy overrides them. Changing a security policy defined in a J2EE deployment descriptor requires redeployment; changing an embedded LDAP policy in the admin console is dynamic. Configure additional administrative users to roles such as admin, deployer, monitor or operator.SerializedSystemIni.dat contains hashes for the passwords in a domain; ensure that you store a copy of this file in a safe place. Give read privileges for SerializedSystemIni.dat only to the WebLogic system administrator account. If you lose the administrative password, and the boot identity is not stored in the form of boot.properties file, you cannot restart servers.Tips
·Store the encrypted boot identity of the user who has privileges to start WebLogic Server in the boot.properties file.
·BEA recommends using security roles (rather than users or groups) to secure WebLogic resources; first assign users to groups, then create role statements.
·Do not install or run WebLogic Server software as root. If you must bind to a privileged port, use post-bind UID or post-bind GID in the WebLogic machine configuration.
·Set the ownership of the WebLogic installation and applications directory for access only by the user account that runs the server.
Recovering Administrator PasswordWhen using the default authenticator, if you have not modified the global admin role (which, by default is granted to the administrators group), you can recover the administrator password in a WebLogic domain.To recover the administrator password in a WebLogic domain:
·At the command line, change directory to the domain and run the setEnv script to set the PATH and CLASSPATH.
·Backup the existing DefaultAuthenticatorInit.ldift file in a different directory.
·java -cp D:\bea\weblogic700\server\lib\weblogic.jar weblogic.security.utils.AdminAccount adminuser weblogic . (Be careful: there is a dot at the end of the command).
·rm myserver/ldap/DefaultAuthenticatormyrealmInit.initialized
·rm boot.properties (if any)
·Reboot the admin server with "adminuser" as administrator userid
·After the server has successfully booted, delete the new DefaultAuthenticatorInit.ldift file and replace it with the backed up file.
If you don't perform these steps in the correct sequence or if you create a DefaultAuthenticatorInit.ldift file by hand, a cleartext password may be available.
SSLWhen using SSL with WebLogic Server, use keystores; storing identity (private keys and certs) and trust (CA) in files is deprecated. Migrating from an earlier version might require you to create keystores from private keys, certs, or trust files.If the network that connects WebLogic Server in a domain is not trusted, enable SSL on each server in the domain, so that LDAP replication between the admin server and managed servers uses SSL connections. Enabling an administration port in the domain requires that all servers use SSL.The default WebLogic installation represents exportable-strength SSL implementation (the maximum SSL strength is 512-bit keys with 40-bit bulk encryption). Key lengths longer than 512 bits require a domestic-strength SSL license key from BEA. If you use SSL in your production environment, use high-strength SSL. Key lengths of less than 1024 bits are generally considered weak.SSL hardware accelerators: Running SSL on the WebLogic servers is a tremendous drain on server resources. By offloading SSL processing, the resources can be applied to WebLogic functions. Web servers, load balancers, firewalls, or switches can handle SSL processing.Filtering them can control incoming connections in WebLogic Server. WebLogic Server provides a default implementation of connection filter that you can configure in the admin console.Tips
·In production, do not use the sample SSL certificates that are provided with WebLogic.
·To avoid compromising application security, install and configure server-specific SSL certificates and enable hostname verification on production servers.
·Use SSL with WebLogic Server only if it is necessary. SSL degrade performance.
·To control the types of connections accepted by WebLogic Server instances, use connection filters.
·Use load balancer with built-in secure sockets layer (SSL) support, or run WebLogic Server on a machine that has SSL hardware, with Java Cryptography Extension (JCE)
Securing Admin ConsoleIf you use the admin server to serve applications (or in a single-server domain), do the following for better security:
·Change the default admin user and password to custom.
·Change the admin console context root path.
·Enable domain-wide administration port.
·Consider disabling the admin console.
If you use an external LDAP provider, store the server boot identity in the embedded LDAP server, and set time-outs on the external LDAP authentication provider. This way, if the external LDAP server is unavailable, you can continue to restart and to serve unprotected data with WebLogic Server. Also before you apply any changes, set the control flag for all authentication providers to OPTIONAL; this prevents a configuration error from causing a production server not to restart.WebLogic Server provides a custom realm, the NTRealm, based on older security realm APIs, that supports native Windows domain authentication. NTRealm is useful with Windows domains that are not set up to use Active Directory.Tips
·Store the server boot identity in the embedded LDAP server.
·For finer control of a production environment, use Active Directory authentication, rather than native Windows domain (NTRealm) authentication.
·To prevent denial-of-service attacks, modify the time-out and maximum-size values for the incoming protocol ports (T3, COM, IIOP, HTTP Post time out) on the server.
·Have a security audit performed by an internal or external auditing group.
ClusteringWebLogic cluster is group of managed servers from a domain that will act in a coordinate fashion to provide a single server view for the client. Use WebLogic clusters to improve efficiency, scalability, load-balancing and failover. WebLogic cluster is a process level cluster, where the participating servers can be on a different physical machine or on the same machine. IP Multicast is the backbone for exchanging heart beat signals in a cluster. So make sure multicast traffic is enabled in the WebLogic Server network.Tips
·If you use Web Server proxies, configure at least two, to avoid a single point of failure for the cluster.
·When porting an application from one WebLogic Server to a cluster, ensure that objects stored in an HTTP session are able to serialize.
·Put at least three WebLogic Server instances in each cluster, so that failure of a server does not stop load balancing of the cluster.
·You cannot add the admin server to a cluster.
·Use separate multicast address for each cluster in a network.
·Servers running in a cluster can listen on different ports from WebLogic Server 7.0
·If available use separate hardware (NIC) to route cluster multicast traffic by configuring network channels to separate internal cluster traffic from outside client traffic for better performance.
·Combine frequently accessed applications in one tier of clusters (ex. war and EJB jar) to avoid network traffic.
·To enable automatic failover of servlets and JSP, use replication technique.
·In-memory replication is faster than other type of replications.
·When using in-memory replication, specify the machine information for servers in a cluster.
·Define replication groups only if you require control over the secondary selection process.
·Using server affinity wherever possible will improve performance.
·Use publicly available DNS names to identify the WebLogic Server instances rather than using IP addresses in firewall-enabled environments.
·If a WebLogic cluster spans multiple sites, the network among the sites must support multicast traffic for cross-site clustering.
·With this spanning architecture, you must configure the cluster's Multicast TTL value high enough to prevent routers from dropping multicast packets before they reach their destinations.
ThreadingTo improve WebLogic Server performance, use native I/O (performance pack) if available. To ensure that the performance pack is initialized correctly, check for errors at startup.Execute queues can be set to automatically increase the threads during overflow condition. But avoid using the server's capability to increase the number of execute threads to manage normal application-load peaks. Rather, do careful capacity planning and server tuning; select an optimal number of execute threads.Tips
·Tune the execute thread count only if the CPU is not running at 100% utilization yet client requests are blocked and rejected too often.
·When tuning the thread count, stop when throughput starts dropping or CPU utilization drops or stays constant.
·Do not set the Stuck Thread Max Time and Stuck Thread Time Interval so low so that normal requests during peak processing time are mistaken for stuck threads.
·To partition application components or to provide a dedicated amount of resources to one component, create user-defined execute queues. Using custom execute queues also avoids potential cross-server deadlock situations.
·To provide a dedicated resource to message-driven beans, use a separate execute queue for each message-driven EJB that is deployed.
·When troubleshooting deadlocks and long-running requests on WebLogic Server, use a series of properly spaced thread dumps to determine the possible causes.
·Enabling T3 protocol access over HTTP by tunneling degrades performance by approximately 15%; avoid tunneling T3 over HTTP.
Testing Tips
·During capacity planning and testing, plan for the peak load that an application might incur.
·Optimize the application during testing; typically, on WebLogic Server, applications are the most-limiting factor in performance and capacity.
·When you put a system under stress to test performance, use appropriate, realistic test cases.
·The closer the test cases are to production situations, the more accurate the test results are.
·When benchmarking applications, ignore the first few samples; run test samples to "warm up" the server VM.
MonitoringUse operating-system-specific monitoring tools to observe thread activity and context switching. For example, on Solaris, you can use mpstat, prstat, top to monitor CPU utilization. mpstat exposes CPU utilization, thread interrupts, and voluntary and involuntary context switches. top will help you to find the processes that are using up the CPU.WebLogic administration console can be used for monitoring running servers, server threads, JVM heap usage, log files, clusters statistics etc. Enabling SNMP monitoring can leverage the existing SNMP monitoring framework, to monitor your WebLogic domain resources through the central admin server.Section 1.01: Third-party monitoring tools can also be used to monitor application, system resources used by WebLogic Server (Ex. spotlight from Quest, Acsera from Acsera Corporation etc.).Tips
·An SNMP agent is an integral part of the admin server in a domain, so admin-server instance failure can become a bottleneck.
·To monitor WebLogic runtime MBeans, you can use JMX monitoring tools, in addition to the admin console.
JVMUse JVMs, which provide better performance for server side applications (ex. JRockit). Administration console can be used for monitoring JVM heap usage graphically.For better performance, test with JVM-vendor-specific options.For example, these are typical "hotspot" VM options that you can set:-XX +AggressiveHeap - uses heaps that are nearly as large as the total physical memory-XX +UseISM - uses intimate shared memory (Solaris)AggressiveHeap warnings:1. Use all available memory2. Incompatible with -Xms -Xmx3. The heap might may steal memory from the stackIntimate shared memory warnings (for Solaris only):1. Lock memory; use only on dedicated systems2. Memory fragmentation can prevent allocation of contiguous 4 MB pages3. Abnormal JVM termination can result in locked segments4. To discover and delete locked segments, use ipcs and ipcrmTips
·Do not set the server's heap size larger than the available free RAM on a machine.
·For high performance and throughput, set the minimum JVM heap size equal to the maximum heap size.
·WebLogic Server's logging feature for low memory condition can be used to sample the available free memory to detect low memory conditions.
·When monitoring garbage collection, if the heap always settles to 85% free, try reducing the heap size.
·When setting -noclassgc make sure the perm size is set greater than the default value (32mb).
·Avoid using the -verbosegc option during production run.
·Use parallel garbage collection algorithms with multiple CPU machines to reduce the garbage-collection pause time.
·On Intel-based architectures, for better performance, configure WebLogic to use the JRockit virtual machine.
·To discover and delete locked segments, use ipcs and ipcrm.
|