Java World

Java Korean

Author Archives: heewoo

ERROR class 클래스명 is public, should be declared in a file named 클래스명.java

Posted on by Posted in Java

발생되는 경우 클래스명이 public으로 선언되었는데 파일명과 다를 경우

조 언 public으로 선언된 클래스가 있다면 반드시 그 클래스명과 파일명이 같아야 한다.

클래스명과 파일명의 대소문자 및 철자가 같은지 비교해 본다.

또한, public으로 선언된 클래스가 하나 이상 있는지 찾아본다.(반드시 하나만 있어야한다.)

ERROR valiable 변수명 might not have been initialized

Posted on by Posted in Java

발생되는 경우 지역변수인 변수명의 변수가 초기화가 되어있지 않았을 경우

조 언 지역변수(메소드 내에서 선언한 변수)를 초기화 하지 않은채 선언했을 경우 발생한다.

멤버 필드가 아닌 경우는 반드시 변수 선언시 초기화를 해주어야 한다.

(멤버 필드는 자바 프로그램 자체에서 자동으로 default값으로 초기화 해준다.)

ERROR non-static variable 변수이름(or method 메소드이름) cannot br referenced from a static context

Posted on by Posted in Java

발생되는 경우 static 메소드 안에서 static 으로 선언되지 않은 메소드나 변수를 참조(사용)했을 경우.

특히, 메소드의 경우는 인스턴스를 사용하지 않고 static메소드 내에서 바로 선언한 경우.

조 언 static 선언자의 사용여부를 살펴보고 static 메소드 안에 static으로 선언되어지지 않은 메소드나 변수가 있느지 확인해본다.

만약 그런것이 있으면 메소드를 새로 만들어 그쪽에서 선언한다. 단, 인스턴스를 생성해서 불러줘야 한다는 것을 잊지 말아야한다.

ERROR cannot resolve symbol

Posted on by Posted in Java

symbol : class in(에러가 난 부분)

location : class StackTest(찾으려는 위치)

발생되는 경우 이해할 수 없는 클래스나 메소드, 변수명이 올경우

조 언 보통 이 에러는 철자가 틀렸을 경우에 많이 발생한다. 클래스, 메소드, 변수의 철자를 세심히 확인해 본다.

특히, 철자를 확인할때 대소문자 구분을 확실히 체크한다.(자바는 대소문자를 구별한다.) 그리고 클래스에서 발생할 경우 import를 해주었는지 확인해 봅니다.

우분투 UTF-8 한글 설정하기

Posted on by Posted in 우분투 리눅스 설정

UTF-8 한글로 설정하기 위해서 다음과 같은 명령어를 실행하면 됩니다.

1
$ sudo locale-gen ko_KR.UTF-8

이렇게 명령을 실행하고 확인을 했는데 LANGUAGE 값이 바뀌지 않아서 다음 파일을 수정했습니다. 이부분은 참고만 하세요! 제 경우에만 해당될 수도 있습니다.

1
2
3
$ sudo vi /etc/default/locale
LANG="ko_KR.UTF-8"
LANGUAGE="ko_KR:ko:en_US:en"

그리고 다음 명령으로 설정된 것을 확인하면 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ locale
LANG=ko_KR.UTF-8
LANGUAGE=ko_KR:ko:en_US:en
LC_CTYPE="ko_KR.UTF-8"
LC_NUMERIC="ko_KR.UTF-8"
LC_TIME="ko_KR.UTF-8"
LC_COLLATE="ko_KR.UTF-8"
LC_MONETARY="ko_KR.UTF-8"
LC_MESSAGES="ko_KR.UTF-8"
LC_PAPER="ko_KR.UTF-8"
LC_NAME="ko_KR.UTF-8"
LC_ADDRESS="ko_KR.UTF-8"
LC_TELEPHONE="ko_KR.UTF-8"
LC_MEASUREMENT="ko_KR.UTF-8"
LC_IDENTIFICATION="ko_KR.UTF-8"
LC_ALL=

리눅스 CPU, I/O, Memory 사용량 측정 (씨피유,메모리,입출력) 모니터링

