여러 java 데몬을 띄워 테스트를 진행하던 중, 자바 데몬에서 특정 포트(40000)를 리스닝하기 위해 실행 중에 아래와 같은 에러가 발생하고 종료되었다.


java.net.BindException: Address already in use


netstat으로 보면, 40000으로 분명 리스닝하는 포트가 없었다. 하지만, TIME_WAIT 클라이언트 포트가 있었다. 즉, 

 curl로 es schema를 생성하면서 40000번 포트를 사용했다. 


따라서, curl이 사용한 클라이언트 포트와 리스닝하려는 자바 데몬간의 충돌이 발생했다.


그렇다면, centos 6.7 기준으로 보면, curl이 사용한 포트 범위는 어떨까? sysctl 로 확인하면 클라이언트에서 사용할 수 있는 포트 범위는 32768부터 60999이다. 


$ sysctl -A | grep local_port_range

net.ipv4.ip_local_port_range = 32768 60999



따라서, 리스닝하는 포트를 쓰려면 32767 이전 포트를 사용하는 게 가장 안전하다.


저작자 표시
신고
Posted by 김용환 '김용환'


ssh를 사용하여 리모트 파일이 존재하는 지 확인하려면, 다음과 같다.


already_copied=`ssh -l deploy s17.internal.io 'ls /tmp/test > /dev/null 2>&1' `

result=$?

if [ ${result} == 0 ]; then

  echo "file exists"

else

  echo "file does not exist"

fi



고급스럽게 사용하려면, ssh와 stat을 사용한다.




if ssh s17.internal.io stat /tmp/test \> /dev/null 2\>\&1

  then

    echo "file exists"

  else

    echo "file does not exist"

fi

저작자 표시
신고
Posted by 김용환 '김용환'




나는 Redis에 대해 많이 모르는 것 같다. 공부 많이 해야 할 것 같다.


이 책은 나처럼 Redis와 Redis 3를 좀 더 알고 싶은 사람들에게 추천한다. 몰랐던 내용을 아는 기쁨.







http://www.acornpub.co.kr/book/redis-essentials

http://www.yes24.com/24/goods/30503660




역자 소개

프로그래밍을 시작하면서 캐시 솔루션에 대해 많은 고민을 했다. 캐시는 사용할 데이터를 웹 애플리케이션 내부 메모리에 저장하면 성능을 개선할 수 있지만, 데이터 양이 너무 많다면 메모리 이슈가 발생하기 때문이다. 특히 자바의 경우는 JVM 튜닝이 필수적이었다. 웹서비스가 성장하면서 캐시 솔루션이 많이 등장하기 시작했다. 때마침 LiveJournal에서 개발되고 페이스북에서 사용한 멤캐시드(memcached)와 함께 레디스를 캐시 솔루션으로 사용할 기회가 생겼고, 캐시 솔루션에 대한 다양하게 활용해 볼 수 있었다. 현재 웹 애플리케이션은 캐시 아키텍처 덕분에 간결해지고 성능이 더욱 좋아지고 있다. 여러 프로젝트에서 레디스를 사용해봤지만, 이 책을 통해 레디스에 대한 충분히 이해함으로써 시야를 많이 넓힐 수 있었다. 기존에 사용하던 레디스 타입뿐 아니라 다양한 타입을 제대로 이해하고 활용할 수 있게 됐고, 트웸프록시(Twemproxy), 레디스 센티널(Redis Sentinel), 레디스 클러스터(Redis Cluster)의 장점과 단점을 더욱 세밀하게 알 수 있었다.
이 책을 통해 레디스 클러스터를 실전 배치에서 사용하게 됐다.
레디스를 처음 접하는 분, 레디스를 속속들이 알고 싶은 분, 레디스 3에 대해 제대로 알고 싶은 분, 다양한 언어의 레디스 클라이언트를 알고 싶은 분들에게 이 책을 추천한다.


(오타 수정)


저작자 표시
신고
Posted by 김용환 '김용환'


티스토리 툴바