/usr/lpp/diagnostics/bin/usysfault  -s  normal
반응형

cron 은 일정시간마다 시스템이 자동으로 실행시키는 데몬이다.
crontab 은 cron 등록,삭제등의 작업을 한다.

// cron 데몬의 시작/종료/상태/재시작... 등
/etc/rc.d/init.d/crond [start/stop/status/restart ...]

// crontab 데몬에 등록된 목록 보기
crontab -l

// crontab 에 등록된 내용 편집
crontab -e

// crontab 설정 방법(space로 구분)
분(0~59) 시(0~23) 일(1~31) 월(1~12) 요일(1:월요일~7:일요일) 실행 할 명령어

// 매월 10일 0시 마다 test를 실행하려면
0 0 10 * * /home/ysoftman/test

// 2시간마다 test를 실행하려면
0 */2 * * * /home/ysoftman/test

사이베이스 StoredProcedure 실행을 크론잡에 추가시키려면 사이베이스 환경변수등을 쉘파일에 세팅해야 한다

반응형


disk init name="디스크이름",physname="db의 물리적 file path",size="할당공간",dsync="false" 
// 사이즈는 복구할 DB사이즈보다 커야함, 할당공간은 G단위설정가능

create database 생성할DB이름 on 디스크이름 = "11G" for load  // DB생성

load database DB이름 from '복구할 풀백업파일의 file path' // 생성된 DB에 복구

반응형

/usr/adm/sulog
/usr/adm/wtmt
/etc/security/faildlog
/etc/security/lastlog

접속로그 경로

현재 접속중인 사용자 보기
who

지난 접속 로그 확인
last | more
last -n 100 (최근 100건)
반응형

비스타를 쭉 쓰다 윈도우7 출시후 라이센스 구매후 정말 잘 쓰고 있는데 어느순간부터 종료를 할때...

프로그램 종료(닫기)를 기다리는중 이라는 메시지가 뜨면서 기다리다 꺼지는 증상이 눈에 보여 자꾸 신경을 건드렸는데..

찾아보니 MS에서 비공식 패치가 있다는걸 알게 되어서 겸사겸사 포스팅합니다.
아마도 후에 나오는 SP1에 포함될것 같은 패치네요.


다아시겠지만 x86이 32bit용 x64가 64bit 용입니다.
반응형

일단  웜 바이러스의 형태로 ,  Viruslist.com 에 공식 기재된 진단명은,
Net-Worm.Win32.Kido  입니다.
변종이  여기서 파생되어져서  이름이 여러가지로 바뀔수가 있습니다.


자신이 사용중인 Microsoft Windows 운영체제가
MS08-067   취약점의  보안패치가 설치되지 않았다면 , 웜 형태로 유입되어서 PC내부로 침투하게됩니다.

감염된 후에 원래 운영체제가 설치되어있었던  드라이브만 HDD 포맷한뒤 , 재설치한다해도 , 이 웜은 이동식 드라이브, Recycle 폴더에까지 흔적을 남기는데
이동식 드라이브에 남아있었던  웜의 잔재나,
혹은
Recycle 폴더내에 남아있었던  웜의 잔재들,  또는  OS 재설치후에도 보안패치가 설치되지 않았다면 웹으로부터 유입되어져서, 
또 다시 활동할수가 있기때문에



사람들이 흔히  포맷을 한뒤 새로 설치해도  지워지지가 않는다,
이건 뭔가 기계적인 문제일것이다.  라고 잘못 알기도 합니다.



백신업체에서 내놓은   Auto Remove Tool을 수행한뒤 , 보안패치를 하는방법과,
자신이 수동으로 삭제한뒤 , 보안패치를 하는 방법이 있습니다.







아래 번역된 내용은   Kaspersky 글로벌 사이트에서 변종버젼이 아닌,
최초로 발견되었었던 , Net-Worm.Win32.Kido  웜에 대한  내용과 그에따른  삭제방법입니다.

(Kaspersky 한국지사에서 소개한 방법과는 약간 상이할 수가 있습니다.)
 - 아마도 약간 변종에 대한 대처방법을 서술한듯 합니다.

좀더 자세한 삭제방법과 정보를 취득하고 싶다면 ,  다음 링크를 방문하십시오.
http://www.kaspersky.co.kr/board/bbs/board.php?bo_table=Malware&wr_id=277






-자동 제거 방법-

1.아래 파일을 받는다.

2. KidoKiller.exe  를 실행합니다.

3. 검사가 끝날때까지 기다립니다.

4. 최신버젼의 백신으로 업데이트 한뒤 , 전체검사를 수행합니다.

5. 보안패치를 실시합니다.



                               위의 파일은  WindowsXP ,   아래 파일은  Widows Vista 입니다.