Posted on by Posted in Linux

 

  1. iostat
    1. 별도의 설치 필요없음, 물리적 드라이버 별로 기본적인 Disk Read/Write 볼 수 있음
    2. 한 개 이상의 디스크 드라이브에 대한 입출력 통계와 CPU 활용량
      arg-cpu
      %user
      %nice
      %system
      %iowait
      %steal
      %idle
      마지막 재부팅 이후의 평균 CPU 활용량 어플리케이션 등 사용자 모드에 소모된 시간 nice를 사용하여 스케줄링 우선순위가 바뀐 프로세스에 소모된 시간 시스템(커널)이 사용한 시간 디스크I/O 요청 때문에 CPU가 대기한 시간 다른 가상 CPU가 서비스하는 동안 비자발적으로 대기한 시간 대기한 시간
      Device
      tps
      kB_read/s
      kB_wrtn/s
      kB_read
      kB_wrtn
      디바이스 구분 초당 전송(입출력) 수 초당 읽혀진 KB (Blk일 경우 512바이트 블록수) 초당 쓰여진 KB (Blk일 경우 512바이트 블록수) 지금까지 읽혀진 KB(Blk일 경우 512바이트 블록수) 지금까지 쓰여진 KB(Blk일 경우 512바이트 블록수)
  2. vmstat
    1. 별도의 설치 필요없음, 시스템의 리소스 상황(CPU, I/O, Memory)을 모니터링 할 수 있음 (http://jikime.tistory.com/286)
    2. vmstat(옵션없음) – 마지막 부팅 이후의 평균값
    3. vmstat 2 10 => 2초 간격으로 10회 정보 갱신
      procs memory swap io system cpu
      r b w swpd free buff cache si so bi bo in cs us sy id wa
      현재 실행중인 프로세스의 수(CPU 접근 대기 중인 실행 가능 프로세스 수) 인터럽트가 불가능한 sleep 상태에 있는 프로세스의 수 (I/O 처리를 하는 동안 블럭 처리된 프로세스) 강제로 스왑아웃된 프로세스 사용하고 있는 swap 메모리 양(사용된 가상 메모리 용량) 사용가능한 메모리 양 버퍼로 사용되고 있는 메모리 양 캐시로 사용되고 있는 메모리 양 swap in(디스크에서 메모리로 스왑된 메모리 용량) swap out(디스크로 스왑되어 나간 메모리 용량) 초당 블럭 디바이스로 보내는 블럭 수(블록 장치로 보내진 블록) 초당 블럭 디바이스로부터 받은 블럭 수(블록 장치에서 받아온 블록) 초당 인터럽트 되는 양 초당 context switch되는 양 사용자의 CPU 사용 시간 비율(CPU가 사용자 수준 코드를 실행한 시간, 백분율 단위) 시스템의 CPU 사용 시간 비율(CPU가 시스템 수준 코드를 실행한 시간, 백분율 단위) CPU idle time(백분율 단위) 입출력 대기
  3. top
    1. 별도의 설치 필요없음, CPU 점유 프로세스들을 실시간으로 조회하는 명령어 (http://weezzle.net/1360)
    • 1줄 top : 시스템의 전반적 상태(가동시간 등)
    • 2줄 Tasks : 프로세스들의 상황
    • 3줄 CPU : CPU의 상황
    • 4줄 Mem : 메모리 상황
    • 5줄 Swap : 스왑 메모리 상황
    • 6줄
      PID
      USER
      PR
      NI
      VIRT
      RES
      SHR
      S
      %CPU
      %MEM
      TIME+
      COMMAND
      프로세스 ID 프로세스를 실행시킨 사용자 ID 프로세스의 우선순위 NICE 값 가상 메모리의 사용량(SWAP+RES) 현재 페이지가 상주하고 있는 크기(Resident Size) 분할된 페이지, 프로세스에 의해 사용된 메모리를 나눈 메모리의 총합 프로세스의 상태(Sleeping, Running, sWapped out process, Zombies) 프로세스가 사용하는 CPU의 사용율 프로세스가 사용하는 메모리의 사용율 CPU TIME, hundredths 실행된 명령어
  5. free
    1. 시스템의 실제메모리와 스왑메모리에 대한 사용현황을 확인할 수 있는 명령어 (http://blog.naver.com/PostView.nhn?blogId=jwmoon74&logNo=100174011942)
    • 1줄 Mem : 시스템의 물리적인 메모리에 대한 사용량을 각 필드 단위로 표시
      total
      used
      free
      shared
      buffers
      cached
      전체 메모리의 용량으 Kbyte단위(default)로 표시 현재 시스템에서 사용중인 메모리의 량을 Kbyte 단위로 표시 현재 시스템에서 사용중이지 않은 메모리의 량을 Kbyte단위로 표시 현재 시스템에서 공유한 메모리의 용량을 표시 현재 시스템에서 buffering된 메모리의 량을 표시 현재 시스템에서 caching된 ㅣ메모리의 량을 표시
    • 2줄 -/+ buffers/cache : 현재 캐시 메모리에서 버퍼링된 사용량을 표시(used/free)
    • 3줄 Swap : 서버설치 시에 결정한 스왑메모리의 량, 스왑메모리는 디스크의 일부분을 메모리로 잡아서 설정되기 때문에 스왑메모리가 많이 사용되고 있다는 것은 시스템의 전체적인 속도가 떨어진다는 것을 의미하며 지속적으로 스왑메모리가 사용된다는 것은 결국 실제 메모리를 증설해야 한다는 것이다.
      total
      used
      free
      시스템의 전체 스왑메모리의 량을 표시 전체 스왑메모리 중에서 현재 사용중인 스왑메모리의 량을 표시 전체 스왑메모리중에서 사용되지 않고 남아 있는 메모리의 량
  7. iotop
    1. 별도의 설치 필요함, Python 2.5+, linux kernel 2.6.20+ 이 2개의 프로그램이 기본적으로 설치되어 있어야 함
      TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND

CPU – perf, top, htop

Memory – valgrind, smem

Disk I/O – nmon, bonnie, sysstat

Network – netperf, iftop, netstat

AJAX Cross-Domain 해결방법 (크로스 도메인 문제)

Posted on by Posted in Javascript

Cross-Domain 문제 해결방법에 대한 조사결과

AJAX를 살펴보면서 Cross-Domain 제한의 문제점에 봉착함.

Cross-Domain의 Pattern은 아래 3가지로 나눠볼 수 있음.

1. from one single domain to many targets

2. from many sources to one single target

3. from many sources to many targets.

지금 고민하는것은 2번항목임.

[지금까지 찾은 해결방법]

(1) Proxy Server 이용 : 최초 시도한 방법인데 이건 사실상 위 1번 항목에 해당하는것으로 적당하지 않고 또한 cookie나 session문제등이 있어서 몇번 사용해보다고 취소함.

(2) SignedJavaScript : Netscape계열에서만 되며 JavaScript에 대한 전자서명시 서명된 javascript는 cross-domain 제약을 극복하여 자유롭게 다른 사이트와 통신가능함. MSIE에서는 동작하지 않는다는 문제점이 있고 아직 테스트해보지 못함.

(3) Flash4AJAX : 지금까지 찾은 최상의 방법인데 ActiveX/Plugin을 사용하기는 하지만 광범위하게 배포된 Flash를 이용하여 구현함으로 Cross-Browser문제는 쉽게 극복가능함. 그러나 Flash에 대해서 잘 모르기 때문에 좀더 살펴보고 있음.

(4) JSON + WebServices : 야후 API에서 사용하고 있는데 Target서버에서 JSON Format으로 Output을 뿌려줘야하는 문제 있음. 아직 테스트 못함.

(5) ActiveX : 어떻게 보면 가장 손쉬운 방법인데 일단 하나 만들어 사용중이기는 하지만 Cross-Browser 문제해결에는 적절치 못함.

(6) Windows TrustedZone 등록 : Source Domain상의 유저가 해당 Source Domain을 Windows TrustedZone에 등록해버리면 어디든 나갈 수 있는데 사실 말이 안됨. 보안상 엄청 위험하기도함.

(7) IFrame 이용 : iframe이용하면 일단 AJAX Cross-Domain 문제는 해결되지만 frame간의 cross-domain 문제가 새롭게 대두됨. cross-domain cookie등 Security issue가 꾸준하게 제기되어온 사항임. 일단 target server로 Get Method로 데이터를 넘기기만 하는 형태로는 쓸만함. (결과수신은 아주 어려움)

[ 최종 선택한 방법 : JSON ]

JSON Format으로 결과 전달하고 Callback method로 해당 결과 수신하는 방법이 정답임.

우선 단점 : Request시 GET Method에 해당하는 정보만 전달가능하므로 정보전달 양이 한계가 있음. 그리고 미동기 통신이 안되는 문제점 있음.

그리고 장점 : 대용량 Response를 받을 수 있음. 사실상 브라우저 및 네트웍 성능에 달려 있음. 아무런 ActiveX나 Plugin이 필요치 않음. Cross-Browser 사실상 지원. JavaScript Tag가 먹히는지 여부 실제 확인 필요

(Concept)

1) Client에서 JSon Request URL 생성

2) Javascript createElement tag로 script 객체 생성

3) DOM에 해당 객체 추가하여 실제 반영. 객체추가시 즉각 Remote Server의 CGI/JSP/PHP 호출

