김세훈

Clunix Wiki
(버전 사이의 차이)
(참고사항)
(참고사항)
153번째 줄: 153번째 줄:
 
취소화함'''으로써 얻어집니다.
 
취소화함'''으로써 얻어집니다.
 
*iis 트레이너이자 기술전도사인 브렛 힐의 어록 (http://network.hanb.co.kr/view.php?bi_id=1228)
 
*iis 트레이너이자 기술전도사인 브렛 힐의 어록 (http://network.hanb.co.kr/view.php?bi_id=1228)
  - 새로운 아키텍처를 도입하게 된 몇 가지 이유가 있습니다. 첫번째는 서버 동작에 대한 권한을 사람들에게 주는 겁니다. 모듈 방식의 디자인을 통해서 사람들은 어떤 모듈을 사용할지, 모듈을 읽어들이는 순서, 누가 어떤 모듈을 읽어들일 수있는지를 제거할 수 있습니다. 사용자가 만든 모듈들은 IIS7의 요청처리 파이프라인(request-handling pipeline)을 통해서 로드되기 때문에 '''인증 같은 내부 이벤트를 가로채는(hook up) 모듈을 네이티브 언어나 관리형 언어로 작성할 수 있습니다.''' 이를 통해 개발자들은 보다 쉽게 '''IIS7의 기능을 수정하거나 확장'''할 수 있습니다. 따라서, 사람들은 새로운 기능을 발표하기 위해 IIS 팀에 의존할 필요가 없으며, IIS7에 직접 추가할 수 있는 모듈을 작성하기만 하면 됩니다. 확장성은 모듈에만 한정된 것은 아닙니다. 예를 들어, '''스키마, 사용자 인터페이스, 응용프로그램이 보고하는 추적 이벤트(tracing events)를 포함한 IIS7의 거의 모든 부분이 모듈로 되어 있으며 확장할 수 있습니다.'''
+
  - 새로운 아키텍처를 도입하게 된 몇 가지 이유가 있습니다.  
 +
  첫번째는 서버 동작에 대한 권한을 사람들에게 주는 겁니다.  
 +
  모듈 방식의 디자인을 통해서 사람들은 어떤 모듈을 사용할지,  
 +
모듈을 읽어들이는 순서, 누가 어떤 모듈을 읽어들일 수있는지를 제거할 수 있습니다.  
 +
사용자가 만든 모듈들은 IIS7의 요청처리 파이프라인(request-handling pipeline)을 통해서 로드되기 때문에  
 +
'''인증 같은 내부 이벤트를 가로채는(hook up) 모듈을 네이티브 언어나 관리형 언어로 작성할 수 있습니다.'''  
 +
이를 통해 개발자들은 보다 쉽게 '''IIS7의 기능을 수정하거나 확장'''할 수 있습니다.
 +
  따라서, 사람들은 새로운 기능을 발표하기 위해 IIS 팀에 의존할 필요가 없으며,
 +
  IIS7에 직접 추가할 수 있는 모듈을 작성하기만 하면 됩니다. 확장성은 모듈에만 한정된 것은 아닙니다.
 +
  예를 들어, '''스키마, 사용자 인터페이스, 응용프로그램이 보고하는 추적 이벤트(tracing events)를  
 +
  포함한 IIS7의 거의 모든 부분이 모듈로 되어 있으며 확장할 수 있습니다.'''
 
  -
 
  -

2009년 3월 19일 (목) 12:37 판

  • 리눅스 팁
링크 시킬때
- ln -s /원본... /링크시킬 위치...
링크 정보를 알고 싶을 떄
- phpMyadmin과 같은 html상의 링크는
- /var/www/html/ 쪽으로 가자!

남은 하드디스크량 알아 볼 때
- df -h
하드디스크 부족할 때
- fdisk /dev/sd...
- extracted는 피할 것.
- 후에 mount로 정착
- 그리고 마지막으로 링크 (위의 것 참고)

마운트

- mount /dev/sdb1(원래 있던 곳.) /tmp/hadoop-root 하둡의 원위치
- 이건 뭘까? umount /media/disk
- http://mwultong.blogspot.com/2007/07/linux-mount.html <- 여길 참고하라!
- http://user.chollian.net/~deuckgi/LinuxServer/linux.htm <-여기도 참고하라!
프로세스의 비중이 클 때
- top로 검사 (작업 관리자와 같은 화면 실시간 출력)
- pid에 따른 비중에 맞춰 막히는 프로세서 삭제
- 삭제하는 방법 pkill -9 pid
- partprobe(?) 암튼 이건 재부팅 방지용이다.

목차

하둡

- hdfs상에서 송수신할 때, 나눠야할 블록, 버퍼량을 헤아려야 한다.
- 예를 들어, 너무 많은 양을 한꺼번에 보내려 한다면 오류가 발생한다.

- h-base, hdfs, map & reduce 방식은 구글 것을 따라한거다.
- 하둡은 높은 전송률,  낮은 지연률 - 단, 많은 양의 컴퓨터(렉)가 병렬구조의 클러스터를 이뤄야 된다- 을 자랑한다.
- moving computation 움직일 수 있는 계산. 즉,  계산처리 과정의 근접화. 즉, 데이터의 이동, 근접화보다 더 효율적인 방법
이라고 한다.
- hdfs는 상호작용이라기보단, 배치 프로세싱. (이게 도대체 무슨말인지...) 
- 결론은, 병행처리 구조상 획기적인 '속도의 증대'는 DFS의 놀라운 발견!

- 하둡의 초기화는 우선 hadoop namenod -format 디렉토리 초기화(1)
- start-all.sh (2)분산파일 시스템(DFS) 가동!
- 그리고 분산파일 시스템의 중지는 stop-all.sh 스크립트 이용
자세한건 여기에! http://www.joinc.co.kr/modules/moniwiki/wiki.php/JCvs/Search/Document/nutch/Hadoop?action=print
- hadoop-default.xml 이건 뭘까?
- hadoop-site.xml 이건 뭘까?
- $하둡홈/logs...
- hadoop-daemon.sh start namenode
- hadoop-daemon.sh start datanode
- 위의 것도 염두해두자.


EMS

- client_data1 as A LEFT JOIN firm_data1 as B on A.f_id = B.f_id
- 생각해보자. 모든 테이블의 값을 불러들어올 수 있는 명령!!
- 뭔가를 값을 얻어서 다른 폐이지에 보낼 때(처리할 때) 한 폐이지에 두개이상의 방식이 존재할 때,
  고려해야한다. 그러니까 인풋 타입의 메쏘드를 get으로 할 것인지, post로 할 것인지, 뭐 요런 것들이
  2개 이상이라면 충돌(아마 그런걸거다.)을 우려할 수 있으므로 미리미리 막아두자. 검색엔진이라던지,
  처리 버튼이라던지...

해쉬 테이블

- 전화번호부, 그러니까 찾아보기 쉽게 색목별로 나눈 사전이나 전화번호부라면 해쉬테이블!
- 어떤 곳에 넣어야 할 지, 그러니까 구분하는 기준을 정하는게 최우선과제겠지!
- 하지만 이 역시 완벽하진 않아, 쉽게 에러가 날 수 있는데 대표적으로 값을 추가할 수 없는 충돌 현상이 그것이다!
- 해결방법 다중슬롯: 그냥 2차원 배열 만들면 되지뭐!
- 하지만 한쪽 슬롯에만 치중된다면- 낭비, 지연.
- 결국 단순, 신속적인 해시테이블을 만들어야!
- 선형탐색 : 꿩대신 닭. 해당 슬롯이 꽉차면 그 옆자리!
- 동적 슬롯: 슬롯의 갯수를 가변적으로 관리하는 방법. 비교적으로 적극대처 방법.
- 이 동적슬롯의 구현은 동적배열이나 연결리스트로 작성해야. 물론 이 때엔, 양이 방대해짐을 전제로 한다면,
- 이분 검색을 하는게 유리하겠다.

- 검색이라기 보단, 빠른 검색을 위한 자료관리 알고리즘.

uts

1) 용어 정리
  - 스테이지 : U. T. S의 세단계를 세분화 시킨것.(같은 S를 가더라도 S1에 갈 건지, S2에 갈 건지 알아야지.)
  - DH테이블, 크게 svc와 tid로 나뉘는데 업데이터와 뭐가 다를까. 일단 보류
  - UTS_ENV 이건 한 데이터의 세부정보.
2) 함수
  - record_direction
