CodeBlack

Context Switching 이란?

 - 병렬처리를 위한 Job Scheduling

 - Running 상태의 Task가 사용하던 Context를 메모리 특정 영역에 저장한 후 새로이 수행 될 Task의 Context를 TCB또     는 Stack에서 CPU의 레지스터 영역으로 복사하여 새로운 Task가 수행되도록 하는 일련의 작업

 - LIFO, FIFO, RR 등..

 - Context는 CPU가 사용하는 레지스터들의 값

멀티프로세스 환경에서 CPU가 어떤 하나의 프로세스를 실행하고 있는 상태에서 인터럽트 요청에 의해 다음 우선 순위의 프로세스가 실행되어야 할 때 기존의 프로세스의 상태 또는 레지스터 값(Context)을 저장하고 CPU가 다음 프로세스를 수행하도록 새로운 프로세스의 상태 또는 레지스터 값(Context)를 교체하는 작업을 Context Switch(Context Switching)라고 한다.

Context는 무엇인가?

사용자와 다른 사용자, 사용자와 시스템 또는 디바이스간의 상호작용에 영향을 미치는 사람, 장소, 개체등의 현재 상황(상태)을 규정하는 정보들을 말한다.

android나 servlet등에서도 context가 있지만 OS에서 Context는 CPU가 해당 프로세스를 실행하기 위한 해당 프로세스의 정보들이다.

이 Context는 프로세스의 PCB(Process Control Block)에 저장된다.

그래서 Context Switching 때 PCB의 정보를 읽어(적재) CPU가 전에 프로세스가 일을 하던거에 이어서 수행이 가능한 것이다.

PCB의 저장정보

- 프로세스 상태 : 생성, 준비, 수행, 대기, 중지

- 프로그램 카운터 : 프로세스가 다음에 실행할 명령어 주소

- 레지스터 : 누산기, 스택, 색인 레지스터

- 프로세스 번호

* 참고로 Context Switching 때 해당 CPU는 아무런 일을 하지 못한다. 따라서 컨텍스트 스위칭이 잦아지면 오히려 오버헤드가 발생해 효율(성능)이 떨어진다.

Context가 뭔지 알았고 멀티프로세싱하기 위해 CPU를 나눠서 사용하기 위해 Context를 교체하는 것이 Context Switching임을 알았다. 그리고 PCB에 Context가 저장됨도 알았다.

남은 것은 인터럽트 요청이 뭐고 어떤 종류가 있는지 + 서브로 우선 순위에 대한 이야기다.

Context Switching - 인터럽트(Interrupt)

인터럽트는 CPU가 프로그램을 실행하고 있을 때 실행중인 프로그램 밖에서 예외 상황이 발생하여 처리가 필요한 경우 CPU에게 알려 예외 상황을 처리할 수 있도록 하는 것을 말한다.

어떤 인터럽트 요청이 와야 Context Switching이 일어날까?

1. I/O request (입출력 요청할 때)

2. time slice expired (CPU 사용시간이 만료 되었을 때)

3. fork a child (자식 프로세스를 만들 때)

4. wait for an interrupt (인터럽트 처리를 기다릴 때)

출처: https://jeong-pro.tistory.com/93 [기본기를 쌓는 정아마추어 코딩블로그]

매월 마지막날 출력 쿼리

DECLARE @v_YMD CHAR(8)
DECLARE @v_tmp CHAR(8)

SET @v_YMD = '20180201'

WHILE @v_YMD <= '20190601' BEGIN
set @v_tmp = CONVERT(CHAR(8),Dateadd(day, -1, @v_YMD),112)
print @v_tmp
SET @v_YMD = CONVERT(Char(8), DateAdd(month, 1, @v_YMD), 112)
END

C/C++ 에서 소켓통신을 하기 위해 패킷을 구조체로 정의한다.

일반적으로 아래와 같이 선언하여 사용한다.

struct _Socket
{
    int Size;
    char text[50];
} Socket;

해당 구조체로 패킷을 정의하면 패킷의 크기는 어떻게 될까?

int 자료형은 4바이트, char 자료형은 1바이트지만 배열로 선언하여 50 바이트가 된다.

두 값을 더하면 54가 나와야 하지만 sizeof(Socket); 결과는 56바이트가 된다.

왜 이런 결과가 나오는 것일까?

