카테고리 보관물: info

Leopold FC660C Bluetooth (BLE660C) Connection Settings

블루투스 페어링

Bluetooth가 연결되지 않고 검색 가능한 경우 페어링할 수 있습니다. 주로 이 섹션을 참조하세요:

BLE 시리즈

문제가 있는 경우 이 지침을 사용하여 문제 해결을 수행하십시오: BLE 문제 해결

하드웨어 스위치

원래 딥 스위치 위치에는 푸시 스위치가 있습니다. 이것은 컨트롤러의 유일한 스위치입니다.

주목:

  • 이 스위치는 누르면 꺼지고, 올리면 켜집니다.
  • 이 스위치의 기능은 블루투스가 아니라 배터리 전원 공급을 켜거나 끄는 것입니다.
  • 따라서 이 스위치가 꺼져 있을 때에도 USB 케이블을 연결하면 USB가 전원이므로 Bluetooth가 계속 작동할 수 있습니다.

블루투스를 끄고 싶으시다면 블루투스 스위치 및 연결 상태를 참고하세요.

힌트

  • 이 소프트웨어 스위치는 USB만 또는 일시적으로 사용하는 사람들을 위해 **Bluetooth 기능**을 완전히 끄도록 설계되었습니다. 이 스위치가 꺼져 있는 동안 물리적 전원 스위치를 끄는 것이 좋습니다.
  • 이 기능은 에너지를 절약하기 위해 매일 Bluetooth를 끄도록 설계된 것이 아닙니다. BLE660C/BLE980C는 잠금 모드보다 이 기능을 사용하여 대기 모드에서 훨씬 더 많은 전력을 소모합니다.

배터리 충전

충전 포트와 데이터 포트는 모두 컨트롤러의 USB 포트입니다.

충전에는 PC의 USB 포트나 5V 충전기를 사용하는 것이 좋습니다.

  • 부적절한 충전(6V 이상)은 충전 IC를 파손할 수 있습니다. 고전력 충전기를 사용해도 기본 충전 전류가 약 450mA로 제한되어 충전 속도가 빨라지지 않습니다.
  • 충전에는 5V 이하의 충전기를 사용하세요. 전원 공급 장치 또는 다른 충전기가 있는 HUB의 일부 U 포트는 5V보다 높을 수 있습니다.
  • 장시간 플러그를 꽂아 사용할 경우, 배터리를 뽑아두거나 적어도 배터리 스위치를 끄는 것이 좋습니다.

충전 표시등은 전원 버튼 아래에 있는 빨간색(또는 파란색) LED입니다. 아래에서 볼 수 있습니다. 세 가지 상태가 있습니다. v2.3 버전에서는 충전 표시등이 제거되었지만 배터리 수준을 x1%로 표시하여 여전히 충전 중임을 판단할 수 있습니다.

충전 LED 상태 의미
밝기가 낮거나 깜박임 비정상(배터리가 없거나 배터리에 문제가 있음)
높은 밝기 충전 중
꺼짐 또는 매우 낮은 밝기 배터리가 완전히 충전되었습니다

win10 1809 이상에서는 배터리 백분율 표시가 지원됩니다. 정확하지 않으며 참조용일 뿐입니다(특히 충전 중에 표시되는 오류가 더 큽니다). 10%마다 수준이고 가장 높은 것은 90%입니다. 또한, 충전 중에는 백분율이 x1%로 표시되며 다음 그림과 같이 충전하지 않을 때보다 1% 더 높습니다.

완전히 충전되면 충전 표시등이 꺼지거나 밝기가 매우 낮아질 수 있습니다.

Mac은 타사 Bluetooth 장치의 배터리 서비스를 차단했습니다. 따라서 배터리 수준을 알고 싶다면 Output Battery Percetage as Text 기능(BLE660C/BLE980C의 기본 단축키는 Fn+E)을 사용할 수 있습니다. 충전 및 배터리 정보

키맵 편집 및 펌웨어 재플래시

웹사이트 https://ydkb.io를 열고 키보드 BLE660C 또는 BLE980C를 선택한 다음 [대용량 저장 장치 부트로더(U 디스크 모드)](부트로더/msd-부트로더) 페이지에 플래싱 방법이 있습니다. 키 편집기에 대한 설명은 이 문서의 다른 부분을 참조하세요.

케이블을 삽입하여 점멸 모드로 들어가려면 왼쪽 위 키(일반적으로 ESC)를 누르는 것 외에도 LED와 기능을 사용할 수 있습니다 Reset실수 로 누르는 것을 방지하기 위해 <kbd>LCtrl을 누른 상태에서 이 키를 누르면 됩니다. 이렇게 하면 플러그 Reset를 뽑았다가 다시 꽂지 않고도 바로 점멸 모드로 전환할 수 있습니다.

지표 및 전력 절약

표시기의 일반적인 기능은 LEDMAP 으로 정의할 수 있습니다 . 표시기는 키보드가 작동 중일 때만 켜지고 절전 모드는 아닙니다. 표시기를 계속 켜두는 기능으로 설정하지 않는 것이 좋습니다. 그러면 전력 소모가 증가하고 배터리 수명이 크게 줄어들 수 있습니다.

블루투스 모드에서 주의 사항

  • 블루투스 모드에서는 Num, Caps, Scroll Lock 표시등이 블루투스 모드의 OS 상태와 동기화되지 않습니다.
  • 블루투스 모드에서는 누르면 켜지거나 꺼집니다. USB 모드에서는 동기화됩니다.
  • 한 지표가 동기화되지 않은 경우 Shift + Capslock과 같은 Shift + KEY를 사용할 수 있습니다. 이런 식으로 CapsLock은 적용되지만 지표는 변경되지 않습니다.
  • 블루투스 모드에서 이 기능을 적절히 사용하면 표시등을 반대로 바꿀 수 있습니다. 예를 들어, Num Lock이 켜져 있을 때 Num Lock 표시등을 끄고 꺼져 있을 때 표시등을 켜면 전력을 절약할 수 있습니다.

LEDMAP 설정 외에도 몇 가지 특수 기능이 있습니다.

상태 또는 작업 BLE660C LED 표시 방식
플래시 모드(대기) 두 개의 표시등이 함께 깜박이거나 번갈아 깜박이며 절대 꺼지지 않습니다. 660C의 무소음 버전은 전면에 표시등이 하나뿐입니다.
플래시 모드(데이터 쓰기) 위의 내용을 토대로 Caps 표시등이 빠르게 깜빡입니다.
시작시 블루투스가 연결되지 않음 상태 표시 두 개의 표시등이 깜박이며 연결되지 않은 경우 약 15초 후에 깜박임이 멈춥니다.
시작 시 블루투스가 연결됨. 상태 표시 두 표시등이 동시에 느리게 깜박입니다. 켜지는 시간은 꺼지는 시간보다 훨씬 깁니다.
LShiftRShift+를 누르세요s 위와 같이 Bluetooth 연결 상태를 표시합니다.
수동으로 잠금 모드로 들어가기 두 개의 표시등이 동시에 켜진 후 Scroll 표시등, Caps 표시등 순으로 꺼집니다.
2단계 에너지 절약 또는 잠금 모드에서 깨어나기 두 개의 표시등이 동시에 켜진 후 Bluetooth 연결 상태를 나타내기 시작합니다.
배터리 부족 알림 키보드를 사용할 때는 두 개의 표시등이 동시에 깜박입니다. 에너지를 절약할 때는 깜박이지 않습니다. 2~3일은 여전히 ​​사용할 수 있습니다.
배터리가 매우 부족하다는 메시지 키보드를 사용할 때 두 개의 표시등이 동시에 빠르게 깜박입니다. 에너지를 절약할 때는 깜박이지 않습니다. 가능한 한 빨리 충전하는 것이 좋습니다.

