검색 엔진의 방문이 늘어나고 있군...

Posted
Filed under 시스템
참조 원문 : Ubuntu Performance – Troubleshooting

  먹통이 되서 아무것도 할 수 없는 상황이 발생할 떄도 있을 겁니다. 그럴 때는 ALTSYSREQ(Print Screen) 키를 누른 상태에서 reisub를 순서대로 누릅니다. 주의할 점은 순서대로 너무 빨리 누르면 안 된다는 건데 그 이유는 각 키를 누를 때마다 특정 작업을 하기 때문입니다. 그래서 키를 누를 때마다 5초 정도 기다리는 것이 좋습니다. 키별 발생 작업은 아래와 같습니다.
  • r = XLATE로 전환
  • e = INIT을 제외한 모든 실행 중인 프로세스에게 종료 신호를 전달
  • i = INIT을 제외한 모든 프로세스를 죽임(종료 신호에 반응하지 않는 프로세스들을 강제로 처리)
  • s = 모든 파일시스템을 동기화(sync)
  • u = 파일시스템을 읽기 전용으로 다시 마운트
  • b = 시스템을 리붓
2013/07/08 13:04 2013/07/08 13:04
Posted
Filed under 시스템
참조 원문 : HTG Explains: Why Linux Doesn’t Need Defragmenting

  리눅스는 윈도우와 달리 조각 모음 유틸리티가 없습니다.(최근에는 윈도우도 없습니다.) 즉, 조각 모음을 할 필요가 없다는 건데요. 왜 파편화가 발생하는지, 리눅스와 윈도우 파일 시스템 사이에 어떤 차이점이 있는지 알아보겠습니다.

1. 조각이란?
  하드 디스크 드라이브는 작은 데이터 조각을 저장할 수 있는 섹터의 모음으로 이뤄져 있습니다. 파일은 몇 개의 섹터에 걸쳐 저장이 되죠. 파일 시스템에 몇 개의 파일을 저장한다고 가정할 때 각 파일들은 연속된 섹터에 걸쳐 저장됩니다. 그 이후 파일들 중 하나의 용량이 증가하면 파일 시스템은 증가된 부분을 바로 이어진 섹터에 적으려고 하는데 그 부분을 이미 다른 파일이 차지하고 있을 경우 다른 부분에 저장하게 되고 이렇게 되어 여러 조각으로 나뉘게 됩니다. 그리고 그런 파일을 하드 디스크에서 읽을 때 하드 디스크의 헤더가 여기저기 옮겨다니며 물리적으로 다른 위치에 있는 데이터를 읽어야 하기 때문에 속도가 느려집니다. 조각 모음은 흩어진 조각을 이동시켜 이어붙여 각 파일이 연속된 섹터를 차지하게 만드는 작업입니다.

  다만 SSD(Solid State Drive)는 기계적인 방식이 아닌 전자적인 방식을 통해 읽고 쓰기 때문에 조각 모음이 필요 없습니다. 오히려 많은 읽기/쓰기 작업으로 인해 수명만 대폭 감소하게 됩니다. 또한 최근 윈도우에서는 자동으로 조각 모음이 진행되기 때문에 별도로 조각 모음을 할 필요가 없습니다.


2. 윈도우 파일 시스템의 작동 방식
  MS의 옛날 파일 시스템인 FAT는 가장 무식한 방식으로 파일을 저장합니다. FAT 파일 시스템에 파일을 저장하려는 시도를 하면 최대한 디스크의 앞부분에 따닥따닥 붙여서 저장하려고 합니다. 그래서 파일 크기가 증가하며 항상 조각이 발생합니다.

  NTFS 파일 시스템은 약간 더 똑똑하게 파일 주변에 빈 공간을 확보합니다. 물론 사용하다보면 역시나 조각은 발생합니다. 최근 윈도우는 백그라운드에서 조각 모음 작업을 지속적으로 실시하여 문제를 최소화하고 있습니다.


3. 리눅스 파일 시스템의 작동 방식
  리눅스의 ext 계열 파일 시스템은 다수의 파일을 저장할 때 서로 가까운 곳에 저장하지 않고 여기저기 분산시켜 저장하여 파일들 사이에 큰 빈 공간을 남깁니다. 파일이 수정되어 커져도 충분하도록 말이죠. 만약 파편화가 발생하면 파일 시스템은 파편화를 줄이기 위해 그 파일을 다른 곳으로 옮기려고 합니다. 이런 방식으로 인해 파일 시스템이 거의 꽉 찼을 때 파편화가 발생하기 시작합니다. 대략 95%(경우에 따라 80%) 정도가 찬 이후로 조각이 발생하기 시작합니다.

  만약 어떻게든 강제로 조각 모음을 하고 싶다면 방법은 간단합니다. 파티션의 모든 파일을 다른 곳으로 복사 후 파일을 전부 지우고 다시 원래대로 복사해 넣는 겁니다. 그러면 파일 시스템이 파일들을 알아서 적절히 배치하게 됩니다.

  리눅스 파일 시스템의 파편화 현황은 fsck 명령어의 출력에서 "non-contiguous inodes" 항목으로 알 수 있습니다.