-수동 제거 방법-
  1. 아래 경로의 레지스트리 키를 삭제합니다.
    [HKLM\SYSTEM\CurrentControlSet\Services\netsvcs] -> 이 경로에 netsvcs 란 키는 원래 존재하지 않습니다.

  2. [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost] "netsvcs"
    위 경로로 가면 netsvcs 내용에 키 파라메터가 2개 있는데 ,이 웜바이러스는 그 파라메터 값을 이용해서(필자 같은경우는 (12320, 1) 2개가 있음)
    System32 이하에   <rnd>.dll   형식의 파일을 만듭니다. (rnd는   무작위를 뜻합니다.)
    그 파일들을 모두 삭제합니다.

  3. 컴퓨터를 재부팅 합니다.
  4. 원래의 웜 파일을 삭제합니다. (이 원래 웜파일의 위치는 당신 컴퓨터에 웜이 어떻게 침투했느냐에 따라서 달라집니다).
  5. system32 폴더에 들어가서 아래와 같은 형식의 파일을 삭제합니다.

    <rnd>.dll    ( <rnd> 부분은 랜덤으로 생성됩니다.)

  6. 모든 이동식 저장 장치에 들어간뒤 , 아래 경로와 파일을 삭제합니다. 들어가서  삭제합니다.

    <X>:\autorun.inf <X>:\RECYCLER\S-5-3-42-2819952290-8240758988-879315005-3665\<rnd>.vmx
    rnd는  랜덤으로 생성되는 이름이며 ,  X 는  이동식 디스크 드라이브 문자열을 말합니다. 

  7. 아래 파일을 OS 버젼에 맞게 내려받아서 설치합니다.



    위의 파일은  WindowsXP ,   아래 파일은  Widows Vista 입니다.

  8. 안티바이러스 SW를 설치하고 , 최신버젼의 DB로 업데이트 한뒤,   전체검사를 수행합니다.
반응형

'Useful Tips > SㆍW' 카테고리의 다른 글

Unix & AIX 서버 로그 저장 위치  (0) 2011.04.12
Windows 7 종료지연 문제 MS비공식 패치  (0) 2010.08.26
마이플랫폼 참고자료  (0) 2009.09.09
SSO 관련 자료  (0) 2009.09.02
JEUS 운영 및 관리  (0) 2009.09.01

☞ c3mix 상품제외처리

 if ( v_AssignFg == '1' ) 
  gds_StdProd.filter("PROD_KIND_CD=='11'||PROD_KIND_CD=='12'||PROD_KIND_CD=='13'||PROD_KIND_CD=='14' ") ;
 else if ( v_AssignFg == '2' )
  gds_StdProd.filter("PROD_KIND_CD=='11'&&PROD_CD<>'000003'") ; // c3(mix) 제외
 else if ( v_AssignFg == '3' )
  gds_StdProd.filter("PROD_KIND_CD=='11'&&PROD_CD<>'000003'") ; // c3(mix) 제외
 else if ( v_AssignFg == '4' )
  gds_StdProd.filter("PROD_KIND_CD=='12'") ;

 

☞ 그리드에서 소수점처리

 데이터셋은 DECIMAL 로 불러오고 ,

그리드설정항목 :  Display=number , Edit(e): lowernum , Mask(E): expr:###,###,###,###.### 으로 설정해서 0 도 표시된다.

 

 

주문처리 구현중에 수량만 처리안되어서 ds 에서 type을 integer 로 수정해서 처리완료되엇음

 

// 유종가져오기 (주유소 , 충전소 )
  v_Row = ds_Assign.SearchRow("ASSIGN_CD='"+strCode+"'") ; // 소속구분 확인
  v_AssignFg = ds_Assign.GetColumn(v_Row,"ASSIGN_FG"); // 1:본사 2:충전소 3:용기검사소, 4:주유소
  if ( v_AssignFg == "2" )
   gds_stdProd.filter("PROD_KIND_CD='11'") ; // 충전소
  else if ( v_AssignFg == "4" )
   gds_stdProd.filter("PROD_KIND_CD='12'") ; // 주유소

  ds_StdProd.CopyF(gds_StdProd) ;
  ds_Prod.CopyF(gds_StdProd) ;  

 

decode(length(Tostring("COND_RATE")),0,'###,###,###.###','###,###,##0.###')

 

☞ 말풍선 도움말

  function grd_Ship_OnMouseOver(obj,nPosX,nPosY,nRow,nCell,nPivotIndex)
{
 if ( nCell == 3 )
 {
  obj.ToolTipText = ds_Ship.GetColumn(nRow,"MNG_DEAL_NM") ;
 } else {
  obj.ToolTipText = "";
 }
}

 

☞ 그리드 속성처리 가변으로 적용하기

iif(CNT=="1", "완전","부분")

iif(DELI_NM == '확인', 'red','default')

 

☞ 그리드 중복처리
suppress 1로 셋팅한다.

 

