반응형

Host OS: Ubuntu 14.04.1 LTS (amd64)

Guest OS: Windows 10 (64-bit)


연구실 PC가 메모리가 넉넉한 편이라서(16GB) 가상 머신으로 윈도우를 시험삼아 돌려 보고 있는데, 이상하게 오랜만에 가상머신에 원격으로 접속하면 (원격 데스크탑 RDP 사용) 바탕화면이 뜨는데 상당히 오랜 시간이 걸린다. 정확히 재지 않았지만, 1분은 확실히 넘는 것 같다.


가상머신 구성은 다음과 같다:

  • 가상 머신 관리는 QEMU KVM을 사용
  • 윈도우 가상 머신에 CPU 2 Cores (물리적으로 2개, 쓰레드 기준으로 4개), 6GB 메모리, 180GB의 하드디스크를 할당
  • 평소에 항상 PC를 켜 두고, 리눅스를 주로 사용하다가 몇 시간에 한 번씩 윈도우 가상 머신에 RDP로 연결(리미너 원격 클라이언트 또는 FreeRDP 사용)

보통 맨 처음 가상 머신을 부팅시키고 나면 직접 Virtual Machine Manager 어플리케이션에서 확인하든 RDP로 원격접속하든 상관 없이 바로 바탕화면이 나오는데, 윈도우에서의 작업을 마치고 원격 접속 연결만 해제한 채 (즉, 켜진 상태로) 오랜 시간을 쓰지 않으면, 나중에 다시 접속할 때 위와 같이 상당히 오랜 시간이 걸린다. 그리고 그 때 PC의 물리적인 상태를 보면 HDD 램프가 빠르게 깜빡거리면서 하드디스크에 지속적으로 열심히 접근하고 있다.


확인해본 결과, 우분투는 기본적으로 물리적인 메모리에 상주하는 어플리케이션을 가급적이면 스왑 영역(가상 메모리 영역; 즉 하드디스크)에 옮겨 두려는 경향이 크다는 것을 알게 되었다. 그리고 그 경향을 조절하는 설정 변수가 Swappiness이다. 0부터 100 사이의 값 중에서 기본값이 60으로 되어 있다. 60이라는 숫자가 정량적으로 얼마만큼의 메모리 영역을 스왑 영역으로 보내는지는 확실하지 않지만, 경향성이 매우 높은 편에 속한다는 사실에는 이견이 없어 보인다.


인터넷에서 대부분의 우분투 사용자들이 개인 PC에서 우분투를 쓸 때 성능을 개선하기 위해서 가장 먼저 swappiness부터 조정한다는 것 또한 알 수 있었다. 설정 방법은 /etc/sysctl.conf 파일에 아래와 같이 한 줄을 추가하거나, 이미 있으면 숫자를 아래와 같이 조정한다:

vm.swappiness=10


인터넷에서는 보통 swappiness 값을 10 으로 권장하는 분위기이다. 실제로 나도 swappiness 값을 조정하고 나서 윈도우 가상 머신의 원격 데스크탑 접속 로딩 시간이 꽤 단축되는 것을 체감할 수 있었다. 하지만 여전히 몇 시간 후에 다시 접속하면 약 30초 가량의 딜레이가 발생하였다. 그래서 아예 vm.swappiness 값을 3으로 더욱 낮게 설정했더니, 그제서야 길어도 10초 이내로 바로 원격 데스크탑 화면이 나타났다.


개인적인 경험으로 볼 때, 물리적 메모리가 16GB이고 가상 머신을 한 개만 운용하고 있으며, 이외에 메모리를 많이 소비하는 다른 프로그램을 쓰지 않기 때문에 swappiness 값을 매우 낮게 줘도 앞으로 쓰는 데는 문제가 없을 것 같다.


하지만 근본적으로는 서버에서 가상 머신을 돌리는 것이 속도를 개선하는 가장 확실한 방법인 것 같다. 실제로 연구실에서 운용하는 24코어에 64GB 메모리, 5TB의 하드디스크를 갖고 있는 서버에서 동일한 스펙의 가상 머신을 돌리는 것이 개인 PC에서 돌릴 때에 비해 속도가 월등하게 빨랐다. 즉, 그래픽 측면의 이질감과 불편함(폰트 같은 것이 깔끔하게 표시되지 못하고, 게임을 실행하지 못하는 문제)만 감수할 수 있다면, 서버에서 가상 머신을 돌리는 것(결국 클라우드 환경)이 좋을 수밖에 없다.


