Jupyter Notebook이란?

Jupyter Notebook은 오픈소스 웹 애플리케이션으로 라이브 코드, 등식, 시각화와 설명을 위한 텍스트 등을 포함한 문서를 만들고 공유하도록 할 수 있습니다.

주로 데이터 클리닝과 변형, 수치 시뮬레이션, 통계 모델링, 머신 러닝 등에 사용할 수 있습니다. 

Jupyter Notebook은 파이썬, R, Scala 등 데이터 과학 분야에서 인기있는 프로그래밍 언어를 지원합니다. 가장 큰 장점은 실시간으로 인터렉티브하게 데이터를 조장하고 시각화할 수 있도록 해준다는 점입니다.



'서버' 카테고리의 다른 글

Jupyter Notebook이란?  (0) 2017.10.18
Ansible이란?  (0) 2017.10.18
WSGI, WAS, CGI 이해  (0) 2017.04.19
호스트 네임  (0) 2017.04.19
[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27

ansible이란?

  • 테스트 환경을 구축하는데 사용되는 툴 Provision & configuration management tool
  • python으로 개발되고 YAML이라는 언어를 통해 정의할 수 있고 json으로 통신
    • python Github project 중 상위 랭킹 (6위)
  • 해커 뉴스 분석을 보면 ansible이 많이 Mention 되어지고 있음
  • 오픈 소스 버전 (GPL)

ansible 장점 및 지원

  • 빠른 SSH통신, 빠른 provision이 가능
  • 추후 상용 환경에서 사용할 때 agent 기반이면 방화벽 이슈, agent 데몬 관리라는 불편한 점이 존재 (agent 방식은 확장성, 대규모 provision을 할 경우 매우 효과적이지만 서버와 통신하는 부분이 고도화되기 때문에 빠르고 간단한 provision을 할 수 없음)
  • 자동 배포 환경이 쉬움
  • 개발 가능성이 높은 오픈소스
  • 대부분이 멱등성을 제공
  • playbook
  • ad-hoc 지원.
  • 병렬 provisioning 지원.
  • vagrant
  • jinja2

멱등성(Idempotency)

  • 여러 번 적용해도 결과는 바뀌지 않음
  • 바뀌는 것이 없으면 당연히 배포되어도 바뀌지 않음
  • 바뀌는 부분이 있으면 그 부분만 반영
  • shell, command, file module은 보장 안됨

Ansible에서의 멱등성이란?

여러 번 ansible 툴을 사용하더라도 동일한 결과 값을 나올 수 있도록 제공되는 형태여야 합니다. 매번 다른 결과가 나오거나 에러가 나온다면 비 멱등성하다고 할수 있습니다. ansible 툴의 거의 대부분의 모듈은 멱등성을 제공합니다. 또한 멱등성을 제공하기 위해서 조건절을 제공하고 있습니다. 예를 들면, 처음 ansible 스크립트를 실행 후 다시 실행을 하면 상황에 따라서는 파일이 append가 될 수 있습니다. 그러나 멱등성의 원칙은 언제나 실행은 해도 결과가 동일하게 나옵니다. 또한 파일/디렉터리를 생성 또는 삭제하는 ‘create’ , ‘remove:’ 같은 ansible 모듈을 실행 할 때 ‘when;’ 조건절을 이용할수 있습니다. 대부분의 ansible 모듈이 멱등성을 보장한다는 의미는 상태를 파악할 수 있다는 의미를 가지게 됩니다.


ansible의 기본개념

ansible의 환경설정, 배포를 가능케 하는 언어입니다. 리모트 서버에 접속해서 무언가를 시행시키는 정책을 기술합니다. yaml 문법으로 정책이 기술되어 있으며 좀 더 고급 단계에서는 로드밸런서를 모니터링하는 복잡한 환경에서 사용할 수 있도록 합니다. 각 playbook은 하나 또는 하나 이상의 ‘play’를 두게 됩니다. Play의 목적은 여러 호스트들에 잘 정의된 ‘role’과 ‘task’를 매핑하는 역할을 합니다. Task는 ansible 모듈의 호출을 의미합니다. Role을 좀 더 편하게 관리하기 위해서 미리 정의된 yaml 파일을 include을 하는 것이 가능 합니다. 또한 host inventory 파일에 정의한 서버 그룹별로 각각 나누어 provision 할 수 있도록 할 수 있습니다. 서버당 디렉터리를 나누어서 각각의 설정 정보가 정의된 파일을 읽어 설치하게 합니다.

playbook

플레이북은 애드혹 테스트 실행 모드와는 완벽하게 다른 사용방법이며 특히 강력한 사용 방법입니다. 간단히 말해 플레이북은 정말 간단하게 설정을 관리하고 다수의 머신에 대한 배포 시스템에 대한 기본적인 단위입니다. 기존에 존재해왔던 것과 달리 복잡한 어플리케이션 형태의 배포에 매우 적합합니다. 플레이북은 설정을 정의할 수 있으며 특정 머신의 집합을 오가며 다른 작업을 수행하도록 수동으로 작업 순서를 설정하는것도 가능합니다. 이때에 작업은 동기 또는 비동기로 수행할 수 있습니다. /usr/bin/ansible 명령을 통한 애드혹 테스크를 실행하는 것에 반해 플레이북은 소스 컨트롤을 통해 보관하거나 사용자의 설정을 내보내거나 원격 시스템을 구성, 보장되는데 더욱 적합합니다. 플레이북을 통해 이러한 기술들을 구현하는 방법은 [Ansible-Example 저장소]에 정리가 되어있습니다.

ad-hoc

Adhoc 이라는 의미는 임시적으로 수행하는 의미. ansible의 playbook을 작성하여 수행하는 것이 아니라 임시적으로나 또는 특별하게 어떤 작업을 수행하기 위해서 사용할 수 있는 실행방법이라고 할 수 있음. 

Inverntory

리모트 서버에 대한 meta 데이터를 기술하는 파일입니다. Ansible에서는 inventory 파일에는 yaml을 적용하지 않았습니다. 기본 파일은 /etc/ansible/hosts를 읽게 하거나, 따로 inventory 파일을 만들고 옵션을 주어 동작하게 할수 있습니다. 만약 고정 ip를 가지고 있고 gosts 파일 안에 들어가 있지 않는 서버가 있다면 설정 파일을 만들수 있고 테스트 환경을 만들때 유용합니다.

Ansible의 한계

  • 시스템의 초기 설치 수행은 불가능 (kickstart, pxe 등을 사용하여야 함)
  • 시스템 모니터링은 지원하지 않음
  • 시스템 변경사항은 추적하지 않음


'서버' 카테고리의 다른 글

Jupyter Notebook이란?  (0) 2017.10.18
Ansible이란?  (0) 2017.10.18
WSGI, WAS, CGI 이해  (0) 2017.04.19
호스트 네임  (0) 2017.04.19
[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27

개요

각 언어마다 WAS와 같이 서버 언어를 처리하도록 하는 동작이 각기 상이합니다. 아래는 하나씩 설명하며 각각 비교를 설명합니다.

웹 서버

인터넷을 통해서 요청된 웹 컨텐츠(이미지, html, 등)의 전달을 도와주는 하드웨어와 소프트웨어를 말합니다. 웹서버는 기본적으로 '정적'입니다. 클라이언트가 HTTP 리퀘스트를 통해 리소스를 요청하면, 그 리소스를 그대로 보내주는게 웹 서버의 역할입니다.

CGI(Common Gateway Interface)

웹 서버에서 어플리케이션을 작동시키기 위한 인터페이스입니다. 정적인 웹서버를 동적으로 기능하게 하기 위해서 등장하였습니다. 서버 프로그램과 외부 프로그램 간의 인터페이스가 바로 CGI입니다. 근래에는 웹 서버의 프로세스로서 인터프리터를 상주시킴으로써, CGI로부터 프로그램을 호출해 부하를 줄임으로써 성능을 개선한 Java Servlet나 mod perl, mod php, FastCGI 등도 공개되었습니다. 기존에는, 웹서버가 있고 클라이언트에서 외부 프로그램이 필요한 리퀘스트가 들어오면 CGI를 통해 외부 프로그램을 실행시켜 리퀘스트에 응답하도록 했지만 요즘에는 웹서버에 인터프리터를 내장함으로써 따로 프로세스를 fork하여 외부 프로그램을 실행시키지 않고 내부에서 다 처리합니다.

방식

요청 ->  웹서버(아파치, nginx 등) -> (웹서버가 직접실행프로그램(Perl, C/C++ 등)

웹서버와 프로그램 사이의 정보를 주고받는 규칙을 의미하고  CGI 프로그래밍이란, Perl, C/C++ 등을 사용하여 웹서버가 실행할 수 있는 프로그램을 작성하는 것을 의미합니다.

WAS(Web Application Server)

WAS는 웹서버가 동적으로 기능하면 WAS입니다. 즉, Web Server + CGI가 WAS입니다. 우리가 하는 소규모 프로젝트에서는 일반적으로 웹서버와 WAS를 굳이 구분할 필요가 없으며, 후에 필요에 따라 서버를 분리할 때 이를 구분하긴 하는데 이때도 사실 용어가 중요한지는 의문이 들긴 합니다. 간단하게 말해 웹서버 위에 서버 어플리케이션을 얹은 것이 WAS입니다.

방식

요청 -> 웹서버) -> 웹 어플리케이션 서버(톰캣, JBoss 등) -> (웹어플리케이션 서버가 실행)프로그램

어플리케이션 서버가 프로그램의 실행결과를 웹 서버에 전달해주며 웹 서버는 전달 받은 결과를 웹 브라우저에 전송합니다. (JSP, ASP.net 등)

※CGI, 어플리케이션 서버 방식의 차이

접속자가 많은 서비스의 경우 CGI 방식보다 어플리케이션 서버 방식의 Throughput(처리량)이 더 좋습니다.

예를들어, 5개의 웹 브라우저가 동일한 프로그램을 요청했을 때 CGI 방식은 5개의 요청에 대한 프로그램을 모두 메모리에 적재합니다. 반면, 어플리케이션 서버방식은 메모리에 한번만 적재합니다. 이로써 CGI방식에 비해 전체적인 메모리 사용량이 적습니다. 이는 더 많은 요청을 처리할 수 있음을 의미합니다.

WSGI(Web Server Gateway Interface)

파이썬에서 어플리케이션, 즉 파이썬 스크립트(웹 어플리케이션)가 웹 서버와 통신하기 위한 인터페이스입니다. 프로토콜 개념으로 이해할 수도 있습니다. WSGI는 서버와 앱 양단으로 나뉘어져 있습니다. WSGI 리퀘스트를 처리하려면 서버에서 환경정보와 콜백함수를 앱에 제공해야 합니다. 앱은 그 요청을 처리하고 콜백함수를 통해 서버에 응답합니다.

방식

요청 -> 웹서버 -> WSGI Server(middleware라고도 함) -> WSGI를 지원하는 웹어플리케이션(Django, flask 등) 

WSGI Server(middleware)

웹 서버와WSGI를 지원하는 웹어플리케이션 사이에서 동작하며, 아래와 같은 일을 합니다.

  • 환경변수가 바뀌면 타겟 URL에 따라서 리퀘스트의 경로를 지정해줌
  • 같은 프로세스에서 여러 애플리케이션과 프레임워크가 실행됨
  • XSLT 스타일시트를 적용하는 것과 같이 전처리함

WSGI Server(middleware)는 mod_wsgi, uwsgi, gunicorn, twisted.web, tornado 등이 있습니다.

WSGI, CGI 방식의 차이

아파치는 80번 포트를 듣고 있다가, 리퀘스트가 들어오면 이를 해석해서 응답합니다. 응답의 방법은 다양한데, 그중 하나는 CGI를 통해 스크립트를 실행시키는 것이고 다른 하나는 단순히 파일을 제공하는 것입니다. CGI의 경우, 아파치는 환경을 준비하고 CGI 프로토콜에 따라 스크립트를 실행시킵니다. CGI 서브프로세스는 소켓과 stdout을 포함하여 OS 환경을 상속합니다. CGI 서브프로세스가 response를 작성하고, 이를 아파치로 보내면, 아파치는 이 response를 브라우저로 보냅니다. CGI는 원시적이라고 볼 수 있습니다. 대부분 CGI는 모든 리퀘스트마다 서브프로세스를 fork합니다.

반면 WSGI는 CGI 디자인 패턴에 기반한 인터페이스입니다. 하지만 WSGI가 항상 CGI는 아닙니다. WSGI는 모든 리퀘스트에 대해 서브프로세스를 다 fork하지 않습니다. WSGI는 CGI가 될수도 있고 아닐수도 있습니다. WSGI는 CGI 디자인 패턴을 몇가지 중요한 방식으로 더했습니다. HTTP Request Header를 파싱하고 이를 환경에 추가합니다. 이것은 환경에서 file-like object로써 POST-oriented input을 제공합니다. 또한 사용자에게 수 많은 format 디테일로부터 해방시키고 response를 만들 수 있는 기능을 제공합니다.

다시말해, WSGI가 CGI 디자인 패턴을 가져다 업그레이드 한 모델입니다. CGI는 모든 리퀘스트마다 fork를 통해 서브프로세스를 띄워 요청을 처리하므로 느리지만 WSGI는 그렇지 않으므로 좋습니다.

WSGI, FCGI

WSGI는 파이썬에 종속된 개념이고, FCGI는 언어와 상관없는 socket wire 프로토콜입니다. WSGI가 더 높은 레이어에서 동작하며, 따라서 WSGI-FCGI를 동시에 사용할 수 도 있습니다.

'서버' 카테고리의 다른 글

Jupyter Notebook이란?  (0) 2017.10.18
Ansible이란?  (0) 2017.10.18
WSGI, WAS, CGI 이해  (0) 2017.04.19
호스트 네임  (0) 2017.04.19
[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27

호스트 네임은 컴퓨터의 이름이고 도메인 네임은 컴퓨터 그룹의 이름입니다. 예를 들면 호스트 네임은 사람의 이름으로, 도메인 네임은 사람의 성으로 이해하면 됩니다. [홍길동]과 [홍기산]은 같은 '홍'씨 족의 사람들이지만 '길동'과 '기산'이라는 이름으로 구분됩니다. [장길산]과 [김길산]은 같은 '길산'이라는 이름을 사용하지만 '장'과 '김' 이라는 다른 성을 사용함으로써 구분됩니다.

여기서 '홍', '장', '김' 과 같은 성을 도메인 네임으로, '길동', '기산', '길산' 과 같은 이름을 호스트 네임으로 이해하면 됩니다.

tom 과 tom.sunjin2.net과 sunjin2.net 에서 tom 은 호스트 네임이 되며, sunjin2.net 은 도메인 네임이 됩니다. kin.naver.com 과 mail.naver.com 과 cafe.naver.com 에서 kin, mail, cafe 등은 호스트 네임이며 naver.com 은 도메인 네임이 됩니다.

추가적으로 호스트 네임과 도메인 네임을 합쳐서 사용할 경우 FQDN (fully qualified domain name) 이라는 시스템을 지칭하는 완전한 이름이 됩니다. tom.sunjin2.net, kin.naver.com, mail.naver.com, cafe.naver.com 등이 FQDN 입니다.

이와 같이 사용하는 이유는 내부 네트워크를 구분하기 위한 것이라기 보다는 각 서버 또는 서비스의 영역을 구분하기 위한 것이라고 보는게 좀 더 정확할 것 같습니다.

예를 들어, sunjin2.net 이라는 도메인을 신청하여 www.sunjin2.net 으로 웹서버를 구축하여 서비스 하던 중 mail 서버를 신설하기로 했다면 기존에 구축되어진 웹서버나 별도의 새로운 서버에 mail.sunjin2.net 을 추가로 설정하여 mail 서비스를 할 수 있기 때문입니다.

리눅스 쉘 프롬프트에서 hostname 명령을 입력하면 현재 설정된 호스트 네임을 확인할 수 있습니다. 또한 domainname 명령을 입력하면 현재 설정된 도메인 네임을 확인 수 있습니다. 별도의 설정을 하지 않았다면 domainname 은 (none) 으로 보입니다.

'서버' 카테고리의 다른 글

Ansible이란?  (0) 2017.10.18
WSGI, WAS, CGI 이해  (0) 2017.04.19
호스트 네임  (0) 2017.04.19
[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27
WSGI  (0) 2017.03.24

넷스케이프사가 개발한 인터넷 상에서 정보를 암호화하여 송수신하는 프로토콜입니다. WWW나 FTP등의 데이터를 암호화하여 프라이버시에 관한 정보나 크레딧카드 번호, 기업 비밀등을 안전하게 송수신할 수 있습니다.



SSL은 공개키 암호나 비밀키암호, 디지털 증명서, 해쉬함수등의 시큐리티 기술을 조합하여 데이터의 도청이나 변경, 위장을 방지할 수가 있습니다. OSI 모델에서는 세션(5계층)과 트랜스포트(4계층)의 사이에서 동작하여 상위 프로토콜을 이용하는 어플리케이션에서는 특별히 의식할 필요없이 투과적으로 이용할 수 있습니다.

'서버' 카테고리의 다른 글

WSGI, WAS, CGI 이해  (0) 2017.04.19
호스트 네임  (0) 2017.04.19
[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27
WSGI  (0) 2017.03.24
[Linux] 메모리 할당 크기 확인하기  (0) 2017.03.15

SSH는 안전한 원격 통신을 위해 사용됩니다. SSH가 사용되기 이전에는 텔넷(Telnet)이 사용되었습니다. 텔넷 통신에는 기본적으로 23번 포트가 사용되는데 통신에서 데이터를 암호화하는 과정이 없기 때문에 같은 네트워크 상의 누군가가 통신을 가로챈다면 내용을 모두 엿볼 수 있다는 문제가 존재했습니다. 이러한 보안 상의 문제로 SSH가 설계, 개발된 것 입니다. SSH는 암호화 기법을 사용하기 때문에 누군가 통신을 가로챈다고 하더라도 암호화된 텍스트로 보이게 됩니다. 기본적으로 22번 포트가 사용되며 주로 리눅스, 유닉스 시스템에서 사용됩니다.

'서버' 카테고리의 다른 글

호스트 네임  (0) 2017.04.19
[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27
WSGI  (0) 2017.03.24
[Linux] 메모리 할당 크기 확인하기  (0) 2017.03.15
[Linux] CPU 개수 확인하기  (0) 2017.03.15

웹 서버 게이트웨이 인터페이스(WSGI, Web Server Gateway Interface)는 웹서버와 웹 애플리케이션의 인터페이스를 위한 파이썬 프레임워크입니다.

기존의 파이썬 웹 애플리케이션 프레임워크는 웹서버를 선택하는데 있어서 제약이 있었습니다. 보통 CGI, FastCGI, mod_python과 같은 커스텀API 중에 하나만 사용할 수 있도록 디자인 되었는데, WSGI는 그에 반하여 low-level로 만들어져서 웹서버와 웹 애플리케이션,프레임워크간의 벽을 허물었습니다. WSGI는 서버와 게이트웨이 , 애플리케이션과 프레임워크 양단으로 나눠져있습니다. WSGI 리퀘스트를 처리하려면, 서버단에서 환경정보와 콜백함수를 애플리케이션단에 제공해야합니다. 애플리케이션은 그 요청을 처리하고 미리 제공된 콜백함수를 통해 서버단에 응답합니다. WSGI 미들웨어가 WSGI 서버와 애플리케이션 사이를 보충해주는데, 이 미들웨어는 서버의 관점에서는 애플리케이션으로, 애플리케이션의 관점에서는 서버로 행동합니다.

'서버' 카테고리의 다른 글

[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27
WSGI  (0) 2017.03.24
[Linux] 메모리 할당 크기 확인하기  (0) 2017.03.15
[Linux] CPU 개수 확인하기  (0) 2017.03.15
[Linux] 용량 확인 명령어  (0) 2017.03.15
$ cat /proc/meminfo | grep MemTotal
MemTotal:        4046944 kB
 
# 또는
 
$ sudo dmidecode | grep 'Size.*MB'
	Size: 4096 MB


'서버' 카테고리의 다른 글

[Linux] SSH (Secure Shell)  (0) 2017.03.27
WSGI  (0) 2017.03.24
[Linux] 메모리 할당 크기 확인하기  (0) 2017.03.15
[Linux] CPU 개수 확인하기  (0) 2017.03.15
[Linux] 용량 확인 명령어  (0) 2017.03.15
[Linux] 커맨드라인 특수문자 명령어  (0) 2017.03.14

일반적인 경우, 하이퍼스레딩에 의해 OS(윈도우, 리눅스 등)에서 코어 수가 실제 코어 수의 2배로 인식됨.

예를 들어 싱글코어는 코어 2개로, 듀얼코어는 4개로 인식

CPU 코어 전체 개수

# grep -c processor /proc/cpuinfo
# 또는
# ll -d /sys/devices/system/cpu/cpu? | wc -l

$ grep -c processor /proc/cpuinfo
48

가상 CPU 코어 수는 48. 1 core(물리코어)당 2 thread(가상코어)이므로 따라서 물리적으로는 24 코어

물리 CPU 수

# grep ^processor /proc/cpuinfo | wc -l


 dmidecode -t processor | grep 'Socket Designation'
	Socket Designation: CPU 0
	Socket Designation: CPU 1

CPU당 물리 코어 수

# grep 'cpu cores' /proc/cpuinfo | tail -1


$ grep 'cpu cores' /proc/cpuinfo | tail -1 
cpu cores : 6

→ CPU당 물리 코어수가 6.


위에서 확인한 사항들을 모아보면 다음과 같음.

물리 CPU 수: 4

물리 CPU당 물리 코어 수: 6

전체 물리코어수 : 24 (=4CPU * 6코어)

 전체 가상코어수 : 48 (=4CPU * 6코어 * 2쓰레드)

'서버' 카테고리의 다른 글

WSGI  (0) 2017.03.24
[Linux] 메모리 할당 크기 확인하기  (0) 2017.03.15
[Linux] CPU 개수 확인하기  (0) 2017.03.15
[Linux] 용량 확인 명령어  (0) 2017.03.15
[Linux] 커맨드라인 특수문자 명령어  (0) 2017.03.14
[Linux] pushd, popd  (0) 2017.03.14

df  - 하드디스크 용량 확인

$ df
Filesystem                  1K-blocks    Used Available Use% Mounted on
...
/dev/sda1                      240972   39176    189355  18% /boot
...


옵션에 h를 주면 보기 더 편합니다.

$ df -h
Filesystem                   Size  Used Avail Use% Mounted on
...
/dev/sda1                    236M   39M  185M  18% /boot
...

du - 디렉토리 용량 확인

$ cd /var/log
$ du
243132	./httpd
23204	./sa
4	./cups
4	./sssd
4	./ntpstats
16	./tweet_bot
8	./mail
4	./varnish
8	./ConsoleKit
24740	./audit
4	./samba/old
8	./samba
32	./prelink
308512	.


해당폴더 용량 확인

# du -hs 폴더
 
$ du -hs test/
512K	test/


현재 폴더에 있는 폴더 및 파일 용량 확인 

# du -hs *
 
$ cd test/
$ du -hs *
4.0K	test.py
4.0K	test1.py
4.0K	test2.py
4.0K	test3.py
4.0K	test4.py
4.0K	test5.py


현재폴더에 있는 폴더 및 파일 중에서 용량이 큰 것 순으로 10개 보기

  • hs 옵션을 주면 sort가 제대로 되지 않음. 예를 들어 2.3G보다 12M를 큰 것으로 인식하기 때문에 -hs 옵션을 빼야함
# du * | sort -n | tail -10


/ (최상위 폴더)의 자식 폴더 용량 보기

$ du -hs /* 2> /dev/null
 
7.5M	/bin
23M	/boot
272K	/dev
34M	/etc
988K	/home
130M	/lib
25M	/lib64
16K	/lost+found
4.0K	/media
8.0K	/mnt
8.0K	/opt
0	/proc
1.2M	/root
14M	/sbin
0	/selinux
4.0K	/srv
0	/sys
248K	/tmp
1.9G	/usr
128M	/var


'서버' 카테고리의 다른 글

[Linux] 메모리 할당 크기 확인하기  (0) 2017.03.15
[Linux] CPU 개수 확인하기  (0) 2017.03.15
[Linux] 용량 확인 명령어  (0) 2017.03.15
[Linux] 커맨드라인 특수문자 명령어  (0) 2017.03.14
[Linux] pushd, popd  (0) 2017.03.14
[Linux] Confluence WiKi 설치  (0) 2017.03.14

+ Recent posts