☞ 그리드 포커스 이동처리   MoveToNextCell()
function grd_DealSale_OnEnterDown(obj,nRow,nCell,strVal,nPivotIndex)
{
 //trace ("nCell = "+ nCell ) ;
 // 추가에누리 등록시에 스킵처리한다.
 if (nCell == 14 ) grd_DealSale.MoveToNextCell();
 grd_DealSale.MoveToNextCell();
}

 

 

☞ 그리드 배경색을 지정

    // 그리드 배경색을 지정한다.
   grd_LeadList.SetCellProp("body",colIdx,"BkColor",v_BgColor);
   grd_LeadList.SetCellProp("head",colIdx,"BkColor",v_BgColor);
   grd_LeadList.SetCellProp("head",colIdx,"text",day+"\n("+v_YoilNm+")" );

☞ 날짜 증가

addDate("strDate" ,   1 ) ;

addMonth("strMonth", 1 ) ;

 

☞ EXPRESION 사용

iif(gfn_IsNull(ds_Mboard.getcolumn(currow,"R_ASSIGN_CD")),ds_Msupp.getcolumn(ds_Msupp.FindRow("NM_CD",ds_Mboard.getcolumn(currow,"R_ASSIGN_FG")),"NM_SUB"),ds_Massign.getcolumn(ds_Massign.FindRow("ASSIGN_CD",ds_Mboard.getcolumn(currow,"R_ASSIGN_CD")),"ASSIGN_NM"))

iif(parseInt(ds_Gauge.getcolumn(currow,"GAUGE_NO"))%2,"green","yellow")

iif(ds_Gauge.getcolumn(currow,"END_DAY")=="99991231","")

iif(ds_Gauge.getcolumn(currow,"END_DAY")=="99991231", "null","date")

 

☞ 그리드 멀티선택 기능

function Grid_PersonList_OnHeadClick(obj,nCell,nX,nY,nPivotIndex)
{
 if (nCell == 0)
 {
  if (Grid_PersonList.GetCellProp("head",0,"Text")=="1")
  {
   Grid_PersonList.SetCellProp("head",0,"Text","0");
   
   for(var i=0; i<dsPerson.RowCount(); i++)
    dsPerson.SetColumn(i, "chk", "0");
  }
  else
  {
   Grid_PersonList.SetCellProp("head",0,"Text","1");
   
   for(var i=0; i<dsPerson.RowCount(); i++)
    dsPerson.SetColumn(i, "chk", "1");
  } 
 }
 else
 {
  gfn_GridSort(Grid_PersonList,dsPerson,nCell,9);
 }
}

☞ 특정 그리드로 이동 설정 ;

    // 선택항목으로 이동
   var v_Row = ds_Mboard.SearchRow("SEQ='"+ gv_BOARD_SEQ +"' && REPLY_SEQ='" + gv_BOARD_REPLY_SEQ +"'");
   ds_Mboard.row = v_Row ;

☞ 파일 가져오기  LoadXML();

dsPam.LoadCSV(arg_dsTC.GetColumn(arg_Row, "PARAMETER"));

gds_Temp.LoadXML(ret);

자료 생성용 Dataset을 만든다.
 Create("Dataset", "dsPam", "DataSetType=\"Dataset\" Id=\"dsPam\"");

생성된 Dataset을 삭제한다.
 Destroy("dsPam");

ds_Assign.FireEvent = false;  데이터셋의 변경에 따른 부하를 줄이기 위해서 사용

eval(this.OnLoadCompleted + "()");   this.OnInit = "gfn_OnInited";

decode(rowtype, "update", "yellow", "insert", "red", "default")

☞ grid 를 이용한 subSum 구현하기

dataSet 에서 -- 속성에서 group Key setting -- grid 에서 항목에 대한 supress 를 지정한다.

dataSet 에서 -- columns 에서 sum, sum-text 에 구현해준다.

bkColor ==>  decode(jigup_nm,'소계','yellow','white')

grid Editor 에서 sum 라인에서 Expr : Sum('jigup_amt') 로 처리해 준다.

grid - HeadHeight

grid - RowHeight

 

CopyF - 필터된 dataSet 을 넘길때 사용한다.

 gds_Assign.filter("ASSIGN_FG == '1' ") ;
 v_Row = ds_Assign.CopyF(gds_Assign);

☞ 트리메뉴 세로간격

RowHeight

 

데이터셋에서 타이틀 볼드해제하기

boldhead : false

 

☞ max 값 구하기 , lpad 사용하기

maxVal = Lpad(parseInt(ds_mainMenu.Max("loc_no"))+1 , '0', 2) ;


☞ 데이터셋 : dataSet

fillarea : 데이터셋영역중 미사용영역도 동일하게 적용하기

cellMoving : 제목부분을 마우스 드래그로 이동가능하게 적용

 

 공통함수

1- 로그저장 로직

2- LOADING 메세지

3- 이미지 표준네이밍 작업

4- 제목부 타이틀 이미지 작업

5- 권한설정 확인부 공통로직

 

 

 