BLE980C의 경우, 설명의 편의를 위해 전면의 3개 표시등을 왼쪽에서 오른쪽으로 LED1 LED2 LED3으로 표시하였습니다.

상태 또는 작업 BLE980C LED 표시 방식
점멸 모드(유휴) 3개의 표시등이 함께 깜박이거나 교대로 깜박이며 항상 켜져 있습니다.
플래시 모드(데이터 쓰기) 위 내용을 기준으로 LED3가 빠르게 깜박입니다.
시작 시 Bluetooth 연결 해제 상태 표시 LED3가 깜박이며, 연결되지 않은 경우 약 15초 후에 깜박임이 멈춥니다.
시작 시 Bluetooth 연결 상태 표시기 LED2와 LED3이 동시에 느리게 깜박입니다. 켜지는 시간은 꺼지는 시간보다 훨씬 깁니다.
LShiftRShift+를 누르세요s 위와 같이 Bluetooth 연결 상태를 표시합니다.
수동으로 잠금 모드로 들어가기 3개의 조명이 동시에 켜지고 LED3 LED2 LED1 순으로 꺼집니다.
2단계 에너지 절약 또는 잠금 모드에서 깨우기 3개의 표시등이 동시에 켜지고 블루투스 연결 상태를 나타내기 시작합니다.
배터리 부족 알림 키보드를 사용할 때는 세 개의 불빛이 동시에 깜빡인다. 에너지를 절약할 때는 깜빡이지 않는다. 2~3일은 쓸 수 있다.
배터리 매우 부족 알림 키보드를 사용할 때 세 개의 표시등이 동시에 빠르게 깜박입니다. 에너지를 절약할 때는 깜박이지 않습니다. 가능한 한 빨리 충전하는 것이 좋습니다.

힌트

  • 배터리 부족 프롬프트는 가장 높은 우선순위를 갖습니다. 배터리가 부족하면 항상 다른 것을 표시하고 덮습니다.
  • FC660C의 무소음 버전에는 스크롤 표시기가 없으므로 Caps 표시기를 보고 판단하세요.

그 다음은 절전 모드에 대해서입니다.

  1. 키보드가 아무 키도 누르지 않고 3초 동안 유휴 상태가 되면 일반 절전 모드로 들어갑니다. 이 모드에서는 30ms마다 매트릭스가 스캔됩니다. 아무 키나 누르면 일반 절전 모드에서 빠져나갑니다.
  2. 키보드의 블루투스가 90초 동안 연결되지 않거나 2.5시간 이상 사용하지 않으면 블루투스가 꺼지고 심층 절전 모드로 전환됩니다. 아무 키나 3~5초 동안 길게 눌러 깨우세요.
  3. 잠금 모드를 사용하면 키보드가 바로 심층 절전 모드로 전환됩니다. 2와의 차이점은 이 방법으로 F와 J만 3~5초 동안 함께 눌러서 깨울 수 있다는 것입니다.

심층 절전 모드의 전력 소모는 매우 낮습니다. 일상적으로 사용하는 경우 전원 스위치를 끌 필요가 없으며 키보드를 그대로 두고 절전 모드로 전환하면 됩니다. 가방에 넣어 가지고 다니려면 잠금 모드로 전환하여 예기치 않게 깨어나는 것을 방지하는 것이 좋습니다.

다음 GIF는 배터리가 부족할 때의 효과를 보여줍니다.

예외 처리

키 누름 오류 트리거 또는 무작위 트리거가 있는 경우. 타오바오 링크에서 제공하는 설치 지침에 따라 배터리가 hhkb 상단 키보드 회로 보드에서 절연되어 있는지 확인하십시오.

작업 중에 문제가 발생하면 가장 빠른 방법은 USB 케이블을 다시 연결하거나 키보드 전원 스위치를 껐다가 다시 켜서 제대로 작동하는지 확인하는 것입니다.

그리고 BLE 문제 해결 을 참조하세요 . 다른 버그가 있으면 이메일로 알려주세요.

하드웨어 버전의 차이점

나중에 다른 사람들이 볼 수 있도록 판매된 하드웨어 버전 간의 차이점을 기록해 두세요.

v2.3:메인 컨트롤 atmega32u4의 패키지를 변경했습니다. 일부 커패시터와 저항의 패키지를 변경했습니다(0805 -> 0603). 컨트롤러의 충전 표시등을 제거했습니다.

v2.2:v2.1 기반으로, LWinLAlt+를 사용하여 RestBluetooth를 재설정할 수 있습니다.

v2.1:v2.0을 기반으로, 블루투스를 재설정하기 위한 단락 회로를 용이하게 하기 위해 두 개의 구멍이 추가되었습니다. 그리고 외부 크리스털 발진기 대신 MCU의 내장 발진기를 사용합니다.

Connect Synology and APC UPS with SNMP protocol

Synology NAS의 안정적인 운영을 위하여 APC사의 UPS를 설치하였다.

UPS 사양은 다음과 같다.

APCSmart-UPS CMS-1500IC

APC UPS의 경우 PowerChute 어플리케이션을 통해서 상황에 따라 서버 전원을 내릴 수 있게 지원하고 있다.

하지만 Synology의 경우 해당 어플리케이션이 없었고, 기본적으로 제공하는 SNMP 기반의 안전모드를 사용해야 했다.

먼저 UPS SNMP를 먼저 설정해준다.

## SNMP V1 이용 시

1. UPS Management Web 접속
2. UPS Management 로그인
3. PowerChute -> SNMP Setting -> SNMPv1(+) 로 이동
4. Enable 체크 후 Apply 클릭
5. User Profiles Add Profile 클릭
6. Community Name 입력 (원하는 값으로)
7. NMS IP/Host Name 설정 (기본값은 0.0.0.0 으로 모두 접속 허용)
   > NMS IP값에 특정 IP를 적으면 그 IP 장비만 SNMP에 접속 할 수 있음.(*Host Name 안됨.)
8. Access Type은 Read로 설정
9. OK 선택 후 Apply 클릭

위와 같이 SNMP 설정이 끝나면, 다음은 Synology NAS 설정이다.

1. Synology NAS 로그인
2. 제어판 열기
3. 하드웨어 및 전원 -> UPS 이동
4. UPS 지원 활성화 체크
5. 네트워크 UPS 유형 "SNMP UPS" 선택
6. RackStation이 안전 모드로 설정되기 전 대기 시간 설정
   (원하는 시간, 예를 들어 20분 등)
7. SNMP UPS IP 주소 입력 (UPS 주소)
8. SNMP MIB는 auto로 설정 (* "apcc" 로 잡아주는게 정확한 값임)
9. SNMP 버전은 v1으로 설정
10. SNMP 커뮤니티는 UPS에서 설정한 값을 입력
11. 적용

위의 절차를 진행하고 잠시 기다리면 장치정보를 확인할 수 있다.

 

## SNMP V3 이용 시

위와 같이 SNMP 설정이 끝나면, 다음은 Synology NAS 설정이다.

 

장치 정보 확인 시 UPS 검색 잘 되면

그럼 끝!

Remote-FX : Enable GPU use during RDP mstsc remote connection

원격데스크톱 연결시, Remote-FX 사용하기.

원래 RDP(Remote Desktop Protocol)는 Client Rendering 입니다.

반면, Remote-FX 기술은 Host Rendering입니다.

 

