유닉스 시스템에서 *는 모든 글자를 의미하고, ?은 한 단어를 의미한다.

특이하게도 cat a? 하면 a로 시작하고 2글자의 파일 이름을 가진 모든 파일을 의미하는데,

cat ?는 한 글자로 된 모든 파일 이름을 출력한다는 의미를 가진다. 

한 글자 파일이 없을 때 아래와 같은 에러가 발생한다.

한 글자 파일을 생성하고 cat ?을 실행해본다. 한 글자 파일을 출력한다.

파일 명을 보고 싶다면, echo *을 실행한다.

2글자 이상의 파일명을 보려면 다음과 같이 실행한다.

$ echo ??*

참고로 *를 살펴본다.

echo * 커맨드를 실행하면 현재 디렉토리의 모든 이름을 출력한다. 중요한 것은 알파벳 순서대로 출력된다.

쉘은 *을 분석해 현재 디렉토리의 모든 파일을 검색해서 파일 이름 대체(filename substitution)하는 작업을 진행한다.  따라서 echo의 매개변수 개수는 1개가 아니라 현재 디렉토리의 파일 개수가 된다.

x=*의 값은 현재 디렉토리의 값이 된다. 

쉘이 커맨드 라인을 파악하는 단계는 다음과 같다. 

1. 쉘은 x 값으로 * 를 대체하여 라인을 스캔했다.

2. 쉘은 라인을 다시 살펴보고 * 를 발견 한 후 현재 디렉토리의 모든 파일 이름을 대체했다.

3. 쉘은 echo의 실행을 시작해 파일 목록을 매개변수로 전달했다.

(변수 대체를 먼저 진행하고 파일 대체를 진행한다)

grep에서 *를 사용할 때도 유의할 필요가 있다. 

특정 파일에서 '*'만 검색하려고 할 때  $ grep '*' file 을 사용할 수 있지만,

$ grep * file을 사용할 때 *는 현재 디렉토리의 모든 파일을 의미한다. 

아래 예시에서 의미를 파악할 수 있다. 

참조 

https://en.wikipedia.org/wiki/Glob_(programming)

여러 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이다. 

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

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

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

jvm(일반 애플리케이션)이 실행 중인 서버에서 slab memory가 끊임없이 늘어나는 현상이 발견되었다.

* slab 메모리가 있는지 확인하기 위해 다음 링크를 참조하면 쉽게 slab 메모리 정보를 구할 수 있다. (/proc/meminfo에서 Slab 영역을 얻는다)

http://atomitech.jp/hinemos/blog/?cat=12

#!/bin/bash

total=`cat /proc/meminfo | grep MemTotal | awk '{print $2}'`
free=`cat /proc/meminfo | grep MemFree | awk '{print $2}'`
buff=`cat /proc/meminfo | grep Buffers | awk '{print $2}'`
cache=`cat /proc/meminfo | grep ^Cached | awk '{print $2}'`
slab=`cat /proc/meminfo | grep Slab | awk '{print $2}'`
used=`echo "scale=2; ($total - $free - $buff - $cache - $slab) * 100 / $total" | bc`
echo "used,$used"

참고로 jvm 메모리 상태를 확인하며 gc 여부를 확인했지만 특별히 변경 내역은 없었다.

$ jstat -gc 프로세스-id 1 1

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT

 0.0   2048.0  0.0   2048.0 2383872.0 624640.0 1808384.0  1099923.5  61056.0 60410.3 7296.0 7135.3  32873  338.821   3      0.999  339.821

jvm은 이슈가 아닌 것 같고, vmstat으로 메모리 상태를 확인했다. 

각 필드의 항목 내용은 Num  Total   Size  Pages이다. 확실히 개수와 용량이 늘긴 늘었다

(vmstat 참고 : https://www.thomas-krenn.com/en/wiki/Linux_Performance_Measurements_using_vmstat#vmstat_-m)

다른 장비에서 동일한 명령어를 실행해서 동일하게 메모리를 확인했다. 

확실히 inode 캐시 값이 너무 커졌다. 이를 정리하기 위해 운영 체제의 vfs_cache_pressure를 사용해야 했다.

jvm이 통신하면서 임시로 메모리 공간(pagecache)을 사용한 것 같은데, 정리가 안되면서 커진 것 같았다.  캐시 데이터는 centos 내부적으로 slab 메모리로 관리된다. inode가 커널의 slab 메모리에서 관리되기 때문에 inode와 slab 메모리가 상당히 커진 것 같았다. 

vfs_cache_pressure는 pagecache를 반환하려는 값이 저장되어 있다. 기본값은 100이다. 위의 문서에 설명되어 있듯이 0이면, 메모리 반환을 하지 않고, 1000을 설정하면 계속 free공간으로 메모리를 반환하려 한다.

나는 아래와 같이 값을 큰 값을 주어 자연스럽게 slab 메모리가 빨리 정리되게 했다. 

문제는 전혀 발생하지 않았고, slab 메모리를 깔끔히 정리되었다. 

이 외에 다른 방법이 있다고 한다. 

참고로 hbase에서는 이슈가 있었다고 하니. 부하가 높은 상황에서는 조심히 사용할 필요는 있을 것 같다. 

https://brunch.co.kr/@alden/14

커보러스 티켓 생성하기

커보러스 티켓 확인하기

티켓을 삭제하는 방법

centos의 git을 설치하면 (yum install git), 버전이 낮은 git이 설치된다. 따라서 git 명령어를 잘 인식 못할 수 있다.

현재는 yum install git으로 설치하면 2.2를 설치한다.

최신 git 을 설치하는 방법을 소개한다.

https://www.kernel.org/pub/software/scm/git/ 에 접속한다.

최신 버전을 찾는다. 현재는 2.9.3이 최신이다.

만약 root 사용자라면, ~/etc/bashrc를 수정한다.

공개키가 포함된 인증서와 개인 키를 생성하는 예제이다.

centos 7 부터 키 생성 방법이 엄청 편해졌다.

키가 정상적인 지 확인하려면, 다음 커맨드를 실행해서 공개 키와 개인 키를 기반으로 나온 결과 값이 동일한지 확인한다.

ssh 연결시 다음 에러가 발생했다.

ssh 인증시. 에러가 발생했고, 이를 해결하기 위해 ssh -v를 실행했다. 로그가 자세히 출력되고 힌트를 얻을 수 있다.

ssh -o StrictHostKeyChecking=no 추가하면 문제 없이 로그인할 수 있다. 

yum 캐시 데이터로 인해서 잘못된 동작이 일어날 수 있다. 이럴 때, yum의 캐시를 정리할 수 있다.

캐시된 패키지 정보를 모두 삭제하는 커맨드이다.

캐시된 XML 기반의 메타데이터를 삭제한다.

캐시된 모든 데이터베이스 파일을 삭제한다.

사용하지 않는 불필요한 디스크 공간을 정리하고, 동시에 이전 커맨드와 같이 캐시된 모든 파일을 삭제한다.

다음 커맨드를 실행하여 yum 캐시를 재구성한다.

저널 로그를 보려면 다음과 같다. 센트OS 7의 시스템 서비스의 대부분은 저널 로그에 저장된다.

기간별 검색이 가능하다.

어제부터 sshd.service 로그를 보고 싶다.

에러 타입에 대한 저널 로그를 살펴본다.

상세로그를 보려면 다음을 실행한다.

상세로그를 tail -f 처럼 보고 싶을 때 다음처럼 실행한다.

참고로, 도커 설정 파일에도 다음과 같은이 저널 로그를 설정되어 있다.