--- ftp 처리


#------------------------------------------------------------------------------#
# to get van ftp file server
#------------------------------------------------------------------------------#
ftp -n ${host_ip} << -!
    user ${user_id} ${user_pwd}
    prompt
    cd  ${r_move_dir}
    lcd ${l_move_dir}
    get ${remot_file_name} ${local_file_name}
    bye
<< -!
#------------------------------------------------------------------------------#

 

 출처 : 스터디넷

 

반응형
SSO 관련 자료   
  theY      
WAS간 세션공유

*** 사용자 인증여부만 참조할 경우

1. 쿠키에 사용자 키 저장
2. DB에 WAS간 세션아이디 매핑 테이블을 두어 상태 참조 등등

*** 세션에 많은 객체를 담아 상태를 유지할 필요가 있는 경우

1. 세션 클러스터링 구현


*** 발췌

========================================================================================
가장 단순한 방법은 Cookie를 이용하시고, 실질적인 정보는 DB에 저장하시어
두 머신이 공유하는 방법일 거라 생각 됩니다.
예를 들어 한 머신에서 Login을 하면 그 정보가 DB에 기록되고, Cookie에
특별한 자신만의 고유한 session_id를 발생시킨 후, 다른 머신으로 변환될 경우
DB에서 session_id에 해당하는 정보를 DB에서 Query해서 "아하, 이 Client는
이미 로그인 했었군"이라 판단할 수 있겠지요....
(단, Cookie는 모든 머신으로 날아갈 수 있게 도메인이 셋팅되어야 할 것이고,
session_id는 서블렛엔진의 기본적인 세션이 아니라, 비즈니스적으로 만들어진
임의의 것이어야 합니다.)
그러나, 이것은 user_id에 대해서만 공유될 수 있을 뿐, Servlet의 Session 에
저장된 여하한의 java Object에 대해서는 적용받을 수 없겠지요....
기능상의 제한이 있게 마련입니다.

========================================================================================
javax.servlet.http.HttpSession을 의미하시는지요? 그렇다면, 정확히는 WAS 에서 세션클러스터링을
지원해야 합니다.. 그렇지 않고서는.. 개발자가 세션클러스터링을 구현해야 겠죠..
Naming Service 같은걸 이용해서. 근데,, 그게 쉬운일 같아 보이지는 않습니다.
두 머신상의 세션의 동기화 문제랄지 그런부분이 아주 골치아플것입니다.. 특히 이것은 앞단에
L4 의 세션이 sticky 하지 않아서 request가 왔다 갔다 할수 있는 상황에서 문제겠지요..

========================================================================================
http://blog.naver.com/kyt0223.do?Redirect=Log&logNo=20017526292

몇몇 사이트에서, "세션유지기능"을 직접 제작하는 분들을 보았습니다. cookie에
key값을 생성하여 담고, key값을 이용해 static java.util.Hashtable에 넣고 빼는 방법으로
자체 제작하는 하는 것이지요.
혹은, 몇 명이 접속하였는지를 보기 위해, "접속자를 모니터링하기 위한 용도"로 이러한
시도를 하시곤 합니다.

이 분들이 종종 놓치는 부분 중의 하나는,  H/W머신(혹은 하나의 인스턴스)가 하나일
뿐이라는 가정을 하는 경향이 있다는 겁니다. 부하량이 늘어나 여러대의 서버로 확장할
경우, 원격의 인스턴스간의 데이타를 공유할 수 있도록 클라이언트/서버 구조의 TCP/IP
Socket/RMI를 사용할까, 데이타베이스를 경유해버릴까 등의 고민이 시작되고,
MOM(Message Oriented Middleware)를 사용하거나 simple MOM 를 TCP/IP로 구현해 볼까도
생각합니다.
하나의 서버에 담겨 있는 Hashtable의 값을 다른 서버에게 publish/subscribe방식으로
공유케 하는 것이지요. 실시간 변경된 값을 전달해 줄까, 아니는 주기적으로 전달해
줄까를 고민합니다. 또한 늘어만 가는 Hashtable의 데이타를 session timeout과 같은
기능을 어떻게 효율적으로 구현할까를 고민하게 됩니다.

.....이쯤되면, "잉, WAS(Web Application Server)의 Http Session Clustering 기능을
만들고 있군..."라는 최종적인 결론에 도달합니다.

이미 적용되어 있던 자체 제작된 기능을 나중에 여러대의 서버로 확장운영될 시점에
구조적인 문제나 성능상의 이슈로 결국 제거됩니다. (3곳 정도의 고객사에서 그러한
상황을 목격했습니다.)