4) Remote Server에서는 Request에 따른 업무 처리 후 결과를 callback method로 둘러싼 JSON Format으로 생성하여 화면 송출

5) Browser에서는 결과가 실제로는 script tag 내에 위치하면서 callback method를 호출한것과 동일한 효과발생.

6) callback method내에서 필요한 client측의 업무 처리.

JSON은 AJAX 통신은 아님 사실상 Dynamic Script Creation에 해당되며 script creation시 Remote Server의 script를 불러오는 형태임.

실제 업무에서 JSON과 AJAX를 적절히 섞어 쓸 필요 있음.

자바스크립트의 메모리관리

Posted on by Posted in Javascript

개요

C 언어같은 저급 언어는 메모리 관리를 위해 malloc() 과 free()를 사용한다. 반면, 자바스크립트는 무언가가 생성되었을 때(오브젝트나 문자열 등) 메모리를 할당하고 쓸모 없어졌을 때 ‘자동으로’ free 한다. ‘자동으로’ 라는 말에는 혼란의 여지가 있다. 이는 자바스크립트를 포함한 여러 고급 언어 개발자들에게 메모리 관리가 불가능하다는 인상을 준다. 하지만 실상은 그렇지 않다.

메모리 생존주기

메모리 생존주기는 프로그래밍 언어와 관계없이 비슷하다.

  1. 필요할때 할당한다.
  2. 사용한다. (읽기, 쓰기)
  3. 필요없어지면 해제한다.