3) 돌아가는 구조
  - 폴더와 같은 이름.C : 거의 메인함수와 같은 격, 익스트렉터와 트렌스포머 그리고 이에따른 분리된 헤시테이블관리
    그리고 헤시엔트리(hentry)를 관리하고 있다.
  - 폴더와 같은 이름.h : 모든 것을 정의하는 헤더파일, 참고로 위에 메크로 부분은 중복선언을 막기위한 것이란다.
    php의 require-once라고 이해하면 될 것이다.
  - transform.c : 후에 uts_transform함수에서 호출하게될 loc_mapping에 관여하는 파일.
4) DHTABLE정의 부분 
  - 2번째 부터 4번째까지의 인자 부분은 중요하다. (알아두어야 할것)
  - 그리고 맨 끝에서 4번째 인자는 2번째 스테이지에서 처리할 데이터(키값)
  - 맨 끝에서 3번째 인자는 키와 벨류를 합친 데이터량
  - 맨 끝에서 2번째 인자는 해시테이블의 수(그러니까 분류처리할 종류의 갯수)
  - 맨 끝의 인자는 최종적으로 처리하여 보내줄 목표 단계(처음에 한건 3스테이지라고 설정했다.) 
5) 앞으로 할 일
  - 더 알자.

이맥스 팁