먼저 정답은 패딩비트에 의해 56바이트가 나오게 된다.

대부분의 컴파일러는 CPU가 접근하기 쉬운 위치에 필드를 배치한다. 그러다보니 중간에 빈 공간이 들어가는데 위 예시에서는 2바이트가 추가로 들어가게 된 것이다.

이렇게 추가된 2바이트를 패딩 비트라고 한다.

32bit CPU는 메모리에서 값을 읽어올 때 한번에 4byte(32bit)를 읽어 오고 64bit CPU는 한번에 8byte(64bit)를 읽어온다

그러면 이러한 상황을 방지하기 위한 방법이 뭐가 있는지 찾아보니 아래와 같이 구조체를 선언하면 패딩비트가 생성되지 않는다.

#pragma pack(1)
struct _Socket
{
  int Size;
  char text[50];
} Socket;
#pragma pack(pop)

위와 같이 선언한 구조체의 크기를 출력해보면 sizeof(Socket)의 결과가 54가 나오게 된다.

#pragma pack(1)이 뜻하는 바는 구조체에서 가장 큰 바이트로 변수의 크기가 설정되는데 해당 설정을 1바이트로 변경한다는 뜻이다. #pragma pack(pop)을 통해 원래 정렬된 값(4바이트)으로 돌아가게 된다.

#pragma pack(1)과 #pragma pack(pop) 사이에 선언된 모든 구조체에 해당 설정이 적용 된다.

#참고 사이트 : https://pangate.com/19

SELECT 문 사용할 때 with(nolock)를 사용하는 경우가 종종 있다.

with(nolock)을 사용하는 이유는 트랜잭션 격리성 때문인데 해당 내용에 대해 정리 글

Transaction Isolation Level(트랜잭션 격리 수준)이란?

  - A 트랜잭션이 실행되고 있을 때 다른 B 트랜잭션의 접근 권한에 대한 수준을 이야기 합니다.

  - 트랜잭션 격리 수준 단계가 높아질수록 격리 수준이 높아지며 데이터 일관성은 높아지지만 동시성은 저하 됩니다.

Transaction Isolation 관련 문제점

  - Dirty Read : 커밋되지 않은 데이터를 읽어 해당 트랜잭션이 롤백 되면 오류 데이터를 읽을 수 있는 문제점

  - Non-Repeatable Read : 한 트랜잭션이 반복하여 Read 중일 때 다른 트랜잭션이 접근하여 데이터를 변경하여 커밋하여도 커밋된 결과가 반영 되지 않는 문제점

  - Phantom Read : 한 트랜잭션 안에서 일정 범위 레코드를 두번 이상 읽을 때, 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타나는 문제점

Transaction Isolation Level 단계

  1. Read Uncommitted

        - 트랜잭션 실행 중 다른 트랜잭션이 접근 가능(트랜잭션이 격리되지 않음)

        - A트랜잭션이 데이터를 변경 중 일 때 B트랜잭션이 접근하여 커밋되기전 변경된 데이터를 읽을 수 있음.

        - 만약 커밋되지 않고 A트랜잭션이 롤백되면 B트랜잭션의 결과값은 잘못된 데이터가 됨(Dirty Read 발생)

        - Non-Repeatable Read 발생 가능

        - Phantom Read 발생 가능

  2.  Read Committed

        - 커밋되기 전 바뀐 데이터를 읽을 수 없음.(Dirty Read 발생 X)

        - Non-Repeatable Read 발생 가능

        - Phantom Read 발생 가능

  3.  Repeatable Read

        - 항상 한 트랜잭션의 일관성 있는 데이터 읽기를 보장(Dirty Read, Non-Repeatable Read 발생 X)

        - A트랜잭션 실행 중 B 트랜잭션에서 Insert가 발생 후 동일 조건의 Select문의 A트랜잭션과 B트랜잭션의 결과가 달라짐(Phantom Read 발생)

        - A트랜잭션이 실행 중일 때 다른 트랜잭션이 DB의 내용을 변경해도 서로 영향을 미치지 않는다.

  4.  Serializable

        - 가장 높은 격리 수준

        - 트랜잭션이 완료될 때까지 Select 문장이 사용하는 모든 데이터에 Shared Lock이 걸리므로 다른 트랜잭션이 접근 불가

        - Dirty Read, Non-Repeatable Read, Phantom Read 모두 발생 안함.