첫 번째 부분과 두 번째 부분은 모든 언어에서 분명하게 기술되지만 마지막 부분은 조금 다르다. 저급 언어에서는 분명히 기술되지만 자바스크립트 같은 고급 언어에서는 분명하게 기술되지 않는다(역자: 명시적으로 free를 하지 않는다는 의미).

자바스크립트에서 메모리 할당

값 초기화

자바스크립트에서는 프로그래머들이 일일히 메모리 할당을 하는 수고를 덜어주기위해 값을 선언할 때 메모리를 할당한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
var n = 123; // 정수를 담기 위한 메모리 할당
var s = "azerty"; // 문자열을 담기 위한 메모리 할당
var o = {
  a: 1,
  b: null
}; // 오브젝트와 그 오브젝트에 포함된 값들을 담기 위한 메모리 할당
var a = [1, null, "abra"]; // (오브젝트 처럼) 배열과 배열에 담긴 값들을 위한 메모리 할당
function f(a){
  return a + 2;
} // 함수를 위한 할당(함수는 '호출가능한' 오브젝트이다)
// 함수식 또한 오브젝트를 담기위한 메모리를 할당한다.
someElement.addEventListener('click', function(){
  someElement.style.backgroundColor = 'blue';
}, false);

함수 호출을 통한 할당

몇 가지 함수에서도 메모리 할당이 일어난다.

1
2
var d = new Date();
var e = document.createElement('div'); // DOM 엘리먼트를 위해 메모리를 할당한다.

몇 가지 메쏘드도 새로운 값이나 오브젝트를 담기 위해 메모리 할당이 일어난다.

1
2
3
4
5
6
7
var s = "azerty";
var s2 = s.substr(0, 3); // s2는 새로운 문자열
// 자바스크립트에서 문자열은 immutable 값이기 때문에 메모리를 새로 할당하지 않고 단순히 [0, 3] 이라는 범위만 저장한다.
var a = ["ouais ouais", "nan nan"];
var a2 = ["generation", "nan nan"];
var a3 = a.concat(a2); // 4개의 원소를 가진 새로운 배열

값 사용

값 사용이란 기본적으로는 할당된 메모리를 읽고 쓰는 것을 의미한다. 변수나 오브젝트 속성 값을 읽고 쓸때 값 사용이 일어난다. 또 함수 호출시 함수에 인수를 넘길때도 일어난다.

할당된 메모리가 더 이상 필요없을 때 해제하기

이 단계에서 대부분의 문제가 발생한다. “할당된 메모리가 더 이상 필요없을 때”를 알아내기가 힘들기 때문이다. 이제까지는 개발자들이 메모리가 필요없어질 때를 정하고 free하곤 했다.