*  컴퓨터에 원격데스크톱 클라이언트 7.1 이상이 있어야함.  (* Win7 Ulti – SP1이상, WinXP SP3이상)

1. 관리자 권한으로 ‘실행’을 실행해주세요.  (*RDP Server 역할에서 설정해야 함.)

2. gpedit.msc를 치고 엔터. (그룹정책편집기 실행)

 

2.  컴퓨터구성 -> 관리 템플린 -> Windows 구성요소
-> 터미널 서비스 -> 원격 데스크톱 세션 호스트 -> 원격 세션 환경으로 갑니다.

3. 원격 세션 환경에 들어가셔서,

모든 원격 데스크톱 서비스 세션에 “하드웨어 그래픽 어탭터 사용”을 “사용”으로 바꿔 줍니다.

> WinXP, 7 : Remote FX 구성을 더블클릭하셔서 사용에 체크하고 확인.
> Win 8 이상 : Enable RemoteFX encoding for RemoteFX clients designed for Windows Server                                2008 R2 SP1 항목 더블클릭 후 사용에 체크하고 확인.

나머지는 읽어 보시면서 필요한걸 사용으로 바꿔주도록 합니다.

“하드웨어 그래픽 사용” 이외 셋팅을 하실땐, 가능하면 옆에 노트북 or 옆에 자리 사람 pc 에서 원격 테스트를 하는게 좋습니다. 귀찮다고 모두 사용으로 바꿔 버리면 아래처럼 진짜 집에서 할때 연결이 안되 낭패를 볼 수 있습니다.

 

제 PC의 셋팅값. 성능을 잡으면서 원격 접속 오류가 안나는 셋팅을 찾는게 중요하고 모르겠으면 하드웨어 그래픽 어댑터 사용만 합니다..

 

다 되었으면  RemoteFX For Windows Server 2008 R2 .. 폴더로 들어갑니다.

4.  Configure RemoteFX (RemoteFX 구성) 을 사용으로 바꿔 줍니다.

 

* RemoteFX를 사용하시려면, 호스트 컴퓨터의 사용자에게도 Remote Desktop User 권한이 주어져       있어야합니다.

1. 관리자권한으로 ‘실행’을 실행해주세요.

2. lusrmgr.msc를 치고 엔터.(로컬사용자편집기)

3. 사용자 폴더에 가셔서, 자신의 계정을 오른쪽클릭 -> 속성

4. 소속 그룹 탭에 가셔서, 밑의 추가버튼을 눌러주세요.

5. 그룹 선택 창에서 고급을 누르시고, 찾기 버튼을 눌러주세요.

6. 그러면 밑에 좌라락 뜨는데요, 거기서 Remote Desktop Users 를 누르시고 확인.

7. 확인 확인 확인 누르시고, 창 닫아주시면 됩니다.

이렇게 다 해주시고, 컴퓨터 다시 껐다가 켜주시면 Remote FX가 활성화 된 상태가 됩니다.

이후 리붓하고 노트북등으로 RDP접속 해 보면 한결 빨라진걸 느낄 수 있습니다.

 

[Docker SWARM] Configuring a cluster environment using SWARM

manager : docker swarm 클러스터의 manager 노드

worker01, worker02, worker03 : docker swarm의 worker노드들 (3개)

registry : docker private registry 서비스

registry-web : docker private registry에 어떤 이미지가 올라가 있는지 web UI로 확인하는 서비스

dashboard : docker swarm 클러스터의 노드들을 web UI로 확인할 수 있는 서비스

 

대충 최종 모습(?)

 

준비사항

$ docker -v
Docker version 20.10.5, build 55c4c88

docker가 설치되어 있어야 한다.

$ docker-compose -v
docker-compose version 1.28.5, build c4eb3a1f

docker-compose도 설치되어 있어야 한다.

서비스 파일 작성

– docker-compose.yml

$ cat docker-compose.yml
version: "3"
services:
  registry-web:
    container_name: registry-web
    image: hyper/docker-registry-web
    ports:
      - 8080:8080
    volumes:
      - "./config.yml:/conf/config.yml:ro"

  registry:
    container_name: registry
    image: registry:2.6
    ports:
      - 5000:5000
    volumes:
      - "./registry-data:/var/lib/registry"

  manager:
    container_name: manager
    image: docker:18.05.0-ce-dind
    privileged: true
    tty: true
    ports:
      - 8000:80
      - 9000:9000
      - 8081:8081
      - 4567:4567
    depends_on:
      - registry
    expose:
      - 3375
    command: "--insecure-registry registry:5000"
    volumes:
      - "./stack:/stack"
      - "./dashboard:/dashboard"

  worker01:
    container_name: worker01
    image: docker:18.05.0-ce-dind
    privileged: true
    tty: true
    depends_on:
      - manager
      - registry
    expose:
      - 7946
      - 7946/udp
      - 4789/udp
    command: "--insecure-registry registry:5000"

  worker02:
    container_name: worker02
    image: docker:18.05.0-ce-dind
    privileged: true
    tty: true
    depends_on:
      - manager
      - registry
    expose:
      - 7946
      - 7946/udp
      - 4789/udp
    command: "--insecure-registry registry:5000"

  worker03:
    container_name: worker03
    image: docker:18.05.0-ce-dind
    privileged: true
    tty: true
    depends_on:
      - manager
      - registry
    expose:
      - 7946
      - 7946/udp
      - 4789/udp
    command: "--insecure-registry registry:5000"

manager와 worker 노드들은 dind(docker in docker) 이미지로 생성한다. dind는 간단히 말하자면 docker 컨테이너 안에서 docker cli를 사용하는 것이다.

registry와 registry를 web UI로 보여주는 서비스들을 추가한다. registry-web은 8080 포트로 접속할 것이다.

– config.yml

$ cat config.yml
registry:
  # 기존에 설치한 docker private registry
  url: http://registry:5000/v2
  # Docker registry name
  name: localhost:5000
  # docker 권한 부여
  readonly: false
  auth:
  eabled: false

registry-web에 사용될 yml 파일이다. private registry가 사용하는 5000번 포트로 url을 설정한다.

– dashbaord.yml

$ cat dashboard/dashboard.yml
version: "3"

services:
  dashboard:
    image: charypar/swarm-dashboard
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    ports:
      - 8081:8081
    environment:
      PORT: 8081
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager

docker-compose.yml 파일을 보면 manager 노드에 /dashboard 디렉토리를 마운트 해주었는데 즉, docker-compose.yml이 있는 곳에 dashboard라는 디렉토리를 만들고, 그 안에 dashboard.yml을 작성하였다.

dashboard 서비스는 manager 노드에만 생성되고, 브라우저에서 8081포트로 접속한다.

swarm-dashboard에 대한 github 주소는 아래와 같다. 개발자 분에게 감사합니다.

github.com/charypar/swarm-dashboard

– 디렉토리 상태

$ ls
config.yml  dashboard  docker-compose.yml

dashboard만 디렉토리이고, dashboard 디렉토리 안에 dashboard.yml 파일이 있다.

docker compose 실행

– docker-compose up -d

$ docker-compose up -d
Creating network "swarm_default" with the default driver
Creating registry     ... done
Creating registry-web ... done
Creating manager      ... done
Creating worker01     ... done
Creating worker03     ... done
Creating worker02     ... done

-d 옵션은 백그라운드로 시작하는 뜻이다.

– 디렉토리 재확인

$ ls
config.yml  dashboard  docker-compose.yml  registry-data  stack