J2EE스펙에서는 동일한 WAR(Web ARchive)내에서만 HTTP Session이 유지됩니다.
일부 WAS는 동일한 EAR(Enterprise ARchive)내에 존재하는 여러개의 WAR간에도
세션클러스터링을 지원합니다. (하나의 EAR에는 여러개의 WAR 및 EJB-jar가 존재할 수
있고, EAR단위로 서버(Server,인스턴스)에 deploy되는데, 서버는 인스턴스가 하나일
수도 있고, 여러대의 H/W박스에 분산되어 여러대의 Server(인스턴스) 클러스터일 수도
있습니다.)

========================================================================================
http://www.javaservice.net/~java/bbs/read.cgi?m=qna&b=consult&c=r_p&n=959681361

질문하신 분도 지적한 바와 같이 당연히 떠오르는 문제가 바로 "세션클러스터링"
입니다. 여러 머신으로 운영할 때, 한 머신에 접속했다가 다른 머신으로 부하분산
메카니즘에 의해 다른머신으로 Request가 이동되면, 기존 머신에서 저장시켜둔
각종 "세션정보", 예를 들어, UserID, 자신이 선택한 Shopping Items 등이 그대로
머신과 머신사이에서 유지되어야 한다는 것이지요...

IBM WebSphere Application, BEA WebLogic, SilverStream Application 등등은
각기 고유한 방식으로 이러한 세션 클러스트링 기능을 제공합니다.
(세션클러스트링은 스펙이 존재하는 것이 아니기에 Vendor 고유한 방식으로
Implementation 됩니다.)

IBM WebSphere Application Server의 경우, Version 2.0.x 역시 세션클러스트링을
제공하며, Version 3.0.x에선 DB를 이용하여 "Persistent Session" 기능을 제공합니다.
보통 Memory상에서 세션정보를 갖게 하는 것이 일반적이지만, file을 이용하기도하고,
DB를 이용하기도 합니다.

========================================================================================
http://www.dev2dev.co.kr/pub/a/2005/05/session_management.jsp

세션 속성을 여러 JVM에서 처리하려면 세션 속성을 serialize할 수 있어야 합니다. 이것은 클러스터링
요구 사항입니다.
세션 속성의 일부 필드를 transient로 선언하여 논-클러스터(non-clustered)로 만들 수 있습니다.
그러면 세션 속성의 모든 필드를 serialize할 수 있어야 하는 요구 사항이 없어지는 반면 이러한 속성이
백업 서버로 완전히 복제되지 않을 것임을 의미하기도 합니다. 이러한 접근 방법을 따르는 개발자는
이 속성 필드가 상실되더라도 애플리케이션이 일관된 방식으로 작동될 수 있도록 아주 신중하게 해야 합니다.
대부분의 경우 이러한 접근 방법은 단순히 모든 세션 속성을 serialize할 수 있는 객체로 변환하는 것보다
마무리가 좀 더 복잡합니다. 하지만 세션에서 아주 방대한 양의 사용자별 데이터를 캐시하는 경우 유용한
패턴일 수 있습니다.
J2EE 서블릿 사양(버전 2.2, 2.3 및 2.4)은 클러스터에서 공유해서는 안되는 서블릿 컨텍스트에 대해 설명합니다.
WebLogic Server는 기술된 대로 이 사양을 구현합니다. 싱글톤(singleton) 데이터 구조로서 서블릿 컨텍스트에
의존하는 논-클러스터(non-clustered) 애플리케이션을 클러스터 환경으로 이동하면 포팅 문제가 발생합니다.
일반적으로 애플리케이션이 J2EE 사양을 따르도록 하는 것이 모든 개발자 팀의 목표여야 함에도 불구하고
Coherence*Web은 클러스터 컨텍스트 옵션을 지원합니다.
클러스터 환경에서 발생하는 보다 미묘한 문제는 객체 공유 문제입니다. 논-클러스터(non-clustered)
응용 프로그램에서 두 세션 속성이 공통 객체를 참조하는 경우 공유 객체를 변경하면 두 세션 속성의 일부로서
표시됩니다. 그러나 이것은 클러스터 애플리케이션에서 흔한 경우는 아닙니다. 컴퓨팅 리소스의 불필요한 사용을
막기 위해 대부분 세션 관리 구현은 요청 시 세션 속성을 개별적으로 serialize 및 deserialize합니다.
WebLogic Server와 Coherence*Web(Traditional 및 Split 세션 모델)은 모두 기본적으로 이런 방식으로 작동합니다.
공통 객체를 참조하는 두 세션 속성을 개별적으로 deserialize하면 공유된 공통 객체는 두 번 인스턴스화됩니다.
공유 객체 동작에 의존하고 쉽게 수정할 수 없는 애플리케이션의 경우, Coherence*Web은 전체 세션 객체를
단일 동작으로 serialize 및 deserialize하는 Monolithic 세션 모델 옵션을 제공합니다. 그러면 처음부터 클러스터링을
염두에 두지 않고 설계된 애플리케이션에 대한 호환성이 제공됩니다.

========================================================================================

반응형

JEUS 운영 및 관리