2013/07/03 13:45 2013/07/03 13:45
Posted
Filed under 시스템
참조 원문 : Linux Memory Management – Swapping, Caches and Shared VM

1. 리눅스 스왑핑(Swapping)
  프로세스가 가상 페이지를 물리 메모리에 올려야 하는데 물리 메모리에 여유 공간이 없으면 이미 물리 메모리에 있는 다른 페이지를 버려야 합니다. 만약 버릴 페이지가 실행 이미지나 데이터 파일에서 읽어들였으며 읽은 후 그 페이지에 쓰기를 하지 않았었다면 쉽게 버릴 수 있습니다. 왜냐면 필요할 때 같은 페이지를 같은 실행 이미지나 데이터 파일로부터 물리 메모리로 다시 옮겨오면 그만이기 때문입니다.

  하지만 그 페이지에 쓰기를 했었다면 문제가 복잡해집니다. 이런 페이지를 더티 페이지(dirty page)라고 부릅니다. 더티 페이지는 보존시켜서 나중에 다시 사용해야 합니다. 더티 페이지를 물리 메모리에서 버릴 때는 스왑 파일(swap file)이라는 특수 파일에 저장합니다. 바로 이것을 스왑핑(swapping)이라고 합니다.

  스왑 페이지에 접근하는데 걸리는 시간은 프로세서의 속도와 비교했을 때 엄청나게 느립니다. 그렇기에 OS는 좋은 스왑핑 알고리즘(버리느냐 스왑핑을 하느냐를 결정하는 알고리즘)을 가지고 있어야 합니다. 신통치 않은 스왑 알고리즘은 실제 처리는 안 하고 스와핑만 하며 시간을 잡아먹는 현상을 야기합니다. 이런 현상을 쓰래싱(thrashing)이라고 합니다.

  또한 어떤 프로세스가 계속해서 사용하는 일련의 페이지 세트를 워킹 세트(working set)라고 합니다. 좋은 스왑 알고리즘은 OS가 쓰래싱에 걸리는 것을 최소화해야 하며 모든 프로세스의 워킹 세트가 항상 물리 메모리에 있도록 만들어야 합니다.

  리눅스는 어떤 페이지가 메모리에 있어야 하는가와 어떤 페이지를 버려야 하는가를 결정하기 위해 '최근 최소 사용(Least recently used)' 스키마를 사용합니다.

  이 스키마에서는 물리 메모리에 있는 각 페이지가 나이 값을 가지고 있습니다. 나이는 페이지의 사용여부로 변합니다. 만약 페이지가 자주 사용된다면 나이가 매우 어릴 것이며, 사용되지 않으면 점점 늙게 됩니다. 더 늙은 페이지가 물리 메모리에서 스왑당하거나 버려집니다.


2. 캐쉬(Caches)
  캐쉬는 프로세서, OS, 그리고 그 둘 사이에서 벌어지는 처리를 더 빠르게 만들기 위한 개념입니다. 리눅스에서 중요한 캐쉬로는 아래와 같은 것들이 있습니다.

(1) 리눅스 스왑 캐쉬
  앞서 설명처럼 더티 페이지(물리 메모리에 올린 후로 내용이 변형된 페이지)만 스왑핑을 합니다. 또한 페이지가 변형되어 스왑된 후 다시 물리 메모리로 돌아온 상태에서 또 다시 스왑해야 할 때 페이지가 변한 게 없다면 스왑할 필요 없이 그냥 버리면 됩니다. 이렇게 해서 아낄 수 있는 시간이 꽤 됩니다. 이 개념을 실현하기 위해 리눅스에서는 스왑 캐쉬라는 것을 사용합니다.
  • 스왑 캐쉬는 물리 페이지 당 하나의 엔트리가 있는 페이지 테이블이다.
  • 각 엔트리는 스왑당한 하나의 페이지와 연관되어 있으며 스왑 파일에 대한 정보를 담고 있는데 그 정보란 스왑 파일 속 그 페이지의 정확한 위치다.
  • 스왑 캐쉬 안에 있는 페이지 테이블 엔트리 중 0이 아닌 게 있다면 그것은 스왑 파일 안에 있는 페이지를 뜻하며 그 페이지는 아직 변형되지 않았음을 뜻한다.
  • 어떤 페이지가 스왑 캐쉬 안에 자신의 엔트리를 가지고 있는 상태에서 변형됐다면 그 엔트리는 스왑 캐쉬에서 제거된다.
  • 이 방법으로 인해 캐쉬 안에는 마지막으로 스왑당한 뒤로 아직 변형되지 않은 페이지들만 남게 된다.
  이 방법을 통해 스왑 캐쉬는 스와핑 메커니즘의 효율성을 증대시킵니다.

