서버 프로그램을 작성하다 보면, 학습,색인 등의 특정 프로세스 이후 대용량의 knowledge 를 로딩하는 경우가 있다.


분명히 메모리 할당 해지 부분을 잘 넣었음에도 증가하는 메모리가 있는 경우가 있는데, 이때 환경변수로 MALLOC_ARENA_MAX=1 를 사용하게 되면 메모리 증가를 막을 수 있다.


단 메모리 할당 속도가 현저히 저하되므로 용도에 맞게 잘 사용해야 한다.


보다 자세한 내용은 아래를 참고한다.


  • https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior


목차



  • make 소개
  • Makefile 기본편
    • 기본구조
    • Makefile.win (CYGWIN)
  • Makefile 응용편
    • Macro
    • Dependency
    • Command
    • Operation
  • 와이즈넛 build_system 소개


make 소개


make 정의(by man) : GNU make utility to maintain groups of programs. The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them.

make 명령시 참조 파일 : 현재 디렉토리 내의 GNUmakefile, Makefile, makefile. Makefile을 권장함

make -f <파일명> : 특정파일을 Makefile 처럼 인식하여 make 명령을 수행할 때 사용. 와이즈넛에서는 윈도우 빌드시 Makefile.win 을 읽기 위해 해당 명령을 사용.


Makefile 기본편 - 기본구조



<target>: <dependency>
      <command>

  • target : command 수행 결과를 담는 곳. 모드, 파일, 패턴, 변수 등 다양하게 올 수 있음. dependency 로 지정된 대상이 변화가 없으면 target은 수행되지 않는다.
  • dependency : target 수행시 의존성을 검사하는 대상 target. 다른 target, 파일등등 target처럼 다양하게 사용 가능. 값이 없어도 됨.
  • command : target에 대한 실제 수행 명령을 담는 부분. 반드시 tab 으로 구분되어야 함. bash 명령어 참조

여기서 잠깐 : mode

  • 표준 모드 : all , clean , install, test
    • all : 현제 디렉토리 내의 모든 것을 빌드. ( 모드를 입력으로 주지 않으면 all 부터 시작함 )
    • clean : 빌드 생성물을 모두 삭제.
      • tip : clean 으로 모든 생성물을 잘 제거했는지 확인 ( VCS로 확인 가능 : subversion / git 등 )
    • install : 빌드 생성물 중 설치 대상 파일들을 설치 디렉토리에 설치함.
    • test : 현 디랙토리 내의 테스트를 위한 빌드 (및 수행)를 진행함.

Makefile 기본편 - Makefile.win (CYGWIN)

  • 모든 경로는 (환경변수 포함) dos 경로로 지정되어야 함.
    • unix 경로( /cygdrive/d/home/user/program )는 오동작을 일으킴. dos 경로 ( "c:/cygwin64/home/user/program" ) 으로 지정되어야 함.
    • unix 경로를 dos 경로로 바꾸려면 cygpath.exe 를 이용함
      • 예 : cygpath -d $PWD
  • 컴파일 전 build_system/confs 아래 해당 빌드옵션.env 파일을 환경변수로 정의해야 한다.
    • 예 : 빌드 정보가 ia64-w64-msvc90-64 인 경우 컴파일 전 아래의 명령을 수행해야 함

$ source ia64-w64-msvc90-64.env





Makefile 응용편 - Macro


  • 명령어 수행 결과를 변수에 넣기 $(shell 명령어)

TEST_SRC = $(shell ls t_*.java)


  • internal macro
    • $* : 확장자 제거한 target 파일
    • $@ : 만들어질 파일 이름 (target)
    • $< : dependency 로 주어진 파일 중 변경된 파일명
    • $? : dependency 로 주어진 모든 파일 set

  • suffix replace macro
    • OBJS = ${SRCS: .c=.o} 
      • SRCS 의 모든 파일에 대한 .c 확장자를 .o로 대치하여 OBJS 에 저장

<Makefile>

SRCS = aaa.c bbb.c ccc.c
OBJS = ${SRCS: .c = .o}

all : xxx

xxx : $(SRCS)
    @echo "================== xxx ==================="
    @echo "target ===== $@"
    @echo "newer sources = q $?"
    @echo "newer sources = g $<"