1) C-x, r, m 북마크 표시해두기
2) C-x, r, l 표시해둔 북마크로 가기
3) C-x, r, b 표시해 둔 북마크로 가기
4) yum -update 이건 리눅스인데, 중요한 것.
5) C-x, [스페이스바] -> 이거 아무래도 브레이크(gdb)걸어놓는 것 같은데.
6) M-';' 소스코드가 있을때 주석 삽입. 자동으로 주석끼리의 줄도 맞춰줌.
7) M-q 주석이 지정된 폭을 넘어가면 알아서 칸을 맞춰준다.
8) C-space 블록 지정, 2번 하면 마킹까지 된다
9) C-u M-';' 현재줄에서 시작하는 주석 삭제.
             블럭이 지정되어 있으면 블럭 전체 주석 처리함.

이맥스 섭버젼(svn) 팁

1) svn - failed : Valid UTF-8 DATA란 메세지가 나온다면
   export lang의 설정을 해야한다. 현재 .bashrc로 alias 설정을 했기때문에
   이맥스작업이라면 UTF-8이 아닌, euc-KR로 그 외에 작업은 가급적 UTF-8로 작업을 해야한다.

ECM-core 배웠던 명령어 나열

1) ./ecmctl -p 908 -e -n clarysage -c kimsh -C start
2) CFLAGS="-g -Wall" ./configure --enable-debug --prefix=/usr/clx
2.5) 단, UTS-modules 에서는, --disable-hadoop이라고 적어야한다.
3) edbd
4) ps -C ebcd (이건 근데 ps, kill같은건 리눅스 커맨드와 관련 깊다. man 으로 공부하자)
5) kill -usr1 (근데 이건 리눅스 커맨드 창에서 실현)

IIS

  • 인터넷 인포메이션 서버의 약자, 서버 프로그램
  • ftp, www에 대해선 어느정도 알고 있으니.
  • smtp는 아웃룩
  • nntp역시 아웃룩인데, 토론그룹에 관한 것.
  • MMC는 관리자(파일관리자 같은 것)

IIS 의 요청 처리 rpm

  • Request Processing Models
  • 사용자 요청처리라고 정의할 수 있겠다.
  • 중간에 웹서버에서 로드한 ISAPI 모듈이 더 많을 경우 처리단계가 더 많아지게 된다.
  • 최근 iis 6에선 요청처리를 별도의 응용 프로그램풀(워커프로세스)처리하여 웹서버의 안정성을 높인다고 한다.
  • 암튼, 해당 지원하는 php라던지 asp같은 언어라면 동적컨텐츠라고 판단 캐시(일종의 'api보관소'인듯)를 탐색후 리턴
  • Request 객체는 클라이언트 -> 서버로 작용하는 여러가지 데이터
  • 값을 가져올 때 클라이언트에 있는 걸 서버쪽에 적용할 때의 객체
test = Request.form("test")
test = Request.cookie("test")
  • 그러니까 사용자의 정보를 서버쪽에 인식할 때의 정보를 통틀어 Request객체?

참고사항

  • 6.0강력한 보안 높은 안정성 및 성능향상을 위한 엔지니어링 릴리스
  • 7.0플랫폼릴리스? 이전버전의 고품질 기본 웹 서버코어를 핵심적인 최신 배포 및 관리 시나리오 지원을 갖춘 모듈 방식의

확장성 높은 플랫폼으로 전환하기 위한 릴리스

취소화함으로써 얻어집니다.

- 새로운 아키텍처를 도입하게 된 몇 가지 이유가 있습니다. 
 첫번째는 서버 동작에 대한 권한을 사람들에게 주는 겁니다. 
  모듈 방식의 디자인을 통해서 사람들은 어떤 모듈을 사용할지, 
모듈을 읽어들이는 순서, 누가 어떤 모듈을 읽어들일 수있는지를 제거할 수 있습니다. 
사용자가 만든 모듈들은 IIS7의 요청처리 파이프라인(request-handling pipeline)을 통해서 로드되기 때문에 
인증 같은 내부 이벤트를 가로채는(hook up) 모듈을 네이티브 언어나 관리형 언어로 작성할 수 있습니다. 
이를 통해 개발자들은 보다 쉽게 IIS7의 기능을 수정하거나 확장할 수 있습니다.
 따라서, 사람들은 새로운 기능을 발표하기 위해 IIS 팀에 의존할 필요가 없으며,
 IIS7에 직접 추가할 수 있는 모듈을 작성하기만 하면 됩니다. 확장성은 모듈에만 한정된 것은 아닙니다.
 예를 들어, 스키마, 사용자 인터페이스, 응용프로그램이 보고하는 추적 이벤트(tracing events)를 
 포함한 IIS7의 거의 모든 부분이 모듈로 되어 있으며 확장할 수 있습니다.
-
부서별 위키