docker-compose up을 실행하면 위처럼 registry-data와 stack 디렉토리가 생기는걸 확인할 수 있다. registry-data 디렉토리를 registry 서비스의 /var/lib/registry 디렉토리와 마운트 시켜놓으면, registry 서비스가 중지되어도 데이터가 그대로 유지된다.

– localhost:8080 접속

 

registry-web 접속

 

registry-web에 접속하면, 현재 registry 상태를 web UI를 통해 확인할 수 있다.

private registry에 이미지 업로드

docker swarm service에 사용할 이미지를 다운로드 받고, 직접 private registry에 이미지를 업로드 해본다.

– docker pull

$ docker image pull subicura/whoami:1

위의 이미지를 받는다. 브라우저로 접속하면 hostname을 출력해주는 docker 이미지이다.

– docker tag

$ docker image tag subicura/whoami:1 localhost:5000/example/whoami:latest

private registry의 포트가 5000이므로, 위와같이 docker image tag 명령어를 통해 이미지 이름과 tag 정보를 변경한다. 이미지의 첫 항목이 image pull 진행 시, 이미지가 올라가는 도메인 정보이다.

– docker image push

$ docker image push localhost:5000/example/whoami:latest
The push refers to repository [localhost:5000/example/whoami]
6304fb0017b0: Pushed
bcd68c905028: Pushed
5f4ed2a4afd7: Pushed
1fad3fef68ba: Pushed
42e63b663df9: Pushed
71d7318763a9: Pushed
7d7e183520a5: Pushed
7cbcbac42c44: Pushed
latest: digest: sha256:6239cd2462f9dd7a0317db107724a101deca600d30e39465515ba632e0982f4a size: 1989

이미지가 푸쉬되는걸 확인할 수 있다.

– registry web 확인

 

registry-web

 

이미지가 올라간것을 확인할 수 있다. 이제 docker swarm 노드에서 이미지를 다운받아 사용할 수 있다.

docker swarm 구성하기

– docker swarm init

$ docker exec -it manager docker swarm init
Swarm initialized: current node (5ywj85cw3tdz8ioe71v1xlyzn) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-1gxj86agzmecefcd6mwjproa96hw7e3gu0plsdhuw9110fuc1r-7q4434lsegri8la2n9qgggsrd 172.22.0.4:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

manager 컨테이너에서 docker swarm init 명령어를 입력한다. 위처럼 docker swarm join 부분 전체를 복사한다. worker 노드들에서 전부 입력하면 된다.

– docker swarm join

$ docker exec -it worker01 docker swarm join --token SWMTKN-1-1gxj86agzmecefcd6mwjproa96hw7e3gu0plsdhuw9110fuc1r-7q4434lsegri8la2n9qgggsrd 172.22.0.4:2377
This node joined a swarm as a worker.

$ docker exec -it worker02 docker swarm join --token SWMTKN-1-1gxj86agzmecefcd6mwjproa96hw7e3gu0plsdhuw9110fuc1r-7q4434lsegri8la2n9qgggsrd 172.22.0.4:2377
This node joined a swarm as a worker.

$ docker exec -it worker03 docker swarm join --token SWMTKN-1-1gxj86agzmecefcd6mwjproa96hw7e3gu0plsdhuw9110fuc1r-7q4434lsegri8la2n9qgggsrd 172.22.0.4:2377
This node joined a swarm as a worker.

Swarm dashboard 서비스 실행

– swarm dashboard stack deploy

$ docker exec -it manager docker stack deploy -c /dashboard/dashboard.yml dashboard
Creating network dashboard_default
Creating service dashboard_dashboard

컨테이너에 마운트해둔 /dashboard/dashboard.yml을 사용해 dashboard서비스를 실행한다.

– dashboard 접속

 

dashboard 접속

 

localhost:8081로 접속하면, 위처럼 현재 Swarm cluster의 상태를 확인할 수 있다. 현재 manager 노드에 dashboard 서비스 한개만 올라가 있는 상태이다.

Swarm 클러스터에 서비스 등록

private registry에 올려놨던 image를 manager 노드에서 pull 받아서 swarm 클러스에서 서비스로 등록해본다.

– docker pull image

$ docker exec -it manager docker pull registry:5000/example/whoami:latest
latest: Pulling from example/whoami
d1426d011624: Pull complete
1659ef4c811e: Pull complete
47bd5f3578fc: Pull complete
5e03057c6ddf: Pull complete
d58f420d5777: Pull complete
d65d30e11c7f: Pull complete
c9d3f35ab05f: Pull complete
fb24e6aeba3f: Pull complete
Digest: sha256:6239cd2462f9dd7a0317db107724a101deca600d30e39465515ba632e0982f4a
Status: Downloaded newer image for registry:5000/example/whoami:latest

– docker service create

$ docker exec -it manager docker service create --name whoami -p 4567:4567 registry:5000/example/whoami:latest
wkkg33d93qity2dustm8dkxvf
overall progress: 1 out of 1 tasks
1/1: running   [==================================================>]
verify: Service converged

– docker service 확인

$ docker exec -it manager docker service ls
ID                  NAME                  MODE                REPLICAS            IMAGE                                 PORTS
isro3osqfsn5        dashboard_dashboard   replicated          1/1                 charypar/swarm-dashboard:latest       *:8081->8081/tcp
wkkg33d93qit        whoami                replicated          1/1                 registry:5000/example/whoami:latest   *:4567->4567/tcp

dashboard 서비스와 whoami 서비스를 확인할 수 있다.

 

 

dashboard에서도 whoami 서비스 하나가 추가된 것을 확인할 수 있다.

– service scale 조절

$ docker exec -it manager docker service scale whoami=6
whoami scaled to 6
overall progress: 6 out of 6 tasks
1/6: running   [==================================================>]
2/6: running   [==================================================>]
3/6: running   [==================================================>]
4/6: running   [==================================================>]
5/6: running   [==================================================>]
6/6: running   [==================================================>]
verify: Service converged

docker service scale 명령어로 서비스의 스케일링을 간단하게 진행할 수 있다. whoami 서비스가 원래 1개였는데, 6개로 늘렸다.

 

 

dashboard에서도 whoami 서비스가 6개로 증가한 것을 확인할 수 있다.

curl test

$ curl localhost:4567
444593584a03
$ curl localhost:4567
fb1e399ac4ed
$ curl localhost:4567
a8948b879833
$ curl localhost:4567
f565b65a22ab
$ curl localhost:4567
7160d9d9e250
$ curl localhost:4567
d7c6861c57e0
$ curl localhost:4567
444593584a03
$ curl localhost:4567
fb1e399ac4ed
$ curl localhost:4567
a8948b879833
$ curl localhost:4567
f565b65a22ab
$ curl localhost:4567
7160d9d9e250
$ curl localhost:4567
d7c6861c57e0

노드들의 hostname이 적절히 분배되어 출력되는걸 확인할 수 있다. docker swarm의 경우 ingress 네트워크가 트래픽 분산을 자동으로 해준다.

Oracle Delete문 사용 후 Tablespace 정리하기

일단 Tablespace 용량 확인 쿼리

select substr(a.tablespace_name,1,30) tablespace,
round(sum(a.total1)/1024/1024,1) “TotalMB”,
round(sum(a.total1)/1024/1024,1)-round(sum(a.sum1)/1024/1024,1) “UsedMB”,
round(sum(a.sum1)/1024/1024,1) “FreeMB”,
round((round(sum(a.total1)/1024/1024,1)-round(sum(a.sum1)/1024/1024,1))/round(sum(a.total1)/1024/1024,1)*100,2) “Used%”
from
(select tablespace_name,0 total1,sum(bytes) sum1,max(bytes) MAXB,count(bytes) cnt
from dba_free_space
group by tablespace_name
union
select tablespace_name,sum(bytes) total1,0,0,0
from dba_data_files
group by tablespace_name) a
group by a.tablespace_name
order by tablespace;

 