%.c:
    @echo "target ==== $@"
    @echo "asterisk ==== $*"
<출력>

$ make
target ==== aaa.c
asterisk ==== aaa
target ==== bbb.c
asterisk ==== bbb
target ==== ccc.c
asterisk ==== ccc
================== xxx ===================
target ===== xxx
newer sources = q aaa.c bbb.c ccc.c
newer sources = g aaa.c
target ==== all.c
asterisk ==== all
cc    -c -o all.o all.c
cc: all.c: 그런 파일이나 디렉토리가 없음
cc: no input files
make: *** [all.o] 오류 1


Makefile 응용편 - dependency


target 및 dependency 에서 자주 사용하는 패턴
  • %.o : *.o 파일을 의미함.  "t_%: t_%.o" 등으로 패턴적용 응용 사용 가능
    • 예) %.o : %.cpp


Makefile 응용편 - command

아래의 command 는 bash 명령어에 기반한 내용이다. bash의 다양한 명령어를 사용하여 Makefile 을 구축할 수 있다.

(참고) Makefile 내에서 명령어 앞에 @를 사용하는 경우 명령어가 출력되지 않음.


  • 하위 디렉토리 순회

DIRS = aaa bbb ccc ddd

all:
    @for dir in $(DIRS); do \
        echo "===> $(PWD)/$$dir"; \
        (cd $$dir && $(MAKE) -f $(MAKE_FILE) $@) || exit 1; \
        echo "<=== $(PWD)/$$dir"; \
    done