아직 연구실에 오픈스택(OpenStack)을 적용하지는 못했는데 (당장 이 쪽으로 연구실 구성원 중에 연구주제가 있는 것은 아니고, 운영상의 목적만 있음), 서버 여러 대와 몇몇 잉여 데스크탑 본제들을 조합해서 클라우드 환경을 만들어서 돌려보고 싶다. 일단은 졸업이 급하니 졸업하고 나서 해 봐야겠다. ㅜㅜ


반응형
블로그 이미지

Bryan_

,
반응형

Device: Buffalo WZR-600DHP

OS: OpenWRT 14.07 Barrier Breaker

IPTraf version: 3.0.1


OpenWRT에서 iptraf 실행 시, 콘솔 창에 아래와 같이 메세지가 뜨면서 엔터 키를 입력받아야 진입되는 경우가 있다.

Warning: unable to tag this process


IPTraf는 여러 개의 인스턴스 실행을 방지하기 위해서 자체적으로 태그를 사용하는데, 그 태그 파일을 저장할 위치가 없어서 생기는 문제이다아래와 같이 디렉토리를 만들어 주면 해결된다 [1].


# mkdir -p /var/run/iptraf


OpenWRT는 어차피 /var 디렉토리가 /tmp로 잡히기 때문에, /tmp/run/iptraf 폴더가 생성될 것이다.

/tmp/run/ 에 직접 만들어도 상관 없다.



<참고자료>

[1] https://lists.openwrt.org/pipermail/openwrt-tickets/2012-June/046623.html



반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 14.04 LTS


우분투 부팅 시 "waiting for network configuration"이라는 글자가 떠서 한동안 기다리는 경우가 있다.

ESC로 취소가 안되고, 1분 이상 걸리는 듯 하다.


이런 경우는 대체로 /etc/network/interfaces 파일에 있는 설정이 실제 하드웨어와 맞지 않거나, 설정이 잘못 입력되어 있어서 발생한다. 필자의 경우에는 우분투 데스크탑에 있는 네트워크 관리자(network-manager)를 쓰지 않고 직접 /etc/network/interfaces 파일을 설정하다 보니 생기는 문제였다.


실제 하드웨어와 맞지 않는다는 것의 의미는, USB 무선랜카드에 대한 설정을 interfaces 파일에 기록해 두었는데, 재부팅하는 순간에 그 USB 무선랜카드를 빼 놓아서 interfaces 파일에 입력된 인터페이스 이름(예: wlan0)을 찾을 수 없는 경우이다.

이 경우, USB 무선랜카드를 연결시킨 다음에 부팅하거나, 부팅하는 당시에 /etc/network/interfaces 파일에서 무선랜 관련 설정이 미리 주석처리 되어 있어야 한다.