위 쿼리로 조회하면 UsedMB와 FreeMB를 조회 할 수 있다.

나는 UsedMB를 처리해야 하는 것.

데이터를 지우기에 앞서 Tablespace가 아닌 해당 Table에서 사용 중인 block를 확인해보았다.

select count(distinct dbms_rowid.rowid_block_number(rowid)) blocks from person;
select blocks, extents from user_segments where segment_name = ‘PERSON’;

 

 

 

person 테이블에서 사용 중인 block는 1241개고, 할당된 block는 1280개.

 

이제 Delete 문으로 데이터를 삭제한다.

DELETE FROM [TABLENAME] WHERE [COLUMN] = [VALUE]

 

27319개의 row를 삭제하였다.

다시 block 사용량을 확인하였다.

 

Delete 문으로 데이터를 지웠으나 다들 알다시피 delete 문으로는 Tablespace 용량이 줄어들지 않는다.

(삭제 조건을 줘야하기 때문에 truncate는 사용 불가능)

사용한 block는 줄어들었으나 hwm은 줄어들지 않았다.

 

이제 shrink를 실행해보았다.

ALTER TABLE PERSON SHRINK SPACE
ALTER TABLE PERSON SHRINK SPACE CASCADE

 

 

HWM도 줄어들고 Tablespace 사용량도 줄어들었다.

 

★ ORA-10636: ROW MOVEMENT is not enabled 에러 발생 시

row movement 기능이 꺼져 있는 것이니 켜줘야 한다.

ALTER TABLE PERSON ENABLE ROW MOVEMENT;

row movement 기능을 끄려면 아래 쿼리를 수행한다.

ALTER TABLE [테이블명] DISABLE ROW MOVEMENT;

 

★ SHRINK 차이점

우측 설명은 그냥 내가 이해한대로 작성한 것임

CASCADE의 이해도가 부족한데 좀 더 찾아봐야겠음.

 

 

SHRINK SPACE HWM 축소
SHRINK SPACE COMPACT Block 정리는 수행하지만 HWM을 건드리지 않음
SHRINK SPACE CASCADE 연관된 인덱스 정리

 

공식 URL : http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#i2192484

CIDR(Classless Inter-Domain Routing) 표기법

인터넷 주소 체계인 IP는 간혹 ‘1.1.1.1/32’와 같은 형태로 표기됩니다. 앞부분인 1.1.1.1이 IP인것은 알겠는데 /32이 무엇을 의미 하는지 모르는 분들을 위해 오늘은 /32이 무엇을 의미하는지 알려 드리겠습니다.

IP는 마침표로 구분되는 4개의 영역을 가지고 있습니다. 각각의 영역을 옥텟이라고 부르며 1개의 옥텟에 1byte의 크기를 가집니다. 0~255까지 표현이 가능하며 총 4byte(32bit)의 크기를 가집니다.

이러한 구성의 가진 IP는 효율적으로 사용하기 위해 Net ID와 Host ID로 나누어 사용합니다.

Net ID는 네트워크 영역을 식별하기 위한 값이며 Host ID는 하나의 네트워크 영역에서 호스트를 식별하기 위한 값입니다.

위에 그림처럼 Net ID는 좌측 비트부터 사용하게 되는데 옥텟과 마침표만 을 사용하면 어디까지가 Net ID이고 Host ID인지 알수 있는 방법이 없습니다.
때문에 보편적으로 CIDR(Classless Inter-Domain Routing)의 유연성있는 서브넷 마스크 표기법을 이용하여 표현합니다.

Subnet mask 표기법 -> 1.1.1.1 (255.255.255.255)
CIDR(prefix) 표기법 -> 1.1.1.1/32

위에서 표현한 1.1.1.1/32는 좌측부터 32비트가 전부 Net ID라는 뜻이며 1.1.1.1은 하나의 호스트 IP를 나타냅니다.
만약 1.1.1.0/24와 같이 표현된다면 좌측에서 부터 24비트, 즉 1.1.1까지는 Net ID라는 뜻이며 1.1.1.0 ~ 1.1.1.255가 1.1.1.0대역 네트워크에서 보유한 호스트 들이 됩니다.

해당 내용을 이용하여 방화벽을 설정할 경우 1.1.1.0/24로 설정하여 1.1.1.0~1.1.1.255에 해당 하는 256개의 ip를 CIDR표현식 한 줄로 설정할 수 있게 됩니다.

Elastic Search Index and Shade Split point

여러개의 샤드 vs 인덱스 쪼개기

다나와 서비스의 상품갯수는 급격하게 늘어나고 있습니다. 몇달전 4~5억건이었던 상품이 7억건에 육박하고 있는데요. 현재 사용하고 있는 패스트캣 검색엔진에서는 대량의 문서들을 여러개의 인덱스로 나누어 색인하고 있습니다.

검색할때는 나눈 인덱스들을 하나로 합쳐서 검색하고 있는데요. 엘라스틱서치에도 여러 인덱스를 하나로 합쳐서 한번에 검색하는 기능이 있어서 지금처럼 인덱스를 쪼개서 사용하는 것도 가능한 시나리오입니다. 참고로 얘기하면, 이렇게 데이터를 범위나 카테고리로 나누어 관리하는 기법을 파티셔닝이라고 합니다.

먼저 인덱스를 하나로 가져가든 여러개로 나누든, 샤드 하나의 크기는 비슷하게 설정해야 할텐데요, 적절한 샤드의 크기를 먼저 정해야 할 것 같습니다. 몇차례 구글링을 한결과 엘라스틱서치의 공식블로그에서 도움이 될만한 글를 찾을수 있었습니다.

TIP: 작은 샤드는 작은 세그먼트를 만들며 부하를 증가시킵니다. 평균 샤드 크기를 최소한 수 GB와 수십 GB 사이를 유지하세요. 시간 기반 데이터를 사용한 과거 사례를 보면, 20GB ~ 40GB 정도의 사이즈가 적당합니다.

샤드크기는 수GB에서 수십GB 사이가 적당하며, 경험상 시계열 데이터의 경우 20GB~40GB가 적당하다고 합니다. 그리고 아래에서 또다른 팁을 발견할수 있었습니다.

TIP: 하나의 노드에 저장할 수 있는 샤드의 개수는 가용한 힙의 크기와 비례하지만, Elasticsearch에서 그 크기를 제한하고 있지는 않습니다. 경험상 하나의 노드에 설정한 힙 1GB 당 20개 정도가 적당합니다. 따라서 30GB 힙을 가진 노드는 최대 600개 정도의 샤드를 가지는 것이 가능하지만, 이 보다는 적게 유지하는 것이 더 좋습니다.

힙메모리 30GB로 엘라스틱서치를 구동시 샤드는 최대 600개 정도라고 합니다. 이미 32GB 를 힙에 할당할 생각을 하고 있으므로, 활성화된 인덱스가 50개라고 한다면, 인덱스당 600샤드 / 50 인덱스 = 12 로 인덱스당 최대 12개의 샤드를 설정할수 있을 겁니다. 일단 샤드갯수의 최대치는 넉넉한것 같으므로, 많아서 문제가 될것같지는 않습니다.