(2) 하드웨어 캐쉬
  앞서 설명처럼 프로세서는 가상 주소를 물리 주소로 바꾸기 위해 페이지 테이블 엔트리를 읽습니다. 일반적으로 프로세서는 페이지 테이블 엔트리의 정보를 하드웨어 캐쉬에 저장합니다.

  이 하드웨어 캐쉬는 TLB(Translational look-aside buffer)들로 이뤄져 있습니다.

  프로세서는 가상 주소를 변환시킬 때마다 TLB로부터 페이지 테이블 엔트리 정보를 찾으려고 합니다. 만약 찾는데 성공하면 다음 일을 진행하지만 찾지 못한다면 OS에게 찾지 못했다는 사실을 알리며 문제를 해결하도록 지시합니다.

  OS에게 찾지 못했다는 정보를 전달할 때는 프로세서의 종류별로 다른 예외처리 메커니즘을 사용한다. OS가 알맞은 엔트리를 찾아 TLB 엔트리에 집어넣어 문제를 해결하면 프로세서는 TLB에서 그 엔트리를 다시 찾기 시작합니다.

(3) 리눅스 버퍼 캐쉬
  버퍼 캐쉬는 블록 디바이스 드라이버가 사용하는 데이터를 담고 있습니다.

  블록 디바이스 드라이버는 블록 단위로 데이터를 조작하는 것으로 고정된 크기의 데이터들이나 다수의 데이터 블록을 읽거나 쓸 수 있습니다. 버퍼 캐쉬는 여러 개가 존재하며 구분을 위해 디바이스 식별자(device identifier)를 사용합니다.

  버퍼 캐쉬는 읽기/쓰기를 매우 효율적이고 빠르게 해줍니다. 예를 들어 하드 디스크에 읽기/쓰기를 한다고 했을 때 그때마다 파일 I/O를 발생시키면 큰 시간을 낭비하게 되는데 버퍼 캐쉬는 그 사이에 위치하여 필요한 시기에 읽기/쓰기를 실시하고 남은 건 캐쉬에 쌓아 보관함으로서 시간을 절약하는 것입니다.

  스왑, 메모리, 페이지, 블록 IO, 트랩, 디스크, CPU 사용률은 vmstat이나 sar 같은 툴을 사용하여 볼 수 있습니다.


3. 공유 가상 메모리(Shared Virtual Memory)
  잘 작성한 코드에는 불필요하게 반복된 코드가 없습니다. 함수를 이용하면 같은 코드를 언제나 다시 부를 수 있죠. 자주 사용하는 함수들은 묶어서 라이브러리로 만듭니다. 공유 메모리도 이와 유사한데 뭔가를 메모리에 한 번만 올려놓고 여러 프로세스가 공용으로 사용하는 것입니다.

  가상 메모리는 프로세스가 메모리를 공유하기 쉽게 해주는데 왜냐하면 물리 주소는 페이지 테이블들을 통해 찾아간다는 점과 여러 프로세스의 페이지 테이블에서 같은 물리 페이지 프레임 번호를 쓸 수 있을 확률이 매우 높다는 점 때문입니다. 바로 이 개념이 공유 가상 메모리입니다.

2013/07/01 21:24 2013/07/01 21:24
Posted
Filed under 시스템
참조 원문 : Linux Memory Management – Virtual Memory and Demand Paging

가상 메모리(Virtual Memory)
  가상 메모리는 시스템이 실제보다 더 많은 메모리를 가지고 있는 것처럼 만들어줍니다.
  • 가상 메모리는 실제 물리 주소와 연결된 별도의 메모리 주소 계층이다.
  • 가상 메모리 모델에서는 프로세서가 프로그램 명령어를 실행할 때 가상 메모리로부터 명령어를 읽어 실행한다.
  • 하지만 명령어를 실행하기 전에 가상 메모리는 먼저가상 메모리 주소를 실제 물리 주소로 변환시킨다.
  • 이 변환은 페이지 테이블(OS가 관리함)에 있는 맵핑 정보를 기반으로 이뤄진다.
  가상 메모리와 물리 메모리는 페이지(page)라고 부르는 고정된 크기의 쪼가리로 나뉩니다. 이런 페이지 모델에서는 가상 주소를 두 부분으로 나눌 수 있습니다.
  • 오프셋(처음 12비트)
  • 가상 페이지 프레임 번호(나머지 비트 전부)
  프로세서가 가상 주소를 처리할 상황이 올 때마다 그것에서 가상 페이지 프레임 번호를 추출하여 물리 페이지 프레임 번호로 변환하며 그 후 오프셋으로 물리 페이지의 정확한 주소를 찾습니다. 이 주소 변환은 페이지 테이블을 통해 이뤄집니다.

  이론적으로 페이지 테이블에는 아래의 정보가 있다고 볼 수 있습니다.
  • 해당 엔트리가 사용 중인지에 대한 플래그
  • 이 엔트리의 물리 페이지 프레임 번호
  • 페이지에 대한 접근 정보(읽기 전용, 읽기/쓰기 등)
  가상 메모리의 가상 페이지 프레임 번호를 읽으면 그것을 오프셋으로 사용하여 그것이 가리키는 페이지 엔트리에 접근합니다. 예를 들어 가상 페이지 프레임 번호가 2라면 페이지 테이블의 1번 엔트리로 가게 됩니다.(엔트리 번호는 0부터 시작)

  아래 그림에서 VPFN은 가상 페이지 프레임 번호의 약자이며, PFN은 물리 페이지 프레임 번호를 약자입니다.