Makefile 응용편 - operation


  • 특정 변수에 대한 확인 : origin
    • 문법 : $(origin variable)
    • return 값
      • undefined : 정의되지 않음
      • default : default 값이 있는경우
      • environment : 환경변수로 정의됨 ( -e 등의 복잡한 부분은 이곳 참조 : http://www.viper.pe.kr/docs/make-ko/make-ko_8.html )
      • file : makefile 에서 정의되었음
      • command line : 명령행에서 정의되었음
      • 등등
    • 보통 ifeq 과 함께 사용

ifeq ( $(origin SF1_SRC), undefined )
$(error no environment variable SF1_SRC)
else
 ...
endif


  • 정렬 및 중복제거 : sort
    • 문법 : $(sort list)

SORT = $(sort foo bar lose bar2 lose)

all:
    @echo "sort === $(SORT)"
sort === bar bar2 foo lose


  • wildcard 실제 텍스트 변환 : wildcard
    • 문법 : $(wildcard text)
      • 예: $(wildcard *.cpp)
    • OBJ = *.o 를 하게 되면 OBJ 는 *.o 라는 문자열을 가지게 된다. 만약 현재 경로에 o 파일이 아무것도 없어도 OBJ 는 *.o를 갖게 되어 알수없다는 컴파일 에러를 내게 될 것이다. 그래서 *.o 보다는 wildcard 와 문자열 치환 함수를 통하여 구현하는 것을 권고한다.


  • 일괄치환 : patsubst
    • 문법  : $(patsubst 원본패턴, 대치할패턴, 텍스트)
    • 보통 wildcard 와 함께 사용하며 특정 경로의 모든 패턴의 파일 리스트에 대한 확장자 변경을 할때 사용한다.

DIRS = ./module1 ./module2 ./module3
OBJS = $(patsubst %.cpp, %.o, $(foreach dir, $(DIRS), $(wildcard $(dir)/*.cpp)))



  • 다른 Makefile 내용 포함 : include
    • 보통 Makefile.win 에서 Makefile 과 그 내용이 동일할때(java compile 등) 사용함.

<$(SF1_SRC)/src/isc/qp/qpapi/java/Makefile.win 내용>

include $(SF1_SRC)/src/isc/qp/qpapi/java/Makefile







References


  1. DATABASE URL 에 아래의 인자를 추가하면 속도가 향상된다.
  2. Table 구조에서 성능저하를 일으킬 수 있는 불필요한 부분을 삭제한다. ( 절대 빈값이 들어갈수 없는 INSERT 문을 이용하는데 NOT NULL을 사용함, 검색을 자주하지 않는 필드에 대해서 인덱스를 사용함 등…)


Use “nc” command.

(ex)  $ nc -k -l 1818 > output.file

  1. See the command argument of nimbus (or supervisor)

     
  2. Search storm.log.dir in the command argument


Error Msg

Cause

  • There are a lot of causes of this situation. In my case, this was because of absence of hostname of kafka server at client side.

Solution

  • Added hostname of kafka server to the client machine. Suppose that the ip and hostname of kafka server are 111.111.111.111 and “kafkaserver”. I used Mac OSX client so I added this information to /private/etc/hosts file. You can easily find the location of host name management file in your OS.


Memory allocation mechanisms in AIX


AIX는 기본적으로 Yorktown 기법으로 memory allocation 이 이루어지며, Watson이나 Malloc 3.1 방법으로도 변경이 가능하다.
각각의 Memory allocation사용방법은 다음과 같다.

  • export MALLOCTYPE=Yorktown
  • export MALLOCTYPE=Watson
  • export MALLOCTYPE=3.1
  • export MALLOCTYPE=3.1_64BIT

Yorktown

Yorktown 은 메모리를 Cartesian binary search tree로 힙 노드들을 관리한다. 

사용시기
  • 대부분의 케이스에서 널리 사용되는 안정적인 방법.
  • 다양한 size 가 기입된 tree로 관리되기 때문에 block size 에 제약이 없음

Yorktown Allocation algorithm
  • free tree에 있는 주소값이 낮은 node(크기는 요청한 사이즈와 같거나 크다)가 삭제 된다. 만약 요청크기보다 큰 경우 두 조각으로 나뉘어 반환된다.

Yorktown free algorithm
  • free tree에 해당 free node를 삽입한다. 삽입시 표준 root insertion algorithm을 따른다. 만약 인접한 메모리영역이 발견된 경우 하나의 노드로 합쳐진다. 이부분은 메모리 파편화를 예방한다.

Yorktown reallocation algorithm
  • 재할당 사이즈가 기존보다 큰 경우, 해당 node는 free tree로 반환되며, 요청된 새로운 크기의 노드로 할당된다. 할당된 새로운 노드에 이전 노드의 데이터들이 옮겨져 반환된다. 이전 블록은 해지되며 더이상 사용가능하지 않다. 만약 재할당 사이즈가 기존보다 작은 경우 노드는 두 조각으로 나뉘며 남는 조각은 free tree로 반환된다.


Watson

Watson 할당 정책은 두개의 분리된 red-black tree(address로 정렬 / size로 정렬)로 관리한다.

사용시기
  • Watson은 red-black tree를 사용하므로, 삽입이나 탐색이 다른 정책에 비해 효과적이다.

Watson Allocation algorithm
  • Yorktown과 비슷하게 요청한 크기와 비슷한 가장 작은 블럭을 탐색한다. 요청한 크기와 일치하는 블럭을 찾은경우 size, address tree에서 제거되며 반환된다. 만약 요청한 사이즈가 발견되지 않으면, sbrk() system call을 호출하여 힙을 확장하며 확장된 블록이 size와 address tree로 삽입된다. 그리고 이전단계의 탐색을 반복한다.

Watson free algorithm
  •  해지할 노드는 먼저 adress tree의 루트에 리턴되며 인접한 노드가 있는지 찾는다. 인접한 노드가 있는경우 하나로 합쳐진다. 

Watson reallocation algorithm
  • 재할당 블럭 크기가 기존보다 큰 경우, 기존 노드는 free tree로 반환되어 인접한 노드가 있는경우 합쳐진다. 요청한 사이즈의 새로운 블럭이 할당되며, 데이터가 기존노드로부터 이동되어 반환된다. 만약 재할당 블럭 크기가 기존보다 작은 경우 블록이 나뉘며 남은 블럭은 free tree로 반환된다. 


malloc 3.1

malloc 3.1에서는 hash bucket으로 관리되며 각각의 bucket포인트에서는 연결리스트로 특정 사이즈의 노드나 블록이 포함된다. 특정 bucket에는 특정 사이즈의 블록이 있다. ( size = 2 ^ (i + 4) ) 

malloc 3.1 allocation algorithm
  • 요청한 사이즈를 보고 bucket 번호가 결정된다. 해당 bucket 번호에 노드들이 없으면 sbrk()를 이용하여 새로운 블록을 집어넣는다. 만약 free list에 노드가 있는 경우 해당 노드가 반환되며 그 다음 노드가 bucket의 list head가 된다.

malloc 3.1 free allocation
  • 메모리 블록이 free pool 로 넘겨질때, 기존에 할당되었던 방법으로 bucket index를 계산하여 해당 버켓의 free list 의 head에 삽입한다.

malloc 3.1 reallocation algorithm
  • 재할당시 재할당 사이즈가 기존보다 커지더라도 해당 블록안에 들어갈 수 있는지 판단한다. 해당 블록 안에서 충족할 수 있는 경우 그 블록이 다시 리턴되며, 큰 사이즈의 블록이 필요한 경우 해당 블록은 해지 되며 새로운 버켓에서 생성한 블록이 데이터 이관 이후 리턴된다.

malloc 3.1 limitations
  • malloc 3.1 은 기본 정책인 Yorktown 보다 효율적이지 못하며 대부분의 상황에서 권장하지 않는다. 고정된 블록사이즈로 인하여 매 블록마다 우리가 원하는 사이즈보다 더 많은 메모리를 할당해야 한다. 
  • 때때로 특정 어플리케이션에서는 malloc 3.1 할당 정책에 따른 사이드 이펙트에 영향을 받기도 한다. 예를들어 특정 요청 사이즈보다 더 쓰는 경우 malloc 3.1에서는 정상적으로 동작하던 코드가(물론 메모리를 잘못 사용하는 것이지만) 다른 할당 정책에서는 실패한다.
  • reallocation 시 데이터 이동을 최소화 하기위해 malloc 3.1을 사용하기도 한다.


Malloc 부가 옵션들

부가 옵션들은 다음과 같이 사용하면 된다.

Malloc multiheap
  • 기본적으로 malloc 은 전체 프로세스 heap을 하나의 속성으로 간주한다. multi thread 환경에서는 각 멀티 스레드가 같은 heap 을 접근하게 된다. 이 경우 single heap은 thread lock 으로 인하여 매우 비효율적이다. 이런 케이스의 경우 malloc multiheap 옵션이 유용하다.
  • export MALLOCOPTIONS=[multiheap:n] | [considersize]
    • multiheap:n : n에는 1 ~ 32의 숫자를 사용할 수 있다. 사용할 힙의 개수를 정의한다.
    • considersize : 기본적으로 multiheap은 사용가능한 다음 heap을 선택하는데, considersize가 활성화된 경우 해당 요청을 처리할만큼 충분한 여유공간이 있는 heap을 선정한다.
    • ex) export MALLOCOPTIONS=multiheap:3,considersize
  • limitations
    • 여러개의 heap을 사용하므로 메모리 파편화를 야기하며, 메모리 부족 현상이 발생할 수도 있다.
    • considersize는 부가적인 처리시간을 필요로 하기 때문에 특정 상황에서는 느려질 수 있다.
    • multiheap옵션은 malloc 3.1 이나 사용자가 정의한 할당 정책에서는 사용할 수 없다.

Pool allocation
  • 메모리 크기가 512 byte 와 같거나 작은 경우 AIX는 효율적으로 malloc의 frontend 와 backend를 제어하는 기능을 제공한다. Pool allocation은 각 스레드마다 고유의 malloc pool을 생성하여 스레드들 간의 malloc locking 현상을 방지한다. 현재 한 프로세스당 설정할 수 있는pool 의 최대 크기는 512MB이다.
  • Pool allocation은 한 쓰레드에서 메모리를 할당하고 다른 스레드들이 해지하는 경우 효과적이지 않다.
  • Pool 개수는 max_size에 따라 결정된다. 32bit에서는 128개의 풀을 가질 수 있는 하나의 머신에서는 64bit에서 64개의 풀을 가질 수 있다.
  • export MALLOCOPTIONS=pool<:max_size>

Malloc buckets
  • Malloc bucket은 Yorktown 할당 정책의 확장 기능이다. 만약 작은 메모리 할당 요청이 굉장히 많은 어플리케이션의 경우 malloc bucket이 더 일반적으로 사용된다. Yorktown 모드에서만 동작한다.
  • 512 byte 이하의 요청에 대해서만 bucket allocator에 의해 서비스되며, 더 큰 경우 Yorktown malloc 으로 넘긴다.
  • export MALLOCOPTIONS=buckets,number_of_buckets:n





AIX: Throughput problems when malloc is called often

최근 고객 사이트에서 MALLOCOPTION=multiheap  환경변수를 재설정하는것 만으로 50% 성능 향상을 이뤄냈다. 무겁고, 동시다발적으로 일어나는 malloc 상황에서만 적용가능하겠지만 대부분의 WAS/Java 를 보면 특별한 케이스가 아니다. 
multiheap 옵션은 가상/물리적 메모리를 증가시키는 만큼 비용이 있다. 각 힙의 free tree가 독립적이기 때문에 파편화가 더 자주 발생한다. 아래에서 오버헤드에 대한 추가적인 설명을 볼 수 있다.

malloc 은 이따금 어플리케이션 성능(특히 AIX에서)의 병목이 된다.  기본적으로 AIX는 하나의 힙을 사용하기 때문에 멀티 쓰레드 어플리케이션에서 malloc lock 상황이 자주 발생한다. multiheap 옵션을 사용함으로서 allocator가 여러 힙들을 병렬로 사용할 수 있다. 

이 옵션이 영향을 미치는지 어떻게 알 수 있는가? 쉽지만은 않다.

pthread library나 kernel locking, routine에서의 실행시간의 집중현상은 locking 이슈와 관련이 있다. locking 현상은 결국 시스템 레벨이나(AIX 의 malloc locking issue같은) Java code의 어플리케이션 레벨(Java code 내 synchronized block이나 method)로 올라온다. Locking 이슈의 근원은 프로파일을 보는것 만으로는 즉시 나타나지 않는다. 예를들어, AIX malloc loking 이슈의 경우 malloc과 free routine에 의해 사용된 시간은 커널 locking 루틴에서의 시간 소비가 대부분인 경우 ​매우 적을 수 있다. 

그럼에도 불구하고 아래는 이 문제를 보여주는 tprof의 한 예이다. 실행은 아래와 같이 하였다.
  • tprof -ujeskzl -A -I -X -E -r report -x sleep 60

Process                          FREQ  Total Kernel   User Shared  Other   Java
=======                          ====  ===== ======   ==== ======  =====   ====
/usr/java5/jre/bin/java           174  22557  11850      0   7473     86   3148

Shared Object                                  Ticks    %    Address  Bytes
=============                                  ===== ======  =======  =====
/usr/lib/libc.a[shr_64.o]                       3037   9.93 900000000000d00 331774
/usr/lib/libpthread.a[shr_xpg5_64.o]            1894   6.19 9000000007fe200  319a8

  Total Ticks For All Processes (KERNEL) = 15045
Subroutine                 Ticks    %   Source                Address  Bytes
==========                 ===== ====== ======                =======  =====
._check_lock                2103   6.88 low.s                    3420     40

  Total Ticks For All Processes (/usr/lib/libc.a[shr_64.o]) = 3037
Subroutine                 Ticks    %   Source                Address  Bytes
==========                 ===== ====== ======                =======  =====
.malloc_y                    856   2.80 ../../../../../../../src/bos/usr/ccs/lib/libc/malloc_y.c    41420    840
.free_y                      669   2.19 ../../../../../../../src/bos/usr/ccs/lib/libc/malloc_y.c    3f980    9a0

  Total Ticks For All Processes (/usr/lib/libpthread.a[shr_xpg5_64.o]) = 1894

Subroutine                 Ticks    %   Source                Address  Bytes
==========                 ===== ====== ======                =======  =====
.global_unlock_ppc_mp        634   2.07 pth_locks_ppc_mp.s      2d714     6c
._global_lock_common         552   1.81 ../../../../../../../../src/bos/usr/ccs/lib/libpthreads/pth_spinlock.c     2180    5e0
.global_lock_ppc_mp_eh       321   1.05 pth_locks_ppc_mp_eh.s    2d694     6c

위의 상황에서 키포인트는 다음과 같다.
  • Process 섹션에서 Kernel 시간이 매우 높다 (Total 시간의 거의 반).  
  • Shared Object 에서 libc와 libpthread 수치가 높다.
  • KERNEL 색션에서 ._check_lock 수치가  높다.
  • libc.a 섹션에서 .malloc_y와 .free_y 수치가 높다.
  • libpthread.a 섹션에서 .global_unlock_ppc_mp와 다른 비슷한 이름의 함수들의 수치가 높다.

AIX에서는 유용한 다른 Allocator 정책과 옵션을 제공한다.

Pool malloc
  • malloc system 의 frontend 격인 pool은 512byte나 그 이하의 메모리 블록 할당을 최적화한다.
  • 일반적으로 애플리케이션은 작은 메모리 블록들을 많이 할당하며, pool을 사용하게 되면 할당 패턴에 비추어 보았을때 일반적으로 시공간적 효율성이 높다.
  • pool malloc 방식은 단일/멀티 스레드 모두 좋은 선택이 될 수 있다. pool 과 multi heap을 조합하는 경우 멀티 스레드 애플리케이션의 충분한 대체제로 사용할 수 있다. 굉장히 일반적인 작은 메모리 블록 할당은 pool을 통해서 굉장히 효율적으로 관리된다. 더 큰 할당들은 multiheap malloc으로 확장성이 용이하게 관리된다. 아래의 설정으로 두 옵션을 복합적으로 사용할 수 있다.
    • export MALLOCOPTIONS=pool,multiheap

Buckets
  • 이 세부 옵션은 Watson allocator의 버킷 allocator 버전이라 할 수 있다. 그러나 이 옵션으로 bucket 수(버킷당 블럭수, 각 버킷 사이즈)를 조절할 수 있다. 이 옵션은 또한 각 버킷의 사용 통계를 볼 수 있는 방법을 제시하는데, 버킷 설정을 최적화 하는데 도움이 된다. 애필르케이션에서 특정 사이즈의 메모리할당 요청이 많이 발생한 경우 bucket allocator는 bucket옵션을 정확하게 기술함으로서 미리 요구한 크기를 할당하도록 설정할 수 있다. Watson 이나 malloc pool 옵션과 비교되는 점은, 512 바이트 미만이어야 한다. 

결론

  • 32bit 단일 스래드 어플리케이션의 경우 기본 할당자를 사용한다.
  • 64bit 어플리케이션의 경우 Watson allocator를 사용한다.
  • 멀티 쓰레드 어플리케이션의 경우 multi-heap을 사용한다. 힙 개수는 사용한 스레드 개수만큼 설정한다.
  • 513 바이트 미만의 작은 블럭에 대한 잦은 할당/해제가 발생하는 프로그램의 경우 malloc pool 옵션을 사용한다.
  • 특정 크기의 메모리 블록이 빈번하게 사용되고, 그 크기가 512바이트보다 크다면 malloc bucket 옵션을 설정한다.
  • 고성능을 요하며 메모리 파편화 이슈가 없는 오래된 어플리케이션의 경우 malloc 3.1을 사용한다.
  • 이상적으로 multiheap과 malloc pool option을 사용한 Watson allocator가 대부분의 multi-thread 어플리케이션에 좋다. front end에서 사용되는 pool 은 빠르며, multiheap은 크거나 작은 할당에 대한 확장성이 용이하게 한다. 
  • free이후에도 특정 어플리케이션의 메모리 사용량이 높은경우 disclaim 옵션이 도움이 된다. (export MALLOCDISCLAME=true)




참조



번역에 오류나 수정사항이 필요한 경우 덧글로 요청 바랍니다.



Introduction


기존 SSH 로그인 방식이 SSH 공격(예를들면 무작위 아이디와 비번으로 여러번 접속시도)에 취약하기때문에 나온 방식으로, key 파일이 되는 것을 생성한 후 접속 client 와 접속할 server에 두고 이를 이용하여 SSH를 접속하는 방식이다.

How to


0. 환경설정

a. 우선 ssh 명령이 먹어야 한다. OpenSSH 가 깔려있는지 확인해본다.
b. public key 를 설정한 후에는 SSH를 통한 로그인 부분은 전부 막아놔야 한다.



1. 키 생성 (클라이언트에서 해야할 일)

client$  mkdir ~/.ssh
client$  chmod 700 ~/.ssh
client$  ssh-keygen -q -f ~/.ssh/id_rsa -t rsa
Enter passphrase (empty for no passphrase):  
Enter same passphrase again:
client$  chmod go-w ~/
client$  chmod 700 ~/.ssh
cilent$  chmod go-rwx ~/.ssh/*

공식 사이트에서는 passphrase는 16글자 이상을 권고하고 있지만, 빈칸을 넣는 경우 암호없이 바로 접근할 수 있어서 편하다. 혹시 다른곳에서 키를 암호없이 생성해서 접근가능하지 않을까하는 걱정이 생길수도 있는데, 같은 서버내의 다른계정, 다른 서버내에서 같은계정으로 테스트해보았지만 접속이 되지 않았다. 즉, 암호없이 써도 안전하다. 게다가 암호를 넣게되면 나중에 추가적으로 해야할 귀찮은 일들이 있기 때문에 여기서는 암호없이 쓰는 것만 기술한다.



2. 키 설정 (서버에 해야할 일)

이제 클라이언트에서 생성한 키를 서버에 등록하는 과정이 남았다. 우선 key.pub 를 scp 를 통하여 서버의 자신의 계정에 복사해 둔다. yourid 는 서버내의 자신의 계정이다. 폴더는 자신의 홈폴더(기본적으로 /home/yourid)를 지정하면 된다.

client$  scp ~/.ssh/id_rsa.pub yourid@server.example.com:/home/yourid/

이제 서버에서 해당 key파일을 권한 인식 부분에 붙여넣어야 한다. 이때 cat >> 연산을 이용해서 authorized_keys 에 append 하게 되는데, 이를 통해 여러 클라이언트에서 생성한 키를 한곳에서 관리하게 된다.

server$  mkdir ~/.ssh
server$  chmod 700 ~/.ssh
server$  chmod g-w $HOME
server$  cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
server$  chmod 600 ~/.ssh/authorized_keys
server$  rm ~/id_rsa.pub

이제 접속 테스트를 해보자. 암호를 묻지 않고 바로 받아온다. ㅋㅋ 이외에도 프로그램중에 ssh 계정접속을 필요로 하는 프로그램들은 모두 암호를 묻지않게 된다. (대환영 ㅋㅋ)

client$  ssh yourid@server.example.com

Tip. 현재 설정한 .ssh 디렉토리를 다른 클라이언트의 디렉토리에 복사해도 다른 클라이언트에서 서버로 SSH 접속이 가능하다. 그래도 보안상 하는 것이므로 이왕이면 한개의 키로 모든 클라이언트에게 돌리는것 보단 귀찮더라도 각 클라이언트당 하나씩 키를 만들어 등록해 사용하길 바란다.

이로서 key 를 통한 ssh 접속설정 및 테스트를 해보았다. 간편한 접속과 좀 더 강화된 서버관리는 이를 사용하는 충분한 메리트가 되지 않을까 싶다. 집에 있는 서버에도 적용을 시켜야 겠다. ㅋ



Related Site



Issues

 

Issue
No firewall, no port used, but changing port to 9906 didn’t work. I’m on CentOS 5.9

 

Solution

 

테이블 폭 제약에 따라 긴 본문이 두줄에 걸쳐 출력되었는데 아래와 같은 현상이 발견되었다.

원문

발생현상

 해당 부분은 특정 컴퓨터의 특정 브라우저 ( Chrome 43.0 / IE 11 ) 에서 드물게 발생하였는데 아래와 같이 해결하였다


JSP

JSP 결과 페이지가 XML일때 브라우저 상에서 제목과 같은 메시지를 자주 보게 된다.

이는 XML 윗부분에 whitespace가 추가되었기 때문에 발생한다.

 

위와 같은 코드는 newline 이 발생되며, 아래와 같이 제거할 수 있다.

 

보다 근본적인 해결책은 실제 view 로 접근하는 jsp 파일의 최상단에 아래의 코드를 삽입하면 된다.

 

이렇게 하는 경우 해당 페이지에서 발생하는 모든 whitespace를 제거해준다.

C++

error LNK2019: __imp_WSAStartup

  • 원인 : ws2_32.lib 를 링크하지 않아서 발생하는 문제
  • 해결 : ws2_32.lib 를 추가

 

relocation 0 has invalid symbol index 11

  • 원인 : 빈 cpp 파일을 링킹할 때 발생하는 에러
  • 해결 : 빈 cpp 파일 제거


How to change encoding type

  • Press ⌘ + i in the iTerm window.
  • Click ‘Terminal’ tab.
  • Select what you want in the ‘Character Encoding’ field.


Little Endian & Big Endian

  • struct 의 경우 variable의 bit order 변경 뿐 아니라 variable의 순서도 바뀌게 된다. 따라서 아래와 같이 little endian에서 작성된 struct는 big endian machine 에서 역순으로 기술되어야 한다.

     

 

AIX

  • 속도적인 이슈로 인하여 char로 선언한 경우 default로 unsigned char로 동작한다.  xlc Compile Option 중 하나인  -qchar=signed 를 사용하여 gcc등의 다른 컴파일러와 같이 signed char로 동작하게 바꿀 수 있다.
  • 아래와 같은 에러가 발생한 경우 runtime 라이브러리 버전이 문제일 수 있다. xlC runtime 버전을 6.0.0.0 에서 8.0.0.0 으로 업데이트 진행하면 해결될 수 있다.

    관련링크 : IBM developerworks

HP UX

  • memory allocation 시 64bit의 경우 8byte, 32bit의 경우 4byte 단위로 alignment 를 잘 맞추어서 할당해야 한다. 구조체 생성시에도 padding 용 변수를 두어 alignment를 맞춘다. 아래 메시지는 memory alignment가 맞지 않은 경우 발생한 에러메시지의 일부를 발췌한 것이다.

     
  • memory allocation 부분에서 segfault 가 발생한 경우
    • gdb example
    • 원인 : 하나의 프로세스가 할당 가능한 데이터 세그먼트 합계를 지정하는 kernel parameter 값(maxdsiz, maxdsiz_64bit)이 작아 프로그램이 더이상 메모리를 할당하지 못하고 죽음
      • kernel parameter 확인 방법

         
      • 실제 물리 메모리 사이즈 확인 방법 (How to check Physical memory in HP-UX)

         
    • 해결 : root 권한을 이용해 해당 kernel parameter 값을 증가시킨 후 (32비트 : 2G , 64비트 : 64G로 설정하였음)  재부팅


1. Error when “yo angular”

  • "npm cache clean" and re-run the command “yo angular”

 

 

자주 사용하는 Bash 명령어들을 정리해보았다.

Array

Associative Array

 

Loop

Dir

 

grep

grep with string replacement (xargs)

 

find

 

 

sed

 

Installation

 

  1. Check the firewalls among servers. ( Recommended to open all ports among servers )
  2. Create same account( TEST_ACCOUNT ) to all servers.
  3. Create public key of TEST_ACCOUNT for each server. ( ssh-keygen )
  4. Authorize public key of TEST_ACCOUNT in master server to each slave server TEST_ACCOUNT so that master account can access each slave servers through ssh( FILE : $HOME/.ssh/authorized_keys ). Make sure the value of chmod of authorized_keys file is “0×600″ or it  doesn’t work.
  5. Copy hadoop-1.2.1 to the same directory of each server.
  6. Modify  $HADOOP/conf/masters & $HADOOP/conf/slaves to add master and slave servers. Copying modified file to each server is recommended.
    1. SAMPLE : masters

       
    2. SAMPLE : slaves

       
  7. Modify /etc/hosts to recognize hostname of each servers(sudo is needed.). Recommended to use same content among servers. I used hostname like “hadoop-master1″ or “hadoop-slave3″.
    1. SAMPLE : /etc/hosts

       
  8. Configure hadoop setting for each server.
  9. Run Format($HADOOP/bin/hadoop name node -format) and Start($HADOOP/bin/start-all.sh) at master server.

 

 

Tips

 

Format script

I used two masters with two mounted directories ( /data1 & /data2 ) and five slaves with three mounted directories( /data1 & /data2 & /data3 ). You can change the directory of your own. Locate this script to $HADOOP/bin

 

 

Trouble-shootings

 

1. Unregistered data node

  • This exception occurred because of different content of $HADOOP/conf/masters and $HADOOP/conf/slaves among servers.