하나의 샤드를 20GB~40GB로 설정한다면, 7억건의 상품은 몇개의 샤드로 나눠지게 될까요? 다나와 상품기준으로는 15개의 샤드로 나눠지게 됩니다. 물론 엘라스틱 서치 블로그에서는 시계열 데이터에 대한 팁이라서 상품과는 문서의 특성이 다릅니다. 대부분은 웹서버나 DB 로그데이터 일텐데요, 로그스태시의 파싱모듈을 확인해보면 한 로그내의 필드수가 10개 내외로 매우 적습니다. 반면에 상품의 필드는 수십개는 기본입니다.

이러한 문서특성의 차이로 검색과 색인시 한개 문서에 들어가는 리소스와 시간이 더 투여됩니다. 그러므로, 상품문서는 하나의 샤드를 20GB 보다는 조금 더 작게 나누면 여러 서버에 더 잘게 분산이 되어 전체적인 응답시간은 더 빨라질겁니다. 우리는 샤드당 약 5GB로 설정하고 테스트 했는데, 빠른 응답속도를 얻을 수 있었습니다.

그럼, 인덱스를 나누는것과 샤드를 나누는것 어떤것이 적합할까요? 어치피 샤드는 여러 서버에 분산되어 병렬 및 병행 (참고: https://soy.me/2015/01/03/concurrent/)으로 검색이 되므로, 인덱스가 같던 다르던 상관은 없습니다. 검색의 기본 단위는 샤드이기 때문이죠. 따라서 인덱스를 나누는 것은 운영의 편의성을 고려할때 선택하는 방법입니다. 장애없는 운영의 측면에서 생각해보면, 큰 덩어리 하나를 다루는 것은 부담스러워도, 작은 덩어리 여러개를 다루는 것이 번거롭긴해도 그만큼 장애 가능성을 낮추는 방법이 됩니다.

전체색인을 빠르게 하려면

전체색인을 할 경우 인덱스 하나가 7억건이라면 색인이 모두 끝날때까지 약 3-4시간이 소요될것이고, 검색에 노출되기 까지 이시간을 고스란히 기다려야 합니다. 더 문제가 되는것은 전체색인 도중에도 상품의 가격은 계속해서 변하게 되는데 이 변경분을 전체색인후에 일괄적용을 해야하며, 대기시간이 길수록 일괄적용시간도 늘어나게 됩니다. 그러므로, 최대한 전체색인을 빠르게 해야하는데, 이를 위해서는 문서를 입력하는 REST 클라이언트를 멀티스레드로 여러개 생성하여 동시입력량을 늘려야 합니다. 이때 Bulk Insert 를 쓰는것은 기본이구요.

하지만, 엘라스틱서치의 Write IO도 고려해야 합니다. 동시입력량을 늘리면, 서버의 CPU와 Disk IO중 둘중 하나는 최대치에 이를것이고, 더이상 색인속도는 늘어나지 않게 됩니다. 우리가 경험한 최대 색인속도는 500KB 상품문서 기준으로 16000건/초 였습니다. 이때 CPU는 32코어로 90%를 사용했으니 활용도는 매우 높다고 할수 있습니다. (참고: https://danawalab.github.io/elastic/2020/07/06/Elasticsearch-Index.html)

결국은 더 빠른 색인을 위해서는 하나의 인덱스를 여러개로 나눠야 합니다. 통으로 4시간이 걸리는 문서를 10개의 인덱스로 나누면 색인시간이 서버를 공유하므로 정확히 1/10이 될수는 없지만, 그대로 각각 40분정도로 병행완료가 됩니다.

상품DB의 특성상 우리는 카테고리군별로 인덱스를 나누고 있습니다. 카테고리별로 인덱스를 나눌때의 장점은 특정카테고리만 검색할때 해당 인덱스만 검색하면 되므로, 검색부하가 현저히 감소하게 됩니다. 우리는 인덱스도 나누고 샤드도 2-3개로 나누어 전체적인 검색응답시간을 최대한 단축하는 방향으로 설계했습니다.

레플리카 갯수는 몇개로?

고가용성을 추구할때 빼놓을 수 없는 것이 레플리카인데요, 레플리카는 레플리카 샤드를 줄여서 얘기하는 것으로, 프라이머리 샤드에 종속됩니다. 우리말로는 복제본 이라고도 하죠. 복제본은 분산 데이터 시스템에서는 동일한 역할을 담당하는데요, 하드웨어 장애를 극복하고 검색과 같은 읽기처리량을 향상시키는 것입니다.

그런데 읽기성능이 좋아진다는 것은 쓰기성능이 낮아진다는 얘기도 됩니다. 왜냐하면, 복제본을 여러개 만들기 위해서는 그만큼 문서색인시에 쓰기작업도 복제본 갯수만큼 발생하기 때문이죠. 하나의 서버만 본다면 1이지만, 전체클러스터 입장에서는 복제본이 열개면 10의 쓰기가 일어나는 것입니다. 문서가 색인될때 구지 모든 서버의 IO발생하게 만들 필요는 없을겁니다.

또한 복제본의 갯수는 동시에 장애가 발생할 노드를 몇개 까지 허용하는지에 달려있습니다. 복제본이 1개라면 하나의 노드가 죽어도 검색서비스는 유지됩니다. 하지만, 이제 복제본은 0개가 되므로, SA가 빨리 노드를 복구하지 않으면, 다른 또하나의 노드가 죽을때 검색서비스에는 장애가 생깁니다.

만약 회사내에 장애 복구시스템이 잘 갖춰져 있다고 하면, 복제본은 1개로도 가능합니다. 복제본이 2라면 서버가 연속 2개 죽어도 상관이 없으므로, 마음을 느긋하게 가질수 있습니다. 하지만 전체 클러스터에서 서버가 2개 빠지고도 부하를 충분히 견딜수 있게 서버를 배치해 놓아야 합니다. 우리는 카테고리별 인덱스의 읽기성능을 고려해서 부하가 높은 인덱스는 복제본 2를 나머지는 1을 설정할 계획입니다.

결론

nginx로그와 같은 로그성 문서는 색인을 하고 나면 수정이 필요없는 정적인 컨텐츠인 반면에, 상품문서는 색인이 끝나도 계속 갱신이 되어야 하는 살아있는 컨텐츠입니다. 그렇기 때문에, 동적색인이 원활하고 장애도 대비할수 있으며, 검색성능도 높은 설계가 필요합니다. 그리고 엘라스틱서치를 사용하여 검색시스템을 설계할때 운영자가 할수 있는 최선의 방법은 문서와 샤드를 잘 관리하는 것입니다. 따라서 견고한 검색시스템을 위해 인덱스와 샤드를 어떻게 설정해야 하는지에 대해 살펴봤습니다.

참고

https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

https://medium.com/kariyertech/elasticsearch-cluster-sizing-and-performance-tuning-42c7dd54de3

https://www.elastic.co/guide/en/elasticsearch/reference/current/scalability.html

Configuring Monitoring Dashboards Through Grafana

그라파나?

  • 그라파나는 데이터를 시각화하여 분석 및 모니터링을 용이하게 해주는 오픈소스 분석 플랫폼입니다. 여러 데이터 소스를 연동하여 사용 할 수 있으며 시각화 된 데이터들을 대시보드로 만들 수 있습니다.

    LIVE DEMO

  • 앞서 설치한 그라파나와 프로메테우스의 메트릭 정보를 조회하여 시각화 하는 방법에 대해 알아보겠습니다.

구성 방법

1. 데이터 소스 생성

  • Create a data source 메뉴를 선택합니다. /images/2020-03-17-Common-Dashborad/grafana_1.PNG
  • 데이터 소스로 프로메테우스를 선택합니다. /images/2020-03-17-Common-Dashborad/grafana_2.PNG
  • 프로메테우스 서버 정보를 입력한 후 하단의 Save&Test를 클릭합니다.
    • 연결테스트 후 이상이 없다면 저장됩니다.

/images/2020-03-17-Common-Dashborad/grafana_3.PNG

2. 대시 보드 생성

  • 홈으로 돌아와 Build a dashboard 메뉴를 선택합니다.

/images/2020-03-17-Common-Dashborad/grafana_4.PNG

  • 패널 선택장이 나옵니다. 대시보드는 이 패널들을 구성하고 배치하면 됩니다.
    • 메트릭 조회를 위해 Add Query를 선택합니다

/images/2020-03-17-Common-Dashborad/grafana_5PNG

  • Query 선택창에서 앞에 생성한 Data Source를 불러옵니다.
  • Metric에선 노드익스포터에서 수집한 항목을 선택합니다.

/images/2020-03-17-Common-Dashborad/grafana_7PNG

잠시 돌아와서 위에 선택한 메트릭 항목은 아래와 같은 구조를 가지고 있습니다.
따라서 Metric name으로만 조회시 프로메테우스 서버가 수집한 같은 이름 항목 전부를 조회 합니다. Label name으로 구분하여 조회 할 수 있습니다.
  • Prometheus Metric

/images/2020-03-17-Common-Dashborad/metrics.PNG

  • 이처럼 프로메테우스 서버에서도 메트릭을 조회할 수 있습니다.
  • node_cpu_seconds_total{job=”kube2”,mode=”system”}
    • ex) kube2 host에서 system 영역 cpu 사용률

/images/2020-03-17-Common-Dashborad/grafana_9.PNG

  • 다시 돌아와서 생성한 패널 쿼리에 적용해보겠습니다.

/images/2020-03-17-Common-Dashborad/grafana_10.PNG

  • node_cpu_seconds_total는 계속 누적이 되고 있는 값이기 때문에 rate함수를 사용합니다.
  • rate(node_cpu_seconds_total{job=”kube2”,mode=”system”}[10m])
    • 10분동안 CPU 사용율 변화수치를 초당으로 변환

/images/2020-03-17-Common-Dashborad/grafana_11.PNG

  • CPU 코어의 평균을 구하여 해당 서버의 CPU 평균 사용률을 표시합니다. -avg(rate(node_cpu_seconds_total{job=”kube2”,mode=”system”}[10m])) by (job)

/images/2020-03-17-Common-Dashborad/grafana_12.PNG

  • 설정에서 그래프 종류를 선택할 수 있습니다.

/images/2020-03-17-Common-Dashborad/grafana_6.PNG

이처럼 자신의 필요한 메트릭 정보를 집계하여 패널로 만든 후 대시보드를 구성하면 됩니다.

외부 대시보드 포맷 사용

  • 매트릭 정보를 직접 집계하여 사용하거나 필요한 데이터를 정의하는게 나름 번거로운 작업이라 그라파나 홈페이지에 다른 여러 사용자들이 구성해놓은 대시보드 포맷을 사용하면 더 쉽게 대시보드를구현할 수 있습니다.

https://grafana.com/grafana/dashboards

/images/2020-03-17-Common-Dashborad/grafana_13.PNG

  • import 화면에서 다운받은 JSON 파일을 upload하거나 COPY ID를 입력하여 적용합니다.

/images/2020-03-17-Common-Dashborad/grafana_14.PNG

결론

프로메테우스, 그라파나를 통해 비교적 쉽게 모니터링을 위한 프로세스들을 만들 수 있었습니다. 여러 익스포터를 통해 필요한 매트릭 수집을 확장할 수 있다는게 큰 장점인 것 같으며 PULL 방식이라 부하에 따른 장애나 성능감소를 걱정하지 않아도 된다고 합니다. 그라나파를 통해 매트릭 데이터를 보기 쉽게 만들 수 있었으며 다양한 데이터 소스를 지원하는 만큼 여러 분야에서 활용하면 좋을 것 같습니다.

WinSxS 폴더, 정리 및 삭제 방법 4가지

디스크 정리 실행

첫 번째 방법은 윈도우에 기본으로 내장되어 있는 디스크 정리 프로그램을 활용합니다.

1. 윈도우 로고 + E 키를 눌러 파일 탐색기를 엽니다.
2. 내 PC를 클릭하고 윈도우가 설치된 드라이브(보통 C:)를 오른쪽 클릭한 다음 속성을 선택합니다.

3. 일반에서 디스크 정리를 클릭합니다. 디스크 정리 프로그램이 실행되면 윈도우 시스템에서 사용되는 디스크 공간을 계산할 때까지 기다립니다. 이 작업을 완료하는 데 몇 분 정도 걸릴 수 있습니다.

4. 시스템 파일 정리 버튼을 클릭합니다.

5. 기본으로 체크된 모든 항목의 체크를 푸세요.
6. Windows 업데이트 정리 항목을 체크합니다.

7. 확인 버튼을 클릭합니다.

버튼을 클릭하면 디스크 정리 도구가 WinSxS 폴더 내에서 발견된 모든 임시 파일을 삭제합니다.

저장소 센스로 WinSxS 폴더 크기를 줄이는 방법

저장소 센스 기능으로도 WinSxS 폴더를 정리할 수 있는데요. 아래에 소개한 방법대로 진행해보세요!

1. 윈도우 로고 + I(영문자 아이) 키를 눌러 설정을 엽니다.
2. 시스템을 클릭합니다.

3. 저장소를 클릭합니다.
4. 로컬 디스크 부분에서 임시 파일 항목을 클릭합니다. 임시 파일 항목이 보이지 않으면 더 많은 범주 표시를 클릭하여 찾아보세요.

5. 기본으로 선택된 항목의 체크를 모두 풉니다.
6. Windows 업데이트 정리 항목을 체크합니다.

7. 파일 제거 버튼을 클릭하세요.

이렇게 해서 WinSxS 폴더의 불필요한 파일을 한 번에 제거할 수 있습니다.

DISM 명령으로 WinSxS 크기를 줄이기

세 번째 내용은 DISM 명령을 사용하여 WinSxS 폴더의 크기를 줄이는 방법인데요. DISM(배포 이미지 서비스 및 관리)는 윈도우(Windows 이미지를 시스템에 연결하고 관리하기 위해 사용하는 명령어 입니다.

1. 시작 버튼을 클릭하고 명령 프롬프트를 입력한 다음, 검색 결과가 나타나면 마우스 오른쪽 버튼을 클릭하고 관리자 권한으로 실행을 선택합니다.

2. 아래 명령을 입력하고 엔터 키를 눌러 WinSxS 폴더의 크기를 줄입니다.
dism.exe /online /Cleanup-Image /StartComponentCleanup

3. 명령 실행이 완료되면 아래의 명령을 입력하고 엔터 키를 눌러 시스템 업데이트 이후 문제가 발생할 시를 대비하여 보관하고 있던 불필요한 예비 파일을 모두 제거합니다. 이 명령이 완료된 후에는 기존의 모든 서비스 팩 및 업데이트를 제거할 수 없습니다. 물론, 명령 실행 이후에 새롭게 설치할 서비스 팩 또는 업데이트의 제거는 문제 없이 가능합니다.

dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase

4. 컴퓨터를 다시 시작합니다. 이제 윈도우 탐색기를 열고 여유 공간이 어느 정도 확보됐는지 확인해보세요.

WinSxS 폴더의 파일을 직접 삭제하는 방법. 주의, 또 주의!

이번에는 최소 2년~4년 전에 다운로드된 오래된 업데이트 파일을 삭제하는 방법을 알아보겠습니다. 이 방법대로 진행하기 전에 시스템을 이미지 파일 형태로 따로 백업해 두거나 가상 머신이라면 스냅샷을 생성하시고요. 업무용 컴퓨터나 메인으로 사용하는 주 컴퓨터에는 이 방법을 적용하지 않는 것이 좋습니다. WinSxS에서 파일과 폴더를 삭제한 후 윈도우가 정상적으로 작동하는지 테스트 환경에서 확인하는 것이 좋습니다.

1. 윈도우 로고 + E 키를 눌러 윈도우 탐색기를 엽니다.
2. C:\Windows로 이동한 다음 WinSxS 폴더를 마우스 오른쪽 클릭하고 속성을 선택합니다.

3. 보안 탭을 클릭한 다음 고급 버튼을 클릭하여 고급 보안 설정 창을 엽니다.

4. ‘소유자: TrustedInstaller’의 오른쪽 옆에 위치한 변경 링크를 클릭합니다.

5. 윈도우에 로그인할 때 사용하는 관리자 그룹의 계정 아이디(MS 계정 사용 중이라면 이메일 주소)를 입력하고 이름 확인 버튼을 클릭한 다음 확인을 누릅니다.

6. 다시 확인 버튼을 클릭하여 고급 보안 설정 창을 닫습니다. 역시나 확인 버튼을 한 번 더 클릭하여 WinSxS 속성 창도 닫습니다.

7. WinSxS 폴더를 오른쪽 클릭한 다음 속성을 선택하여 다시 WinSxS 폴더의 속성 창을 엽니다.

8. 속성 창에서 편집 버튼을 클릭한 다음 사용 권한 창이 열리면 추가 버튼을 클릭합니다. 이제 윈도우에 로그인할 때 사용하는 관리자 그룹의 계정 아이디(MS 계정 사용 중이라면 이메일 주소)를 입력하고 이름 확인 버튼을 클릭한 다음 확인을 누릅니다.

9. 방금 전에 추가한 로그인 할 때 사용하는 계정을 선택하고 모든 권한 옆에 있는 허용 부분의 체크 박스를 체크합니다.
10. 시스템 폴더의 사용 권한 설정을 변경할지 묻는 창이 뜨면 를 클릭해주세요. 마지막으로 적용을 클릭한 다음 확인을 클릭합니다. 열려 있는 모든 창을 닫습니다.

11. 이제 오래된 업데이트 파일을 삭제합니다. 제 경우에는 2016년 ~ 2018년 사이에 다운로드된 모든 파일을 삭제하여 10GB 정도의 여유 공간을 확보했습니다.

윈도우 10의 다이어트를 응원하며

글에서 소개한 방법대로 진행하여 WinSxS 폴더의 크기와 용량을 줄일 수 있습니다. WinSxS 폴더에서 오래되거나 불필요한 파일을 삭제할 수도 있고요. 단, 향후 새롭게 나올 업데이트를 설치하다 보면 시간이 지날수록 폴더 크기가 다시 커지게 되는데요. 윈도우 10에 자체적으로 폴더 크기를 자동으로 줄이는 기능이 있다고는 하지만, 생각 보다 잘 작동하지 않는 듯한 인상을 줄 때가 많죠. 글에 나온 내용을 필요할 때마다 적용하시면 WinSxS 폴더 크기를 항상 최소 크기로 유지할 수 있습니다.

뚱뚱한 윈도우 10이 스스로 능숙하게 다이어트하는 날이 빨리 오기를 마음속으로 바라봅니다! 😁

 

프로세서 성능 및 전원 관리 고급 수정하는 방법

 

우선 코어 파킹을 알아보고 만지다가 사용하게된 기능이므로 정보와 자료에 관해서 링크도 올려봅니다.
(경험담입니다만, 스로틀링은 그냥 두시는게 좋아요. 절전 효과는 그저 그런데 퍼포먼스가 엄청나게 저하됩니다.)

http://tshoo.tistory.com/tag/%EC%9C%88%EB%8F%84%EC%9A%B07%20%EC%BD%94%EC%96%B4%ED%8C%8C%ED%82%B9

윈도우 전원 관리는 절전 – 균형 – 고성능으로 나뉘어져 있습니다.

셋 다 최소 프로세서 수치를 변경하면 프로세서의 최소 스피드 스탭 단계를 정할 수는 있습니다만,

점유율에 의해 클럭이 내려가고 올라가는 정도도 확연히 틀립니다.

특히 절전을 써보신 분들은 아시겠지만,

프로세서 설정은 균형과 차이가 없는데도 클럭이 안 올라가는 것을 느끼셨을 겁니다.

여기서 눈치 빠르신 분들은 바로 눈치채셨겠죠. ㅇ_ㅇ/

윈도우 7 프로세서 전원 옵션에는 클럭을 올리고 내리는 상한, 하한선이 존재하며 수정할 수도 있습니다.

특히 절전은 상관이 없는데, 고성능과 균형의 퍼포먼스 차가 심하죠.

그냥 고성능으로 쓰기에는

시작 – regedit로 레지스트리 에디트를 여신 다음에

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings

\54533251-82be-4824-96c1-47b60b740d00

위 경로로 이동해 주세요.

여기에 보이는 하위 값이 프로세서 전원관리와 관계가 있는 값입니다.

대부분 코어 파킹과 관련이 있습니다만, 다 설정해버리면 뭐가 뭔지도 모르겠고 토 나옵니다.

코어 파킹에 대해서는 위 링크를 참고해 주세요.

여기서는

06cadf0e-64ed-448a-8927-ce7bf90eb35d

12a0ab44-fe28-4fa9-b3bd-4b64f44960a6

4d2b0152-7d5c-498b-88e2-34345392a2c5

요 항목 들을 수정해주시면 됩니다.

우측에 보이는 Attributes를 0으로 설정해 주세요.

그리고 제어판 – 시스템 – 전원관리 – 고급옵션에 들어가셔서 프로세서 전원관리를 열어보시면

aab3a9ab7e439188bfca6121b9b0fdc9.jpg

프로세서 성능 증가 임계값

프로세서 성능 감소 임계값

프로세서 성능 시간 검사 간격

이렇게 세 항목이 생깁니다.

이걸 절전 – 균형 – 고성능 마다 확인해 보시면 값이 확연히 다르다는 것을 아실 수 있습니다.

(고성능이 15 ,균형이 30 ,절약 200,   최저값 1000이였네요.)

덧붙여 추가한 성능시간 검사간격은 맛폰의 SetCPU를 사용하셨던 분 들에겐 익숙한 항목일 겁니다.

말 그대로 클럭 전환을 얼마나 신속히/천천히 하는지를 결정하는 항목입니다.

줄이면 소비전력은 조금 증가하지만 클럭 변동이 그만큼 빨라지고,

내리면 소비전력도 조금 감소하고 그만큼 CPU의 반응이 둔해집니다.

이제 이것들을 원하시는 수치로 수정하시면 되는데…

원래 있던 프로필을 수정하시는 것 보단 새로 프로필을 만드셔서 수정하시는 것을 권장드립니다.

고성능 기반의 옵션을 생성하실 경우에

디폴트 설정이 최소 프로세서 상태 100%이므로 이걸 수정해주시지 않으면 말짱 꽝입니다.

Recommend : 10% / 5% / 1초 / 30%