위 내용을 아래 표로 정리하였습니다.

* DB별 Default isolation

격리 수준과 with(nolock) 힌트의 관계

    -    With(nolock)힌트는 격리성 제한이 걸린 DataBase의 Read Uncommitted를 허용한다.(격리성 관련 문제점 발생)

    -    격리성 제약조건 있는 DB에 실시간으로 데이터를 확인할 때 주로 사용한다.

    -    데드락이나 교착상태가 발생하지 않는다.

    -     Rollback이 될 수 있는 데이터까지 읽기 때문에 데이터 일관성은 저하된다.

*with(nolock)과 유사한 with(readuncommitted)힌트도 있습니다~!

*본문에 사용된 이미지 출처 : https://lng1982.tistory.com/287

기계 학습(Machine learning)을 위해 라이브러리 및 계산하기 편한 언어는 Octave, Matlab, Python, Numpy, R 등이 있습니다. 그 중 Octave는 오픈소스이며 무료로 사용가능하고 Python, Numpy, R 보다 생산성이 뛰어나다는 평가를 받고 있는 언어입니다.

많은 사람들이 Octave를 이용해 기계학습 프로토 모델을 생성하여 테스트를 진행합니다.

* Octave 다운로드 주소 : https://www.gnu.org/software/octave/download.html

Octave로 프로토 타입을 만들어 본 후 해당 알고리즘을 C++, Java로 새로 코딩하는 것을 추천합니다.

SubnetMask란?

• NetMask를 이용하여 네트워크를 나누는걸 Subnetting이라 하며 네트워크를 합치는게 Supernetting이라 한다.
• Subnet Mask는 IP 주소 체계의 네트워크ID와 호스트ID를 넷마스크를 통해 변경하여 네트워크 영역을 분리하는 것이다.
• Subnet Mask를 이용하여 호스트ID를 네트워크ID로 변환(Subnetting) 가능하고, 반대의 경우(Supernetting) 역시 가능하다.

• Subnet Mask는 IP주소와 동일하게 32bit의 2진수로 되어 있다. /25 숫자는 연속 1bit의 개수를 의미합니다.
• 1과 0은 연속적이야 하며 중간에 섞일 수 없습니다. Ex) 1111111.11011111.11111111.00000000 불가

• /25 는 Subnet Mask가 25bit라는 의미로 255.255.255.128이라는 의미를 가진다. 그러면 호스트ID에 할당할수 있는 범위가 [0~127], [128~255]가 되며 네트워크가 2개로 나눠지게 된다
• /26 은 255.255.255.196가 되며 할당받을 수 있는 호스트는 [0~63], [64~127], [128~191], [192~255]가 되며 네트워크가 4개로 나눠지게 된다.
• 따라서 하나의 bit를 가져올 때 마다 네트워크 크기는 2배로 증가하며 할당할 수 있는 호스트 수는 2로 나눠지게 된다.

* 참고 사이트 : http://korean-daeddo.blogspot.com/2016/01/blog-post_26.html

기계 학습 알고리즘 (Machine Learning Algorithm)

기계 학습 알고리즘으로 크게 두가지로 분류 되지만 두개의 특성을 합친 학습법을 포함해 3가지로 나눌 수 있다.

기계 학습은 experience E 와 respect to some task T 그리고 some performance measure P로 학습 및 성능 측정을 한다.

E : 학습할 데이터

T : 실제 데이터

P : E로 학습한 모델을 T로 측정한 성능

1. Supervised Learning (지도 학습)

 - 정답인 데이터를 학습하여 입력값에 대한 정답 여부를 판별

2. Unsupervised Learning (비지도 학습)

 - 정답이 없는 데이터를 학습하여 입력값을 특정 그룹으로 분류

3. Semisupervised Learning (반지도 학습)

 - 정답이 있는 데이터와 없는 데이터를 같이 학습하여 입력값을 처리

sklearn 라이브러리에 있는 Regression 모델

1. Lasso Regression(Least Absolute Shrinkage and Selection Operator)
2. Elastic Net Regression
3. Kernel Ridge Regression
4. Gradient Boosting Regression

Machine Learning(ML) 이란?

알파고와 이세돌의 바둑 대결로 알파고에 관심이 증가함에 따라 알파고에 접목된 Machine Learning 또한 관심도가 높아졌다.