출처 : 참조 원문 페이지

  프로세서가 가상 페이지 프레임 번호로 페이지 테이블 엔트리를 처리하다가 잘못된 엔트리를 발견하는 일이 생길 수도 있는데 이런 경우 프로세서는 제어권을 커널에 넘긴 후 문제를 해결하도록 요청할 책임이 있습니다. 프로세서마다 제어권을 넘기는 방식은 다르지만 일반적으로 이런 현상을 '페이지 폴트(page fault)'라고 부릅니다. 엔트리가 정상이라면 프로세서는 물리 페이지 프레임 넘버와 페이지의 크기를 곱하여 물리 페이지의 기준(base) 주소를 구한 후 오프셋 값을 더하여 정확한 물리 주소를 계산합니다.

  각각의 프로세스는 전체 범위의 가상 주소를 자체적으로 소유하며 이런 개념 때문에 시스템이 실제보다 더 많은 물리 메모리를 가진 것처럼 보이는 것입니다.


페이징 요청(Demand Paging)
  프로세서가 가상 페이지 프레임 번호로 페이지 테이블을 처리하다가 아무것도 없는 엔트리를 건들이게 되는 원인은 2가지가 있습니다.
  1. 프로세스가 잘못된 메모리 주소로 접근하려고 했다.
  2. 가상 주소와 연결된 물리 페이지가 물리 메모리에 아직 올라가지 않았다.
  1번의 경우 프로세스가 허용되지 않는 메모리 주소로 접근을 시도하는 경우로 이때는 페이지 폴트가 발생하며 커널이 해당 프로세스를 종료시킵니다.

  2번의 경우에도 페이지 폴트가 발생하며 그 후 커널이 필요한 메모리 페이지를 하드 디스크에서 물리 메모리로 올리는 시도를 합니다.

  페이지를 하드 디스크에서 물리 메모리로 옮기는 일은 시간이 많이 걸리기 때문에 그 틈에 프로세스 간의 컨텍스트 스위치를 처리하거나 다른 프로세스를 실행합니다. 그러던 중 프로세스의 페이지가 물리 메모리로 옮겨지고 페이지 테이블이 업데이트되면 프로세스가 '페이지 폴트'를 일으켰던 명령어를 다시 실행합니다.

  이것을 페이징 요청(Demand Paging)이라고 부르며 이런 일이 발생한다는 것은 한 프로세스에 속한 모든 메모리 페이지가 동시에 전부 물리 메모리에 존재하지 않을 수도 있다는 것을 의미합니다. 이렇게 필요하지 않은 메모리 페이지를 올리지 않았다가 필요할 때 페이지 폴트를 통해 물리 메모리로 옮김으로서 물리 메모리를 아낄 수 있습니다.

2013/07/01 16:51 2013/07/01 16:51
Posted
Filed under 시스템
참조 원문 : Disable annoying bell in Gnome Terminal, vim, xterm, etc…

  터미널이나 쉘에서 작업을 하다보면 잘못된 조작을 할 때 소리가 울리는데 이게 귀에 거슬리는 경우가 많죠. 특히나 이 소리가 보드의 PC스피커에서 나온다면 짜증이 제곱으로 증가합니다. 이런 소리를 끄는 방법을 소개합니다.

1. Gnome Terminal의 경우
  • Gnome terminal을 연다.
  • Edit -> Profile Preferences
  • "Terminal bell" 해제

2. Vim 내에서만 안 나게 할 경우
  • ~/.vimrc에 set vb 라고 한 줄 추가

3. xterm의 경우
  • ~/.xsession에 xset b off 라고 한 줄 추가

4. Bash shell의 경우
  • ~/.inputrc에 set bell-style none 이라고 한 줄 추가

5. PC스피커 소리가 아예 안 나게 만들기(모듈 제거)
  • rmmod pcspkr 명령어 입력