그 외에는 링크(http://askubuntu.com/questions/213614/waiting-for-network-configuration-problem)에 의하면, 같은 물리적 인터페이스에 여러 IP를 할당하는 경우(eth:0 과 같이 설정)에 게이트웨이를 두 번 명시하는 경우에도 발생한다고 한다.



반응형
블로그 이미지

Bryan_

,
반응형

일반적으로 VI 설정은 사용자 디렉토리에 있는 .vimrc 파일에 적힌 대로 따라가는데, 루트 계정으로 vi를 실행하면 그 설정이 모두 없이 기본 VI로 로드되는 경우가 있다.


다 그런 것 같지는 않은데, 예를 들어 우분투는 $ sudo vi 로 실행하더라도 사용자 설정을 따라가는 듯 하다. 반면에 라즈베리파이에 설치한 Raspbian에서는 $ vi 와 $ sudo vi 의 설정이 서로 다르다.


Raspbian의 경우, (아마 다른 배포판도 마찬가지일 듯) /root/ 디렉토리에 사용자 디렉토리에 있는 .vimrc 파일을 복사하는 것으로 간단하게 해결된다.

반응형
블로그 이미지

Bryan_

,
반응형

PC 환경: 가상머신 (Ubuntu 14.04에 KVM으로 생성: 쿼드코어, 6GB 램, 180GB 하드디스크)

운영체제: 윈도우10 (Microsoft Windows 10, 64-bit)

브라우저: 인터넷 익스플로러 11 (Internet Explorer 11)


처음에는 위에 설명된 가상 머신에서 윈도우 8.1을 썼었고, 그 때 우리은행 사이트는 아무 문제없이 잘 작동하였다. 윈도우10으로 업그레이드한 이후에도 잘 작동하는 듯 했으나, 최근에 우리은행에서 보안 프로그램을 하나 더 추가한 것 같았고, 이후로는 자꾸만 아래와 같이 플러그인을 설치하라는 메세지가 뜬다.



일단 보안 프로그램을 설치하기 위해 설치 페이지로 이동한 결과, realip라는 보안로그 수집 프로그램을 설치해야 된다고 나왔다. 아래 그림에는 재설치로 나와 있지만, 맨 처음에는 미설치 상태였다.




문제는, 시키는 대로 설치를 하고 나서 웹사이트가 시키는 대로 인터넷 익스플로러 브라우저를 재시작하고 나서 다시 로그인 페이지에 갔더니, 또다시 설치 페이지로 이동하라는 메세지가 뜨는 것이었다. 이번에는 또 무슨 문제가 있는지 가 봤더니,아래 화면과 같은 어이없는 상태를 보여주었다.





보안 프로그램을 제대로 설치했고, "설치됨"으로 나오는데도 설치가 필요하다면서 설치 페이지로 이동하라는 것은 무슨 의미일까?

아무튼 설치 페이지로 이동하라는 안내를 무시하고 로그인을 했더니 다행히 로그인은 할 수 있었다. 그러나, 키보드 입력을 통해서는 올바른 공인인증서 암호를 입력했음에도 불구하고 비밀번호 입력 오류가 나와서, 결국 우리은행 사이트에 있는 화상 키보드를 써서 불편하게 일일이 클릭해야만 했다.

분명히 윈도우 8.1을 쓸 때에는 이런 문제가 없었는데, 최근에 플러그인 내부 로직이 바뀌어서 그런 건지 윈도우 10 때문인지는 알 수 없다.


로그인하고 나서 계좌 거래내역 조회를 할 때에도, 계좌이체를 할 때에도 플러그인 설치 페이지로 가라는 성가신 안내 메세지는 계속 나타났다.




제일 좋은 것은 이렇게 덕지덕지 붙이는 듯이 보이는 보안 프로그램 없이 인터넷 뱅킹을 하는 것이지만, 그렇게 되려면 국가가 나서서 공인인증서를 비롯한 제도적인 개선을 해야 하므로 시간이 많이 걸릴 것 같다. 현재로써는 불편을 감수하고 쓰는 수밖에 없는데, 그나마 설치되는 플러그인도 위와 같이 제대로 인식도 안돼서 몇 번씩이나 재설치하게 만들고, 결국 버그라는 것이 밝혀져서 한동안 불편하게 설치 페이지로 이동하라는 메세지를 일일이 꺼야 한다. 


아마 윈도우10 운영체제를 완벽하게 지원하지 못해서일 수도 있고, 게다가 가상머신까지 쓰고 있어서 어딘가 예상치 못한 문제가 발생하는지도 모르겠다. 하지만 그렇다고 해서 우리은행 측에서 공식적으로 윈도우10을 쓰지 말라는 권고를 한다면 진심으로 "무책임하고 실력없다"고 비난받아도 마땅하다. 기본적으로 존재 자체가 불편한 보안 플러그인이고, 실제로 사용자 PC 입장에서는 평소에 메모리와 CPU 사용량만 잡아먹는 암덩어리 같은 존재인데, 이렇게 제대로 작동하지 못해서 추가적인 불편을 초래하지는 말아야 한다. 하루빨리 고쳐지길 바랄 뿐이다.



반응형
블로그 이미지

Bryan_

,