현재 AI 분야에서 주로 사용되는 분야로 한국어로는 기계 학습이라고 한다.

Machine learning(기계 학습)이 주목 받는 이유는 단 하나다.

AI분야에서 음성인식, 자연어 처리, 영상 처리 등 전반적인 부분에서 처리 및 인식 성능이 타 기술보다 높게 측정되었기 때문이다.

알파고가 보여준 엄청난 바둑 경기력은 바로 이 Machine Learning에서 비롯 되었다.

수천 수만개의 바둑 기보를 통해 학습한 기계 알파고를 인간 이세돌이 이기기는 쉽지 않았고 사람들은 알파고의 능력에 감탄하고 열광하면서

AI에 대한 기대가 커지게 된 것이다.

그럼 이 Machine Learning으로 할 수 있는 일이 무엇이 있을까?

충분한 학습에 필요한 데이터만 있으면 그 데이터를 기반으로 학습 된 모델을 통해 앞으로 일어날 일을 예측하고 분석할 수 있으며 분류 또한 가능해 진다.

예로 들어 과거 기상 데이터를 학습하여 내일 또는 미래의 날씨를 예측하거나 스팸 메일 분류 같은 일까지 정확하게 처리할 수 있다.

이처럼 충분한 데이터 셋만 있다면 어느 분야에서도 사용이 가능한 Machine Learning은 앞으로도 대체 가능한 방법이 나오지 않는다면 활발하게 연구 될 것이고 AI의 시대가 점점 더 가까워 지고 있다는 것을 알 수 있다.

B-TREE 구조란?

- B-Tree라고 하면 사람들은 이진 트리(Binary Tree)라고 생각하는 사람들이 많다. 하지만 SQL SERVER에서 B-Tree는 이진 트리가 아니다!

- Root node, Intermediate Level, Leaf nodes/data pages의 총 3가지 단계로 구성된다.

- 각 노드의 키 값은 하위 노드들을 나누는 값이 되어야 한다

- 각 노드는 정렬된 상태

- SQL Server에서는 B-Tree와 Linked list를 합친 B+Tree를 사용

참고 사이트 : https://docs.microsoft.com/ko-kr/sql/relational-databases/sql-server-index-design-guide?view=sql-server-2017

실행계획이란?

- 옵티마이저가 쿼리의 최적 실행 방법을 결정하여 나타내는 쿼리의 동작 계획

- 작성된 쿼리문의 성능을 파악할 수 있는 DBMS가 지원해주는 정보

- 작성된 쿼리가 어떤 식으로 동작하는지 내용을 파악할 수 있다

실행계획의 중요성

- 자신이 작성한 쿼리의 실행계획을 제대로 파악하지 못한채 쿼리를 작성하게 되면 데이터가 많아졌을 때 성능 저하가 발생!

MS-SQL에서 실행계획 보는 방법

- 실행계획을 확인할 쿼리를 드래그 한 후 Ctrl+L 을 누르면 선택된 영역 쿼리의 실행계획을 볼 수 있다

실행계획에 나오는 용어 정리

Table Scan    -  테이블 내 전체 데이터를 모두 검색(full scan)

Table Seek    -  인덱스를 사용하여 검색

Index Scan    -  인덱스를 검색하여 데이터를 검색(range scan)

Index Seek    -  인덱스를 사용하여 검색

Hash join      -  두 테이블간에 인덱스가 없고 Equal Join을 사용할 경우

NS Lookup    -  

빨간색으로 표시된 부분이 실행계획에 많이 있으면 데이터가 많아짐에 따라 성능 저하의 위험이 있다는 뜻!

실행계획을 볼 때 유의 할 점!

- 실행 계획에 Table Scan / Index Scan 이 있으면 전체 검색을 하기 때문에 Table Seek / Index Seek으로 바꿔주는게 일반적으로 좋다

- Scan을 Seek로 바꿀려면 Where에 사용하는 컬럼에 Index를 걸어주면 해결된다.(* 단 Index에 대한 이해가 필수!)

- 데이터 검색할 Row수가 적으면 쿼리 옵티마이져가 자동적으로 Scan으로 검색하니 참고!

*앞으로 실행계획을 통해 자신이 만든 쿼리와 SP의 성능을 확인하고 개선하는 습관을 가지는 것이 좋다!!!!*

*SQL Server 2014 기준으로 작성한 글입니다.