JEUS 5.0을 버전을 기준으로 하고 설치시 입력한 JEUS 관리자의 비밀번호는 jeusadmin이라고 전제한다.

JEUS 구동

주로 jboot, jdown이란 이름으로 스크립트를 작성하여 실행한다. 이 파일들의 실제 명령행은 다음과 같다.

  • jboot: jeus -Uadministrator -Pjeusadmin
  • jdown: jeusadmin -Uadministrator -Pjeusadmin jeusexit

jeusadmin console

jeusadmin 콘솔툴을 이용하여 JEUS 컨테이너기동/종료, 엔진리스트확인 등 JEUS 엔진의 상태를 제어 및 점검한다.

  • 콘솔 실행: jeusadmin 'hostname' -Uadministrator -Pjeusadmin
  • 명령 목록
    • allenglist: jeusadmin의 allenglist 명령은 현재 각 컨테이너의 엔진기동 상태를 보여준다.
    • downcon <container-name>: 지정된 컨테이너를 종료시킨다.
    • startcon <container-name>: 지정된 컨테이너를 기동시킨다.
    • pidlist: JEUS의 엔진 프로세스를 확인한다.

webadmin console

webadmin 콘솔은 JEUS의 컨테이너 내부에 기동된 서블릿 엔진의 상태를 모니터링하기 위한 명령프롬프트이다.

  • 콘솔 실행: webadmin <container-name> -Uadministrator -Pjeusadmin
  • 명령 목록
    • ti: ti는 Thread Information의 약자로 JEUS 서블릿 엔진의 컨텍스트그룹 내부의 Worker Thread의 상태를 체크하기 위한 명령어이다.
    • st -m: 현재 Container의 JVM Memory 사용 현황
    • st -r: 설정한 Context로 들어온 요청 count와 평균처리시간
    • st -s: 현재 유지하고 있는 세션 객체의 수

webadmin 반복 모니터링

webadmin 내의 모니터링 명령어를 주기적으로 자동실행하게 하려면 다음과 같은 형식으로 명령어를 실행한다.

  • <command> -i 주기(초) -k 횟수
  • 예) ti -i 2 -k 10 : ti 명령어를 2초 간격으로 10번 수행

dbpooladmin console

dbpooladmin 콘솔은 컨테이너별로 할당된 Database Pool의 상태를 모니터링하기 위한 명령프롬프트이다.

  • 콘솔 실행: dbpooladmin<container-name> -Uadministrator -Pjeusadmin
  • 명령 목록
    • Info: 해당 컨테이너에서 관리되고 있는 Database Pool의 정보가 표시된다.
    • min, max 값은 JEUSMain.xml에 설정한 Pool의 최소/최대값이며 current는 현재 풀에 보관되고 있는 실제 커넥션의 수, idle의 풀에 보관되고 있는 커넥션중, 사용가능한 개수를 의미한다.

JEUS 웹 관리자

http://hostname:9744/webadmin 로 접속하여 administrator/jeusadmin 계정으로 로그인한다.

사용자 삽입 이미지

JEUS 웹 관리자

JEUS 장애 처리

JEUS 프로세스ID (PID) 확인

JEUS의 엔진 프로세스는 다음과 같이 2가지 방법으로 확인할 수 있다.

  • ps -ef | grep java
    • -Xmx512m 이후 부분을 확인하여 JEUS Manager 프로세스임을 확인한다.
    • [-D컨테이너이름]을 이용하여 컨테이너 프로세스임을 확인한다.
  • jeusadmin 콘솔툴을 이용한 PID 확인
    • pidlist: pidlist 명령을 사용하여 PID를 확인한다.

JAVA Dump

  • 덤프 생성: kill -3 [JEUS-PID]
  • 덤프 확인: JEUS JAVA프로세스에서 생성한 덤프는 JeusServerLog에서 확인한다.
    • 예) vi $JEUS_HOME/logs/`hostname`/JeusServer_20070201.log
WebtoB 운영 및 관리

WebtoB 구동

  • wsboot
  • wsdown-I : ps -ef을 이용하여 wsm, hth, htl, html 등의 프로세스가 나타나지 않으면 정상 종료

wsadmin console

WebtoB 시스템을 관리하기 위해서 wsadmin이라는 프로그램이 제공된다. wsadmin 프로그램은 UNIX 환경의 shell과 비슷한 Command Interpreter 이다. 즉, 항상 프롬프트상태로 대기중이다가 입력되는 명령어를 해석하여 이를 실행하게 된다. 여러 Node를 한 Domain으로 사용하는 경우 wsadmin으로 전체를 중앙관리가 가능하며 각 Node 별로 로컬에서만도 관리가 가능하다.

  • wsadmin
  • 명령 목록
    • ci: 요청에 대한 현재 클라이언트 정보를 표시한다. HTH당 접속한 클라이언트의 KeepAlive 되어있는 개수를 보여준다. WebtoB단에 요청을 보내고 HTTP Session의 KeepAliveTimeout 전까지 유지되고 있는 클라이언트의 총 개수 정보이다.
    • ci -s: 현재 클라이언트의 전체 수를 표시한다.
    • si: 웹서버 환경설정 파일에서 *SERVER 절에 선언한 서버들의 수행정보를 보여준다.
    • st -s: 웹서버 환경설정 파일에서 *SERVER, *URI, *EXT 절에 설정한 서비스의 상태가 보인다.
    • st -p: WebtoB 프로세스의 상태를 표시한다. 주로 JEUS-WebtoB간 연동 상태를 확인할 때 사용한다.