고급 언어 인터프리터는 “가비지 콜렉터”라는 소프트웨어를 가지고 있다. 가비지 콜렉터란 메모리 할당을 추적하고 할당된 메모리가 더 이상 필요 없어졌을 때 해제하는 작업을 한다. 이 작업은 근사적인 작업이다. 왜냐하면 일반적인 경우에 어떤 메모리가 필요없는지 알아내는 것은 알고리즘으로 풀 수 없는 비결정적인 문제이기 때문이다. (역자: 세상에 존재하는 모든 가비지 콜렉터는 안전하지만 완전하지 않다. 가비지 콜렉터는 항상 필요없어진 메모리만을 해제하지만 모든 필요없어진 메모리를 해제하는건 아니다)

가비지 콜렉션

위에서 언급한 것처럼 “더 이상 필요없는” 모든 메모리를 찾는건 비결정적이다. 따라서 몇 가지 제한을 두어 “더 이상 필요없는 모든 메모리”가 아니라 “더 이상 필요없는 몇몇 메모리”를 찾아보자. 몇 개의 가비지 콜렉션 알고리즘을 소개하고 한계점을 알아볼 것이다.

참조

가비지 콜렉션 알고리즘의 핵심 개념은 참조이다. A라는 메모리를 통해 (명시적이든 암시적이든) B라는 메모리에 접근할 수 있다면 “B는 A에 참조된다” 라고 한다. 예를 들어 모든 자바스크립트 오브젝트는 prototype 을 암시적으로 참조하고 그 오브젝트의 속성을 명시적으로 참조한다.

앞으로 “오브젝트”라는 어휘의 의미를 넓혀서 기존의 자바스크립트 오브젝트뿐만 아니라 함수 스코프도 포괄하자.

참조-세기(Reference-counting) 가비지 콜렉션

참조-세기 알고리즘은 가장 무난한 알고리즘이다. 이 알고리즘은 “더 이상 필요없는 오브젝트”를 “어떤 다른 오브젝트도 참조하지 않는 오브젝트”라고 정의한다. 어떤 오브젝트를 참조하는 다른 오브젝트가 하나도 없다면 그 오브젝트에 대해 가비지 콜렉션을 수행한다.

예제

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
var o = {
  a: {
    b:2
  }
}; // 2개의 오브젝트가 생성되었다. 하나의 오브젝트는 다른 오브젝트의 속성으로 참조된다.
// 나머지 하나는 'o' 변수에 할당되었다.
// 명백하게 가비지 콜렉션 수행될 메모리는 하나도 없다.
var o2 = o; // 'o2' 변수는 위의 오브젝트를 참조하는 두 번째 변수이다.
o = 1; // 이제 'o2' 변수가 위의 오브젝트를 참조하는 유일한 변수가 되었다.
var oa = o2.a; // 위의 오브젝트의 'a' 속성을 참조했다.
// 이제 'o2.a'는 두 개의 참조를 가진다. 'o2'가 속성으로 참조하고 'oa'라는 변수가 참조한다.
o2 = "yo"; // 이제 맨 처음 'o' 변수가 참조했던 오브젝트를 참조하는 오브젝트는 없다(역자: 참조하는 유일한 변수였던 o2에 다른 값을 대입했다)
// 이제 오브젝트에 가비지 콜렉션이 수행될 수 있을까?
// 아니다. 오브젝트의 'a' 속성이 여전히 'oa' 변수에 의해 참조되므로 메모리를 해제할 수 없다.
oa = null; // 'oa' 변수에 다른 값을 할당했다. 이제 맨 처음 'o' 변수가 참조했던 오브젝트를 참조하는 다른 변수는 없으므로 가비지 콜렉션이 수행된다.

한계: 순환

이 알고리즘은 두 오브젝트가 서로를 참조하면 문제가 발생한다. 두 오브젝트 모두 필요 없어졌더라도 가비지 콜렉션을 수행할 수 없다.

1
2
3
4
5
6
7
8
9
10
11
12
13
function f(){
  var o = {};
  var o2 = {};
  o.a = o2; // o는 o2를 참조한다.
  o2.a = o; // o2는 o를 참조한다.
  return "azerty";
}
f();
// 두 오브젝트가 만들어지고 서로를 참조해서 순환이 일어났다.
// 함수가 종료되고 나면 사실상 두 오브젝트는 의미가 없어지므로 가비지 콜렉션이 수행되어야 한다.
// 그러나 위의 참조-세기 알고리즘에서는 두 오브젝트 모두 참조를 가지고 있기 때문에 둘 다 가비지 콜렉션이 일어나지 않는다.

실제 예제

인터넷 익스플로러 6, 7 은 DOM 오브젝트에 대해 참조-세기 알고리즘으로 가비지 콜렉션을 수행한다. 흔히, 이 두 브라우저에서는 다음과 같은 패턴의 메모리 누수가 발생한다.