2013/06/28 16:27 2013/06/28 16:27
Posted
Filed under 시스템
참조 원문 : What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 'console'?

  • 터미널 = tty = 텍스트 입출력 환경
  • 콘솔 = 물리적인 터미널
  • 쉘 = 커맨드 라인 인터프리터
  콘솔, 터미널, tty는 서로 깊은 연관을 갖고 있는데 본래 이것들은 컴퓨터와 상호작용을 위한 장비를 뜻합니다. 초기 유닉스 시절에 타자기를 닮은 전신 타자기(텔리프린터) 스타일의 장비를 사용했으며 이를 텔리타입라이터나 이를 줄여 'tty'라고 불렀던 것이죠. 터미널이란 용어는 전자적 관점에서 생긴 용어이며, 콘솔은 가구적인 관점에서 생긴 용어입니다. 유닉스 역사 중 극초반 시절에는 전자 키보드와 디스플레이 한 세트가 터미널의 표준 모습이었습니다.

  유닉스 전문 용어로 tty는 단순히 읽기와 쓰기를 넘어 몇 가지 추가적인 명령어를 지원하는 디바이스 파일을 뜻합니다. 그리고 터미널은 사실상 이 tty와 동일한 의미로 사용됩니다. 일부 tty는 하드웨어 디바이스를 위해 커널이 제공하며 그 예로 키보드에서 들어오는 입력과 텍스트 모드 화면으로 나가는 출력, 시리얼 라인을 통해 전송되는 입출력이 있습니다. 그 외의 tty는 씬 커널 레이어를 통해 터미널 에뮬레이터라고 불리는 프로그램으로 제공되며 이런 tty를pseudo-tty로 부르기도 합니다. 터미널 에뮬레이터로는 Xterm(X 윈도우 시스템), Screen(프로그램과 다른 터미널 사이에 독립적인 계층을 제공), SSH(한 머신에서 프로그램으로 다른 머신의 터미널에 연결), Expect(스크립팅 터미널 인터랙션용) 등이 있습니다.

  터미널이라는 단어는 컴퓨터와 상호작용을 하기 위한 디바이스라는 더 고전적인 의미도 가지고 있는데 이는 일반적으로 키보드와 디스플레이로 구성됩니다. 예를 들어 X 터미널은 씬 클라이언트의 일종으로서 키보드, 디스플레이, 마우스, 경우에 따라 그 외의 인터랙션용 주변 장치의 수용만을 위해 존재하는 특수목적 컴퓨터이며 이때 실제 애플리케이션은 더 성능이 좋은 다른 컴퓨터에서 실행됩니다.

  콘솔은 일반적으로 머신과 직접 연결된 물리적인 1차 터미널을 말합니다. 콘솔은 OS에서 커널에 의해 tty로 나타납니다. 리눅스나 FreeBSD 등 일부 시스템에서는 다수의 tty가 존재합니다.(특수한 키 조합으로 이 tty사이를 옮겨다닐 수 있습니다.)

  은 유저가 로그인했을 때 볼 수 있는 1차 인터페이스로서 그 주목적은 다른 프로그램을 실행하는 것입니다. 유닉스에서는 커맨드라인 쉘을 뜻하는 경우가 대부분이며 다른 종류의 작업 환경에는 쉘이란 단어를 쓰지 않는 편인데 예를 들어 윈도우 시스템에서는 Window Manager와 Desktop Environment라는 용어를 사용합니다. 유닉스에는 많은 쉘이 있지만 대부분은 Bourne Shell의 문법을 기반으로 합니다. 터미널과 쉘의 업무영역을 구분짓는 것은 쉽지 않은편인데 아래는 주요 역할의 예제들입니다.
  • 입력: 터미널은 키를 컨트롤 시퀀스로 변환(예: 왼쪽 방향키 -> \e[D)시킵니다. 쉘은 컨트롤 시퀀스를 명령어로 변환(\e[D -> backward-char)시킵니다.
  • 줄 편집, 입력 히스토리, 자동 완성은 쉘에 의해 제공된다.
    • 터미널이 줄 편집, 히스토리, 자동 완성을 대신 제공하고 완성된 최종 내용을 쉘에 전달하는 경우도 있다. 일반 터미널 중 이런 방식으로 작동하는 것은 Emacs의 M-X 쉘 뿐이다.
  • 출력: 쉘이 "'foo'를 출력하라", "포어그라운드 색을 초록색으로 변경하라", "커서를 다음 줄로 옮겨라" 같은 명령을 내리고 터미널은 이 명령을 수행한다.
  • 프롬프트는 전적으로 쉘이 담당한다.
  • 쉘은 자신이 실행한 명령의 출력 결과를 전혀 보지 않는다.(단, 리다이렉트된 것은 제외.) 출력 히스토리(스크롤 되돌리기)는 전적으로 터미널이 담당한다.
  • 애플리케이션 사이의 복사/붙여넣기는 터미널이 제공한다.(일반적으로 마우스나 Ctrl+Shift+V, Shift+Insert 같은 키 시퀀스를 사용.) 쉘이 자체적인 복사/붙여넣기 메커니즘을 가지고 있는 경우도 있다.(예: Meta+W와 Ctrl+Y)

 

2013/06/23 13:47 2013/06/23 13:47
Posted
Filed under 시스템
참조 원문 : Using the /proc filesystem

1. /proc/[pid]/
  /proc에는 시스템에 존재하는 각 프로세스의 PID와 동일한 이름의 디렉토리들이 있다. 이 아래 어떤 디렉토리가 있는지 보자.

1-1. /proc/[pid]/cmdline
  해당 프로세스를 실행하기 위해 사용한 명령어를 담고 있다.

1-2. /proc/[pid]/cwd
  프로세스가 현재 작업 중인 디렉토리를 향한 심볼릭 링크다.

1-3. /proc/[pid]/status
  프로세스의 이름, 상태, pid, ppid, 소유자 등의 정보를 담고 있다.

2. /proc/cmdline
  부팅 시 커널에 넘겨진 모든 인자들을 담고 있다.

3. /proc/cpuinfo
  아키텍쳐, 주파수, CPU의 캐쉬량 등 프로세스 관련 정보를 담고 있다.

4. /proc/filesystems
  현재 커널이 지원하는 모든 파일 시스템의 목록이 있다. nodev로 시작하는 항목은 네트워크 파일시스템이나 proc 같은 비물리적 파일시스템이다.

5. /proc/loadavg
  시스템의 평균 부하율(load average)에 대한 정보를 담고 있다. 첫 3개의 필드는 uptime으로 볼 수 있는 정보와 동일하다.
  네 번째 필드는 슬래쉬로 나눠진 2개의 숫자로 되어 있다. 첫 번째는 현재 실행 중인 프로세스/스레드 수를 나타낸다. 이 값은 시스템에 있는 프로세서 코어의 수를 넘지 않는다. 두 번째는 시스템에 있는 프로세스/쓰레드의 수를 나타낸다.
  다섯 번재 필드는 가장 최근에 생성된 프로세스의 PID 값이다. 이 부분은 주의가 필요한데 만약 'cat /proc/loadavg'라는 명령을 실행한다면 이 값이 실행된 cat 프로그램의 PID로 바뀌기 때문이다.

6. /proc/net/
  네트워킹 레이어에 대한 많은 파일이 있다. 모든 파일은 아스키로 되어 있어 읽을 수 있다.

6-1. /proc/net/arp
  arp 테이블을 담고 있다.

6-2. /proc/net/dev
  인터페이스별로 송신, 수신한 패킷 및 바이트 같은 정보가 있다.

6-3. /proc/net/route
  라우팅 테이블이 16진수 형태로 있다.

6-4. /proc/net/wireless
  품질이나 버린 패킷 수 등 현재 무선 연결과 관련된 정보를 담고 있다.

7. /proc/swaps
  사용 중인 스왑의 양과 스왑 파티션의 우선순위를 담고 있다.

8. /proc/sys/kernel/hostname
  시스템의 현재 호스트명을 담고 있다. "echo '새로운 호스트명' > /proc/sys/kernel/hostname"을 통해 변경할 수 있다.

9. /proc/sys/kernel/threads-max
  시스템에 동시에 존재할 수 있는 프로세스/쓰레드의 최대 개수를 정의하고 있다. /proc/loadavg의 네 번째 필드에 있는 현재 프로세스/쓰레드의 개수와 비교해보자.

10. /proc/sys/vm/swappiness
  커널이 얼마나 메모리를 어느 정도 스왑할지를 제어하는 값이 있다. 이 값을 높이면 커널은 더 자주 스왑을 하려고 할 것이며, 낮추면 스왑을 덜 하려고 할 것이다. 기본 값은 60이다.

11. /proc/uptime
  두 값이 있는데 첫 번째는 시스템이 시작된 후로 지난 시간(초)이며, 두 번째는 idle 상태로 보낸 시간이다. 이를 이용한 아래 명령어를 통해 idle로 존재한 시간을 백분율을 알 수 있다.
echo `cut -d' ' -f2 /proc/uptime` / `cut -d' ' -f1 /proc/uptime` | bc -l
12. /proc/vmstat
  가상 메모리 현황을 담고 있다.

13. /proc/sys/net/ipv4/conf/default/forwarding
  커널이 tcp forwarding을 허용할지를 제어한다. 디폴트 값은 0이며 포워딩 금지를 뜻한다.
2013/06/21 12:55 2013/06/21 12:55
Posted
Filed under 시스템
제가 이쪽에 대해 잘 아는 건 아니지만 윈도우와 리눅스 사이에서 데이터를 옮기다 보면 워낙 많이 겪는 문제라 이참에 아는 한도 내에서 정리를 하려고 합니다. 이 글에서는 윈도우에서 작성한 파일을 리눅스에서 읽었을 때 일어날 수 있는 문제와 해결 방법을 중심으로 이야기를 풀어나가겠습니다. 틀린 내용이 있을 수 있으므로 본문 내용을 너무 믿지 마시기 바랍니다;;

  일단 윈도우는 문자 인코딩에서 코드 페이지라는 것을 사용합니다. 코드 페이지는 IBM이 정의한 문자 인코딩 표인데 문자의 종류(예를 들어 그리스 글자, 한국어 글자, 일본어 글자 등)별로 번호가 있습니다. 즉, 각각의 코드 페이지는 각각의 인코딩 방식을 뜻합니다. 예를 들어 한글 윈도우는 CP949라는 코드 페이지를 사용하며 이를 두고 'CP949 인코딩을 사용한다'라고 할 수 있습니다.

  문제는...이 CP949가 표준 인코딩이 아니라는 것에 있습니다. CP949와 유사한 인코딩으로 EUC-KR이라는 것이 있습니다. 둘이 비슷하여 대부분의 문자가 호환되다보니 CP949와 EUC-KR을 같은 것으로 알고 있는 경우가 많습니다만 사실 CP949는 EUC-KR의 확장판으로서 EUC-KR에서 표현이 불가능한 문자를 표현할 수 있습니다.

CP949 인코딩 구조(출처: 위키피디아)
  위 그림에서 KS X 1003과 KS X 1001 부분을 사용하는 것이 EUC-KR이며 보라색 부분을 추가로 사용하는 것이 바로 CP949입니다. 그러므로 CP949는 EUC-KR에 대해 하위 호환성을 가지고 있습니다.

  그럼 이게 어떻게 문제가 되는지 실제로 한 번 알아보겠습니다. 먼저 윈도우에서 메모장을 통해 "test.txt"라는 이름의 텍스트 파일을 하나 만들고 그 안에 "가나다"라는 내용을 집어넣어 리눅스 서버에 옮긴 후 터미널을 통해 접속하여 그 내용을 출력할 겁니다. 터미널 프로그램은 putty를 이용하겠습니다.

  먼저 서버에 접속 전에 아래의 그림처럼 서버로부터 전송받은 문자 코드 값을 어떤 인코딩 방식으로 변환하여 출력할 것인지 정해야 합니다. 이를 위해 한글 윈도우에서 사용하는 인코딩 방식인 CP949를 입력합니다. 참고로 CP949는 탑다운 목록에 없기 때문에 수동으로 입력해야 합니다.

사용자 삽입 이미지
  그리고 한글을 적을 수 있도록 한글이 있는 폰트를 선택하고 스크립트도 한글로 선택합니다.

  이제 서버에 접속해서 서버의 로케일이 CP949가 아님을 확인하고 파일의 내용을 출력해보겠습니다.
mirashi@myservlab:~$ echo $LANG
ko_KR.UTF-8
mirashi@myservlab:~$ cat test.txt
가나다
  그런데 서버의 로케일이 UTF-8임에도 불구하고 CP949 인코딩을 사용한 텍스트 파일의 내용이 잘 보이는 것을 확인할 수 있습니다. 그 이유는 파일의 내용을 가감 없이 출력만 했기 때문입니다. 이를 쉽게 설명하자면 아래와 같습니다.
  1. 이 파일의 내용은 CP949 인코딩을 사용하여 작성되었다.
  2. 서버는 파일의 16진수 값을 그대로 터미널 프로그램으로 전송하였다.
  3. 전송을 받은 터미널 프로그램은 그 값을 CP949로 인코딩해서 우리에게 보여주었다.
  즉, 파일은 CP949 인코딩으로 작성됐고 앞서 처음 터미널을 설정할 때 서버로부터 전송받은 문자 코드 값을 CP949로 변환하여 화면에 보이도록 설정했기 때문에 서버의 로케일이 무엇이 됐던 간에 제대로 된 결과를 볼 수 있는 겁니다.

  그렇다면 이제 아무것도 문제가 없는 걸까요? 위는 어디까지 파일의 내용을 단순히 출력했을 때만 해당되는 이야기입니다. 만약 지금 상황에서 파일이나 디렉토리를 한글로 만들면 어떻게 될까요?
mirashi@myservlab:~/test$ touch 한글
mirashi@myservlab:~/test$ ls
?畸?
  이제 문제가 보이기 시작했습니다. 아까 putty를 설정할 때 사용할 캐릭터 셋을 CP949로 설정했기 때문에 '한글'이라는 문자열을 넘겨줄 때는 CP949로 넘어갑니다. 그런데 지금 서버에서 사용하고 있는 인코딩 방식은 UTF-8입니다. 저(=터미널)는 '한글'이란 문자열을 CP949의 코드로 넘겨주고 서버는 일단 불만 없이 이를 파일명으로서 파일 시스템에 저장합니다. 그 후 ls로 파일명을 출력하도록 하니 UTF-8를 사용하는 시스템 입장에서는 이해할 수 없는 문자 코드였기 때문에 이상한 결과가 출력되는 겁니다. 이는 로케일을 EUC-KR로 바꾸면 제대로 출력된다는 것을 통해 증명할 수 있습니다.
mirashi@myservlab:~/test$ LANG=ko_KR.UTF-8
mirashi@myservlab:~/test$ ls
?畸?
mirashi@myservlab:~/test$ LANG=ko_KR.EUC-KR
mirashi@myservlab:~/test$ ls
한글
  편법으로 ls를 사용할 때 제어 문자도 강제로 출력하게 하는 --show-control-char 옵션을 사용하면 문자 코드를 해석하지 않고 그대로 출력하기 때문에 로케일이 UTF-8라도 제대로 된 출력을 볼 수 있긴 합니다.
mirashi@myservlab:~/test$ ls
?畸?
mirashi@myservlab:~/test$ ls --show-control-char
한글
  하지만 이건 어디까지나 편법일 뿐 정상적인 방법이라고 볼 수 없습니다. 이런 문제는 파일을 편집하려고 할 때 더욱 부각됩니다.

  위는 "가나다"라는 내용이 CP949로 저장되어 있던 test.txt 파일을 vi 에디터로 열었을 때 볼 수 있는 상황입니다. 이제는 문자 코드를 읽어서 로케일에 설정된 인코딩 방식에 따라 보여주기 제대로 보는 것 조차 불가능합니다.(단, 옵션들을 통해 가능하긴 합니다) 참고로 아래에 글씨가 깨지는 건 현재 로케일이 UTF-8로 되어 있는데 터미널에서는 CP949로 번역하고 있기 때문에 그런 겁니다.

  위는 서버의 로케일을 EUC-KR로 바꾼 후 vi 에디터를 다시 실행한 모습입니다.

사용자 삽입 이미지
  이제 제대로 표시는 되는군요. 그런데 또 다른 문제가 있습니다. 지금 사용하고 있는 인코딩 방식은 EUC-KR이며 이 인코딩 방식은 표현하지 못하는 한글들이 있습니다. '똠' 같은 글자도 그런 글자 중 하나입니다. 이는 vi 에디터에서 인코딩과 관련된 몇 가지 명령어를 통해 해결할 수 있긴 하지만 근본적으로 이런 작업이 필요하다는 사실 자체가 문제라고 볼 수 있겠죠.

  앞서 본 모든 문제들은 한글 윈도우(더 나아가 전 세계의 모든 OS)가 세계 표준이라고 할 수 있는 UTF-8 인코딩 방식을 사용하면 완전히 해결되겠습니다만 만약 진짜로 그렇게 되면 기존 데이터들로 인해 한 동안 대혼란이 발생할 거고 그로 인한 비난은 (비록 자신들이 스스로 자초한 거지만)고스란히 MS가 받을 테니 그들이 그런 선택을 할 것이라고 기대하긴 어렵습니다. 결국 한 동안은 이런 문제가 지속될 것 같군요.

2011/07/24 03:08 2011/07/24 03:08
Posted
Filed under 시스템
출처 : 8가지 획기적인 데이터센터 전력 비용 절감 방안

  전력에 소요되는 비용을 줄이기 위한 흥미로운 기사입니다. 다른 것도 상식적으로 알아두면 좋겠지만 SSD 같은 이야기는 직접적으로 도움이 되지 않을까 싶습니다.


1. 냉방기의 최대 설정 온도를 상향
  온도가 높을 경우 기계의 고장률이 올라가지만 생각을 뒤집어 요즘같이 하드웨어가 싸다면 부품이 고장나서 잃는 손실보다 냉방기 사용 감소로 얻는 이득이 더 높다는 겁니다. 특히 클라우드 환경의 경우 한두 개의 컴포넌트가 고장난다고 서비스가 중단될 일은 없으므로 더 적합할 것 같습니다. 단, 일정 수준을 넘으면 머신에 달린 팬의 RPM 증가로 전력 소모가 늘어나 효과가 반감될 수 있습니다.

2. 미사용 서버 전원 오프
  사용률이 적으면 로드 밸런싱 같은 이유로 돌리는 여분의 서버를 오프시키라는 겁니다. 긴급 상황 시 부팅 시간이 걱정이라면 부팅 진단 검사 넘기기, 스냅샷 이용, 웜-스타트 기능 이용 등을 방안을 활용하라고 하는데...운용자 입장에서는 확실히 좀 부담스러운 방법이긴 하네요.

3. 바깥 공기 유입
  바깥의 온도가 낮을 경우 그 공기를 유입하여 냉방을 하는 방식입니다. 물론 그냥 덕트 뚫고 공기만 빨아온다고 되진 않습니다. 바로 외부 공기의 미세 먼지들이 기계에 악영향을 끼치기 때문입니다. 따라서 공기를 끌어오기 전에 정화 시설을 통과시켜야 합니다.

4. 데이터센터의 열을 사무실 난방에 이용
  제목 그대로 입니다. 서버실의 공기를 사무실로 유입시킵니다. 서버실에서 발생하는 뜨거운 공기는 화학적으로 오염을 걱정할 필요가 없습니다.

5. 거의 읽기 작업만 하는 서버는 SSD를 사용하라
  SSD는 빠른 속도, 낮은 전력 소모, 거의 없는 발열이라는 장점에도 불구하고 높은 비용과 쓰기 횟수의 한계라는 큰 단점으로 인해 서버에 쓰기에 문제가 좀 있지만 읽기에 역할이 집중된 서버라면 이야기가 다릅니다. 이때 사용하는 SSD는 가격이 더 비싸더라도 SLC가 적합한데 이유는 수명이 10배에 달하기 때문입니다. 또한 다중 채널로 구성된 서버용 SSD를 사용하는 것이 좋습니다.

6. 직류 전류 이용
  컴퓨터는 직류 전류로 동작하는데 2000년 초반에는 전원 변환 효율이 낮아 바로 직류를 사용하는 일이 많았습니다. 그 후 변환 효율이 높아져 인기가 시들어지다가 최근 고전압 장비들의 등장으로 다시 인기를 얻고 있습니다. 이렇게 교류전압-직류전압의 변환 과정 없이 직류전압의 크기만 변환시켜주면 손실되는 전력과 방출되는 열이 크게 줄일 수 있습니다.

7. 사용한 냉각수를 땅에 내리기
  땅 아래에 파이프를 연결하여 사용한 냉각수를 땅 속으로 전도시키는 방법입니다. 기구 설치 시 높은 사전 분석이 필요합니다.

8. 바다에서 냉각수 끌어오기
  반대로 저온의 바닷물을 인근에서 끌어다 쓰는 방법입니다. 시설이 호수나 바다 근처에 있어야 하겠지만 효과는 매우 큽니다.

2011/04/08 13:34 2011/04/08 13:34