wsadmin 명령 연속 보기

ci, st -s, st -p, si 등의 명령어를 다음과 같이 수행하면 주기적으로 WebtoB의 상태를 모니터링할 수 있다.

  • r -i <시간(초)> -k <횟수> <명령>
  • 예) r -i 1 -k 1000 st -s
JEUS alias 설정

.profile 참고

...
export JEUS_HOME=/jeus
...
#### JEUS alias ####
alias ja='jeusadmin `hostname` -Uadministrator -Pjeusadmin'
alias ea='ejbadmin `hostname`_ejb_engine1 -Uadministrator -Pjeusadmin'
alias wa='webadmin `hostname`_container1 -Uadministrator -Pjeusadmin'
alias da='dbpooladmin `hostname`_container1 -Uadministrator -Pjeusadmin'
alias ti='webadmin `hostname`_servlet_engine1 -Uadministrator -Pjeusadmin ti -i 3 -k 100000'
alias ss='webadmin `hostname`_servlet_engine1 -Uadministrator -Pjeusadmin st -s -i 3 -k 100000'
alias sd='webadmin `hostname`_servlet_engine1 -Uadministrator -Pjeusadmin st -d -i 3 -k 100000'
alias di='dbpooladmin `hostname`_container1 -Uadministrator -Pjeusadmin info -i 3 -k 100000'

alias jcfg='cd ${JEUS_HOME}/config/`hostname`'
alias jbin='cd ${JEUS_HOME}/bin'
alias scfg='cd ${JEUS_HOME}/config/`hostname`/`hostname`_servlet_engine1'
alias ecfg='cd ${JEUS_HOME}/config/`hostname`/`hostname`_ejb_engine1'

alias jhome='cd ${JEUS_HOME}'
alias lhome='cd ${JEUS_HOME}/logs'

alias jlog='tail -f ${JEUS_HOME}/logs/`hostname`/JeusServer_`date +%Y%m%d`.log'
alias alog='tail -f ${JEUS_HOME}/logs/`hostname`_servlet_engine1/MyGroup/accesslog/access_`date +%Y%m%d`.log'
alias elog='tail -f ${JEUS_HOME}/logs/`hostname`_servlet_engine1/MyGroup/errorlog/error_`date +%Y%m%d`.log'
alias ulog='tail -f ${JEUS_HOME}/logs/`hostname`_servlet_engine1/MyGroup/userlog/user_`date +%Y%m%d`.log'

...
 
 

출처 : http://kyungseo.pe.kr/blog/102 E-MAIL 
반응형

제우스 설정 방법 몇 가지 (JEUS 6.0 기반)

 

이는 티맥스소프트에 AS 요청을 하면 원격으로 작업해주고 알려주는데, 체크시 자주 이용하는 것이라 정리하였다.

 

 

*. DB Close 가 정상적이지 않는 부분을 추적할 때 JEUSMain.xml 설정
<invocation-manager-action>Warning</invocation-manager-action>
<!--invocation-manager-action>AutoClose</invocation-manager-action-->

-> Warning 으로 설정하면 로그 파일에 DB Close 가 정상적이지 않는 파일의 이력이 나타남.
-> AutoClose 으로 설정하면 비정상인 소스를 자동 닫는 기능을 수행하나 디버깅이 안됨. 따라서 정상가동전에는 반드시

     Warning 상태로 테스트해야 함.


*. DB Connection 유실 있는 소스를 리눅스 콘솔에서 찾는 방법
[tmax@WEMS WEMS]$ grep "RequestURI" Jeus*20090312*.log
[2009.03.12 17:04:06][0][b168] [container1-42] [MGR-0107] RequestURI : /cewolf
[2009.03.12 17:04:14][0][b168] [container1-22] [MGR-0107] RequestURI : /cewolf
[2009.03.12 17:04:18][0][b168] [container1-32] [MGR-0107] RequestURI : /cewolf
[2009.03.12 17:04:19][0][b168] [container1-33] [MGR-0107] RequestURI : /cewolf
[2009.03.12 17:04:23][0][b168] [container1-26] [MGR-0107] RequestURI : /cewolf
[2009.03.12 17:04:35][0][b168] [container1-33] [MGR-0107] RequestURI : /cewolf
[2009.03.12 17:05:15][0][b168] [container1-30] [MGR-0107] RequestURI : /cewolf
[2009.03.12 17:05:22][0][b168] [container1-36] [MGR-0107] RequestURI : /cewolf