1
2
3
4
5
6
var div = document.createElement("div");
div.onclick = function(){
  doSomething();
}; // div 오브젝트는 이벤트 핸들러를 'onclick' 속성을 통해 참조한다.
// 이벤트 핸들러의 스코프에도 div 오브젝트가 있으므로 div 오브젝트에 접근할 수 있다. 따라서 이벤트 핸들러도 div 오브젝트를 참조한다.
// 순환이 발생했고 메모리 누수가 일어난다.

표시하고-쓸기(Mark-and-sweep) 알고리즘

이 알고리즘은 “더 이상 필요없는 오브젝트”를 “닿을 수 없는 오브젝트”로 정의한다.

이 알고리즘은 roots 라는 오브젝트의 집합을 가지고 있다(자바스크립트에서는 전역 변수들을 의미한다). 주기적으로 가비지 콜렉터는 roots로 부터 시작하여 roots가 참조하는 오브젝트들, roots가 참조하는 오브젝트가 참조하는 오브젝트들… 을 닿을 수 있는 오브젝트라고 표시한다. 그리고 닿을 수 있는 오브젝트가 아닌 닿을 수 없는 오브젝트에 대해 가비지 콜렉션을 수행한다.

이 알고리즘은 위에서 설명한 참조-세기 알고리즘보다 효율적이다. 왜냐하면 “참조되지 않는 오브젝트”는 모두 “닿을 수 없는 오브젝트” 이지만 역은 성립하지 않기 때문이다. 위에서 반례인 순환 참조하는 오브젝트들을 설명했다.

2012년 기준으로 모든 최신 브라우저들은 가비지 콜렉션에서 표시하고-쓸기 알고리즘을 사용한다. 지난 몇 년간 연구된 자바스크립트 가비지 콜렉션 알고리즘의 개선들은 모두 이 알고리즘에 대한 것이다. 개선된 알고리즘도 여전히 “더 이상 필요없는 오브젝트”를 “닿을 수 없는 오브젝트”로 정의하고 있다.

순환 참조는 이제 문제가 되지 않는다.

첫 번째 예제에서 함수가 리턴되고 나서 두 오브젝트는 닿을 수 없다. 따라서 가비지 콜렉션이 일어난다.

두 번째 예제에서도 마찬가지다. div 변수와 이벤트 핸들러가 roots로 부터 닿을 수 없어지면 순환 참조가 일어났음에도 불구하고 가비지 콜렉션이 일어난다.

한계: 오브젝트들은 명시적으로 닿을 수 없어져야 한다.

이 한계가 지적되었지만 실제로는 사람들은 이 문제를 비롯한 가비지 콜렉션에 별 관심이 없다.

더 보기

리눅스 용량 확인하기

Posted on by Posted in Linux

df (disk free) : 리눅스에 연결되어 있는 디스크의 남은 공간을 보여준다.
[사용법]
df [Option] [FileSystem | File]

* Option
– k : Kilobyte 단위
-m : Megabyte 단위

[예제]
‘df -k’  : Kilobyte 단위로 현재 마운트된 파티션들의 남은 공간을 보여준다.
‘df -m’ : Megabyte 단위로 현재 마운트된 파티션들의 남은 공간을 보여준다.
‘df .’    : 현재 디렉토리가 포함된 파티션의 남은 공간을 보여준다.

du : 특정 디렉토리에서 하부디렉토리까지 포함한 디스크의 사용량을 보여준다.
[사용법]
du [Option] [Files]

* Option
-a  : 디렉토리에 있는 파일 하나하나의 크기를 출력한다.
-s  : 총 사용량만 표시한다.
-k  : KiloByte 단위로 표시한다.
-h  : 용량을 사람이 보기 가장 좋게 표시한다.

[예제]
‘du -a’ : 현재 디렉토리의 디스크 사용량을 파일단위로 모두 출력한다.
‘du -s *’ : 현재 디렉토리의 첫번째 단계까지만 디스크의 사용량을 출력한다.
              ‘du -h –max-depth=0 *’ 와 동일
‘du -h –max-depth=1 . ‘

–max-depth=1 은 현재 폴더에서 깊이가 1 즉 현재 폴더 내의 파일에 대해서만 용량 표시
. 은 현재 폴더

root 폴더 사용량을 확인한다면…

[명령]
‘du -h –max-depth=0 /root’ or ‘du -sh /root’

[결과]
4.1G root