-> RequestURI 라는 예약어를 통해 관련 소스를 찾을 수 있음.


*. DB ConnectionPool 상태 보기
[tmax@WEMS WEMS]$ ja // 제우스 콘솔로 화면 전환
JEUS 6.0 (Fix#4) Jeus Manager Controller
WEMS>dsinfo 혹은 WEMS>dsinfo -i 5 -k 999 // 파라미터 의미: i(internal), k(repeat)

 

Connection pool information for engine container 'WEMS_container1'

----------------------------------------------------------------------------------
| id |        name | min | max | active | idle | disp | total | wating | working |
----------------------------------------------------------------------------------
|  1 | jdbc/source |   5 |  15 |      15 |    0 |    0 |     15 |   true |    true |
----------------------------------------------------------------------------------

disp : disposable connection, total = active + idle + disp
-> 컨넥션 풀로 설정한 정보를 제공하여 준다. 필요시 JEUSMain.xml에서 갯수를 변경할 수 있음


*. 제우스 쓰레드 상태 보기, 응답속도, 메모리 관련
[tmax@WEMS WEMS]$ ja // 제우스 콘솔로 화면 전환
JEUS 6.0 (Fix#4) Jeus Manager Controller


WEMS>ti

< ContainerName : WEMS_container1 >
-- Thread State [webtob1-hth0(localhost_9900)] --
[webtob1-hth0(localhost:9900)-w00][waiting, wt=84007 ms]
[webtob1-hth0(localhost:9900)-w01][waiting, wt=84004 ms]
[webtob1-hth0(localhost:9900)-w02][waiting, wt=84003 ms]
[webtob1-hth0(localhost:9900)-w03][waiting, wt=84000 ms]
[webtob1-hth0(localhost:9900)-w04][waiting, wt=84000 ms]
[webtob1-hth0(localhost:9900)-w05][waiting, wt=83996 ms]
[webtob1-hth0(localhost:9900)-w06][waiting, wt=83995 ms]
[webtob1-hth0(localhost:9900)-w07][waiting, wt=83993 ms]
[webtob1-hth0(localhost:9900)-w08][active, rt=111992 ms] /aaa/bbb/test.jsp
[webtob1-hth0(localhost:9900)-w09][waiting, wt=83990 ms]
[webtob1-hth0(localhost:9900)-w10][waiting, wt=83989 ms]
[webtob1-hth0(localhost:9900)-w11][waiting, wt=83986 ms]
[webtob1-hth0(localhost:9900)-w12][waiting, wt=83986 ms]
[webtob1-hth0(localhost:9900)-w13][waiting, wt=83882 ms]

-> active 상태가 장시간 지속되는 관련 소스는 반드시 체크되어야 함.

 

WEMS>st  -r // 요청에 대한 처리시간을 제공
< ContainerName : WEMS_container1 >
< request information(MyGroup/wems) >
   - total requests          : 19
   - total processing time   : 26023 ms
   - average processing time : 1369 ms


WEMS>st -m // 현재 사용중인 JVM 메모리 정보 제공
< ContainerName : WEMS_container1 >
< memory information >
VM Total Memory    = 648740864 Bytes
VM Free Memory     = 510449952 Bytes

 

*. 제우스 덤프 (AS 요청시 이 정보가 제공하면 빨리 처리될 수 있음.)
-> 아래와 같이 하면 로그 파일에 덤프가 수행됨

 

[tmax@WEMS WEMS]$ ja // 제우스 콘솔로 화면 전환하여 컨테이너의 pid값을 얻음.
JEUS 6.0 (Fix#4) Jeus Manager Controller

WEMS>pidlist
node or container : WEMS, pid : 25195
node or container : WEMS_container1, pid : 25248

 

[tmax@WEMS WEMS]$ kill -3  25248 // 콘솔상태에서 덤프실행 10초간격 3회 정도

-> 이를 수행하면 로그 파일에 덤프 정보가 수집됨.

 

*. OutOfMemoryError: PermGen Space 에러가 발생하였을 경우의 JEUSMain.xml 설정
-> Permsize를 조금 크게 하여 가동시킨다. 테스트 운영이나 스트레스 테스트 툴을 이용해 에러가 발생하지

     않는 값으로 최종 설정하면 된다.

<engine-container>
    <name>container1</name>
    <invocation-manager-action>Warning</invocation-manager-action>
    <command-option>
           -Xms512m -Xmx1024m -Djava.awt.headless=true
          -XX:PermSize=512m -XX:MaxPermSize=1024m
    </command-option>
    <sequential-start>true</sequential-start>
    <engine-command>
        <type>servlet</type>
        <name>engine1</name>
    </engine-command>
</engine-container>


반응형

+ Recent posts