아니 이게 왜 되지

JPA 영속성 컨텍스트, 엔티티 생명주기, 변경 감지

이게되네 — Mon, 11 Dec 2023 14:40:52 +0900

영속성 컨텍스트(persistence context)

쉽게 말하면 엔티티를 영구 저장하는 환경이다.

즉, 엔티티 메니저로 엔티티를 저장하거나 조회하면 엔티티메니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.

영속성 컨텍스트는 엔티티 메니저 당 하나씩 할당한다

엔티티의 생명주기

엔티티는 4가지 상태가 존재한다.

- 비영속 : 영속성 컨텍스트와 전혀 관계가 없는 상태

순수한 객체 상태이며, 아직 저장되지 않음. DB와 전혀 관련 없는 객체

- 영속 : 영속성 컨텍스트에 저장된 상태

- 준영속 : 영속성 컨텍스트에 저장되었다가 분리된 상태

영속성 컨텍스트가 관리하지 않으므로 거의 비영속 상태에 가깝고, 그렇기에 지연 로딩을 할 수 없다.

하지만, 식별자 값을 가지고 있다는 특징이 있다.

- 삭제 : 삭제된 상태, 실제로 DB에서 삭제한 상태.

영속성 컨텍스트는 엔티티를 식별자 값으로 구분한다.

즉, 영속 상태는 식별자 값이 반드시 있어야 한다.

영속성 컨텍스트에 있다가. 트랜젝션을 커밋하는 순간 DB에 반영하는데. 이것을 플러시(flush) 라고 한다.

물론, entity manager에서 flush 함수를 호출해도 DB에 반영한다.

영속성 컨텍스트 내부에는 캐시를 가지고 있는데, 이것을 1차 캐시라고 한다.

entity manager에서 find를 호출하면 먼저 1차 캐시에서 엔티티를 찾고, 만약 엔티티가 1차 캐시에 없으면 DB에서 조회한다.

find를 여러번 호출해도 연속성 컨텍스트는 1차케시에 있는 같은 엔티티 인스턴스를 반환한다.

이를 통해 영속성 컨텍스트는 성능상 이점과 엔티티 동일성을 보장한다.

변경 감지

JPA에서는 객체 수정 후 별도 update 쿼리를 날리지 않아도, 변경을 감지하여 자동으로 DB에 반영한다.

어떻게 감지할 수 있을까?

JPA에서는 엔티티를 영속성 컨텍스트에서 보관할 때, 최초 상태를 복사하여 저장해두는데 이것을 스냅샷이라고 한다.

JPA에서는 플러시 시점에 스냅샷과 엔티티를 비교해서 변경된 엔티티를 찾는다.

즉, 변경 감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용한다.

참고로 jpa에서 update 쿼리 작성 시 엔티티의 모든 필드를 업데이트한다.

플러시(flush)

영속성 컨텍스트의 변경 내용은 DB에 반영한다.

변경 감지가 동작해서 영속성 컨텍스트에 있는 모든 엔티티와 스냅샷을 비교해서 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 등록하고,

쓰기 지연 SQL 저장소에서 쿼리를 DB에 전송한다.

em.flush()를 직접 호출하거나, 트랜젝션 커밋 시, JPQL 쿼리 실행시 플러시가 자동으로 호출된다.

JPA Entity Manager

이게되네 — Mon, 11 Dec 2023 13:45:44 +0900

엔티티 메니저

이름 그대로 엔티티를 관리하는 관리자다.

엔티티를 저장, 수정, 삭제, 조회 등 엔티티와 관련한 모든 일을 처리한다.

JPA 대부분 기능은 엔티티 메니저에서 제공한다.

엔티티 메니저는 DB 커넥션과 밀접한 관계가 있으므로 스레드 간 공유하거나 재사용을 하면 안 된다.

엔티티 메니저는 엔티티 메니저 팩토리를 통해 생성된다.

엔티티 메니저 팩토리

이름 그대로 엔티티 메니저를 만드는 공장이다.

데이터 커넥션 풀도 생성할 정도로 생성 비용이 아주 크다.

즉, 엔티티 메니저 팩토리는 애플리케이션 전체에서 딱 한 번만 생성하고 공유해서 사용해야 한다.

Mysql 아키텍처

이게되네 — Sun, 26 Nov 2023 13:01:25 +0900

Mysql은 크게 Mysql 엔진과 스토리지 엔진으로 구분한다.

사람으로 따지자면, Mysql 엔진은 머리 역할,

스토리지 엔진은 손발 역할을 담당한다.

MYSQL 엔진

크게 커넥션 헨들러, 파서, 전처리기, 옵티마이저 등으로 구성되어 있다.

커넥션 헨틀러는 클라이언트로부터의 접속 및 쿼리 요청을 처리하고,

옵티마이저는 쿼리의 최적화된 실행을 진행한다.

스토리지 엔진

디스크 스토리지에 저장하거나, 데이터를 읽어오는 역할을 한다.

MYSQL 엔진을 하나 두고, 스토리지 엔진을 여러 개 둘 수도 있다.

스토리지 엔진은 성능 향상을 위해 키 캐시나 버퍼 풀 같은 기능을 내장하고 있다.

Mysql 스래딩 구조

Mysql 서버는 프로세스 기반이 아닌, 스레드 기반으로 동작한다.

크게 포그라운드 스레드와 백그라운드 스레드로 구분한다.

포그라운드 스레드 (클라이언트 스레드)

포그라운드 스레드는 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다.

즉, 클라이언트가 Mysql 서버에 접속하면 스레드를 생성해서 그 클라이언트에게 할당한다.

작업을 마치고 커넥션을 종료하면 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시로 돌아간다.

포그라운드 스레드는 버퍼나 캐시에서 데이터를 가지고 온다. 만약 없으면 백그라운드 스레드가 처리한다(InnoDB 기준)

백그라운드 스레드

InnoDB 기준으로 다음 작업을 백그라운드로 처리한다.

- insert buffer 병합

- 로그를 디스크로 기록

- 버퍼 풀의 데이터를 디스크에 기록

- 데이터를 버퍼로 읽어옴

- 잠금이나 데드락을 모니터링

MSQL 메모리 구조

Mysql에서 메모리는 크게 글로벌 메모리 영역과 로컬 메모리 영역으로 구분한다.

해당 영역은 MYSQL 서버 내에서 많은 스레드가 공유해서 사용하는 공간이지 여부에 따라 구분한다.

글로벌 메모리 영역

글로벌 메모리 영역은 Mysql 서버가 시작되면서 운영체제로부터 할당한다.

일반적으로 클라이언트 스레드 수와 무관하게 하나의 메모리 공간만 할당된다.

모든 스레드에 의해 공유되고, 다음과 같은 영역이 있다.

- 테이블 캐시

- 버퍼 풀

- 어댑티브 해시 인덱스

- redo log buffer

로컬 메모리 영역

mysl 서버 상에 존재하는 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역이다.

클라이언트가 연결을 요청하면 스레드가 하나씩 할당되는데, 이 때 해당 스레드가 사용하는 메모리 영역이다.

즉, 한 클라이언트 스레드 당 하나의 영역을 할당한다.

세션 메모리 영역이라고도 한다.

로컬 메모리는 각 스레드별로 독립적으로 할당되며, 스레드 간 공유가 되지 않는다.

다음과 같은 영역이 있다.

- 정렬 버퍼

- 조인 버퍼

- 바이너리 로그 캐시

- 네트워크 버퍼

컴포넌트

MYSQL 8.0 부터 지원한다. 기존에 플러그인 아키텍처를 대체한다.

플러그인은 오직 mysql 서버와 인터페이스 할 수 있고, 플러그인 간 통신할 수 없었으며,

mysql 서버 변수와 함수를 직접 호출하기 때문에 캡슐화가 안됐으며

상호 의존 관계를 설정할 수 없어 초기화가 어려웠는데,

컴포넌트는 이 모든 것을 대체했다.

컴포넌트를 통해 msql을 유연하게 확장할 수 있다.

쿼리 실행 구조

쿼리 실행 과정은 위 그림과 같다.

쿼리 파서

사용자 요청으로 들어온 쿼리를 토큰(mysql이 인식하는 최소 단위)로 분리해 트리 구조로 만든다.

기본 문법 오류는 여기서 거른다.

전처리기

파서 과정에서 만들어진 문장에 구조적인 문제점을 확인한다. 테이블-컬럼 이름, 내장함수, 접근 권한 등을 확인한다.

옵티마이저

사용자 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리하는 방안을 결정한다.

실행엔진

위에서 만들어진 실행 계획을 기반으로 각 헨들러에 요청해서 결과를 받아오는 역할을 수행한다.

핸들러

실행 엔진에 요청에 따라 데이터를 디스크로 저장하고 디스크로 읽어오는 역할을 담당한다.

InnoDB 스토리지 엔진 아키텍처

innodb 엔진은 mysql 스토리지 엔진 가운데 가장 많이쓴다.

스토리지 엔진 중 거의 유일하게 레코드 기반 잠금을 제공하여 동시성 처리가 가능하고 안정적이기 때문이다.

innodb 엔진은 아래와 같은 특징이 있다.

PK에 의한 클러스터링

innoDB 엔진은 기본적으로 PK를 기준으로 클러스터링하여 저장한다.

즉, PK값의 순서대로 디스크에 저장한다.

따라서 PK를 이용한 range scan은 상당히 빨리 처리할 수 있다.

외래키 지원

물론 외래키는 DB 서버 운영의 불편함 때문에 생성하지 않는 경우가 자주 있다.

허나, 개발 환경에서는 좋은 가이드 역할을 할 수 있다.

다만, 외래키는 부모테이블과 자식 테이블에 인덱스 생성이 필요하고,

변경 시에 부모 테이블이나 자식 테이블에서 데이터 체크 작업이 필요하여 여러 테이블로 락이 전파되어 데드락이 발생할 수도 있다.

MVCC(Multi Vrsion Concurrency Control)

하나의 레코드에 대해 여러 버전이 동시에 관리한다.

잠금을 사용하지 않은 일관된 읽기를 제공한다.

즉, 잠금을 걸지 않고 읽기 작업을 수행한다. 다른 트랙젝션의 잠금을 기다리지도 않는다.

innoDB는 undo log를 이용하여 이 기능을 구현한다.

자동 데드락 감지

데드락 감지 스레드가 주기적으로 잠금 대기 그래프를 검사해 데드락에 걸린 트랙젝션을 강제종료한다.

버퍼 풀

버퍼풀은 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해두는 공간이다.

쓰기 작업을 지연하여 일괄 처리를 하게 해준다.

버퍼풀의 구조는 다음과 같다

LRU(Least Recently Used) 리스트

LRU 리스트는 MRU(Most Recently Used)랑 결합되어있는데, 최근 사용한 데이터와, 가장 많이 사용한 데이터 리스트와 연관되어 있다.

과정은 다음과 같다

Flush 리스트

디스크로 동기화되지 않은 데이터를 가진 데이터 페이지(더티 페이지)의 변경 시점 기준 페이지 목록을 관리한다.

한 번 데이터 변경이 가해진 데이터 페이지는 플러시 리스트에 관리된다.

그러고 나서 특정 시점이 되면 디스크로 기록한다.

데이터가 변경되면 innoDB는 변경 내용일 REDO 로그에 기록하고 버퍼 풀의 데이터 페이지에도 변경 내용을 반영한다.

Free 리스트

버퍼 풀에서 비어있는 페이지 목록, 사용자가 새롭게 읽어와야 하는 경우 사용

Index 인덱스

이게되네 — Sun, 26 Nov 2023 12:13:31 +0900

인덱스란?

테이블의 검색 속도를 향상시키는 자료구조이다.

쉽게 생각해서 책의 색인과 같다

처음부터 완전 탐색하면 힘든데, abc순으로 정렬하면 빠르게 찾을 수 있지 않은가?

ldex를 통해 조회 속도를 올릴 수 있으나, insert, delete,update 속도는 느려진다.

그리고 인덱스를 따로 관리하기 위한 추가 작업이 필요하고, 잘못 사용할 결우 오히려 성능이 악화된다.

인덱스는 그럼 언제 사용하는 것이 좋을까?

- 규모가 큰 테이블

- insert, update, delete가 자주 발생하지 않는 컬럼

- join, where, order by가 자주 사용되는 컬럼

- 데이터 중복도가 낮은 컬럼

그럼 Index는 어떻게 구현하는가? 대표적인 방식이 헤시 테이블과 B+ Tree가 있다.

해시 테이블은 Key-Value로 구성되어 있고, 고유 키 별로 인덱스를 생성해서 가져오는 방식이다.

시간복잡도가 O(1)이다, 즉 메우 빠르다

값이 조금이라도 달라지면 아예 다른 해시값을 생성하는데, 이러한 이유로 부등호연산(<,>) 에는 적합하지 않다.

그리키의 일부만 조회하는 부분에서도 인덱스 혜택을 못받기 때문에 보통 B+Tree가 일반적으로 사용된다

B+Tree

자식 노드가 2개 이상인 B-tree를 개선 시킨 구조이다.

BTree는 모든 노드에 데이터를 저장했다면, B+ Tree는 아래와 같은 특징을 가진다

- 리프 노드만 인덱스와 함께 데이터를 가지고 있음

- 나머지 노드는 인덱스만 가지고 있음

- 리프 노드 간 LinkedList로 연결 -> 순차 검색에 용이해 짐

- 데이터 노드 크기는 인덱스 노드와 달라도 됨.

bTree보다 최적화 되었으나, 데이터 탐색을 위해서는 무조건 리프노드로 가야한다는 단점이 있다.

그럼 언제 인덱스를 사용하지 않을까?(=인덱스 풀 스캔을 진행할까?)

- where절이나 on 절에서 인덱스를 이용할 수 있는 적절한 조건이 없는 경우

- 테이블 레코드 건수가 너무 적어서 인덱스를 통해 읽는 거소다 풀 테이블 스캔을 하는 것이 더 빠른 경우

(일반적으로 테이블이 1개의 페이지 만으로 구성되는 경우)

- 인덱스 레인지 스캔을 쓰더라도, 일치되는 레코드 건수가 너무 많은 경우

참조 :

1. Real Mysql 8.0

2. https://mangkyu.tistory.com/96

[Database] 인덱스(index)란?

1. 인덱스(Index)란? [ 인덱스(index)란? ] 인덱스란 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조이다. 만약 우리가 책에서 원하는 내

mangkyu.tistory.com

https://mangkyu.tistory.com/286

[MySQL] B-Tree로 인덱스(Index)에 대해 쉽고 완벽하게 이해하기

인덱스를 저장하는 방식(또는 알고리즘)에 따라 B-Tree 인덱스, Hash 인덱스, Fractal 인덱스 등으로 나눌 수 있습니다. 일반적으로 B-Tree 구조가 사용되기 때문에 B-Tree 인덱스를 통해 인덱스의 동작

mangkyu.tistory.com

DB Lock

이게되네 — Sat, 25 Nov 2023 23:20:41 +0900

Lock

같은 데이터를 동시에 접근하는 상황을 방지하기 위해 접근 한 곳, 혹은 허용되는 수만 접근 되도록 설정하는 것.

데이터의 무결성과 일관성을 지키기 위해 사용

Lock 종류는 다음과 같다

Shared Lock - 공유락

데이터를 변경하지 않는 읽기 명령에 주어진다.

여러 사용자가 동시에 데이터를 읽어도 데이터 일관성에는 아무런 영향을 주지 않는다.

따라서, 공유 락 끼리는 동시 접근이 가능하다.

Exclusive Lock - 베타 락

데이터에 변경을 가하는 명령에 주어지는 락이다. Write Lock으로도 불린다.

다른 세션이 해당 자원에 접근(Select, Insert, update, delete...)를 막는다.

베타 락은 트랜젝션 동안 유지된다.

Update Lock - 업데이트 락

배타 락을 걸기 전 데드락을 방지하기 위해 사용되는 락이다.

일반적으로 Update쿼리의 where절이 실행되는 과정에서 적용된다.

가끔 읽기 쿼리 이후 업데이트 쿼리를 적용하는 경우 컨비전 데드락(공유 잠금에서 단독 잠금으로 변경 시 발생)하는데,

이를 막기위해 일부 select 쿼리에서도 업데이트 락을 걸기도 한다.

Intent Lock - 내재 락

사용자가 요청한 범위에 대한 락을 걸 수 있는지 여부를 빠르게 파악하기 위해 사용

락을 거는 시점에 상위 객체들(페이지, 테이블) 에 대한 내재 락을 걸어 다른 사용자가 더 큰 범위 자원에 대해 락을 걸 수 있는지 여부를 빠르게 파악할 수 있도록 한다.

따라서 락 생성 시 상위 객체에 대한 내재락을 생성한다. 모든 row에 락을 생성하는 대신, 더 상위 객체 테이블에만 락을 걸어 메모리 사용을 최적화한다. 이를 Lock Escalation이라 한다

DB isolation level (격리수준)

이게되네 — Sat, 25 Nov 2023 23:07:01 +0900

격리수준이란(isolation level) 트랜젝션 간 고립 수준을 말한다.

즉, 다른 트랜젝션이 변경한 데이터에 대한 접근 강도를 의미한다.

* dirty read : 다른 트렌젝션에서 아직 commit 되지 않은 데이터를 읽는 것

* non-repeatable read : 다른 트랙젝션에서 데이터 수정/삭제 시 커밋한 데이터를 읽을 수 있는 것. 한 트랜젝션에서 같은 쿼리로 2번 이상 조회했을 때 그 결과가 상이한 상황

* phantom read : 데이터 삽입 시 발생, 한 트랜젝션에서 같은 쿼리를 2번 이상 조회했을 때 없던 결과를 조회하는 상황, 다른 트랜젝션이 commit한 데이터가 있더라도, 자신의 트랜젝션에서 읽었던 내용만 사용

격리수준을 좀 더 자세히 알아보자

LEVEL 0 - Read Uncommited

커밋이나 롤백 상관 없이 다른 트랜젝션에서 조회 가능한 것.

정합성 문제가 많음. 그래서 격리 수준으로 인정 안해용

Select를 실행하는 동한 해당 data에 shared lock이 걸리지 않아용

그래서 dirty read가 발생한답니당

LEVEL 1 - Read Commited

한 트랜잭션 변경 내용이 commit 되어야만 다른 트랜젝션에서 조회가 가능함.

대부분 RDB들이 기본적으로 사용하는 격리 수준이다.

select문 실행 시 shared Lock이 걸린다.

조회 시에는 실제 테이블 값이 아니라 Undo 영역에 백업된 레코드 값을 가져온다.

하지만, 하나의 트랜젝션에서 select를 다수 실행을 해도 항상 같은 결과를 가져와야하는데, 그러지는 못해용

즉, non-repeatable read와 phantom read가 발생한답니당

LEVEL 2 - Repeatable Read

트랜젝션 시작하기 전에 커밋한 내용만 조회 가능하다.

트랜젝션이 완료될 때까지 Select문이 사용하는 모든 데이터에 shared lack이 걸린다.

그래서 트랜젝션 범위 내에서 데이터 내용이 항상 동일함을 보장한다.

하지만, 일관성 보장을 위해, 트랜젝션 실행시간이 길어질수록 멀티 버전을 관리해야한다.

또한, phantom read가 발생할 수 있다.

Level 3 - Serializable

가장 엄격한 격리 수준.

트랜젝션이 동시에 일어나지 않고 순차적으로 실행된다.

당연히 동시 처리를 못하니 겁나 느리다

참조 :

real mysql8.0

https://akasai.space/db/about_isolation/

Isolation Level이란? | devlog.akasai

격리 수준(isolation level)이란? 격리수준(isolation level…

akasai.space

페이지 대치 알고리즘

이게되네 — Sat, 25 Nov 2023 22:38:58 +0900

가상 메모리의 성능은 얼마나 페이지폴트를 줄이냐가 관건이다.

물론 프레임 수가 증가하면 페이지폴트도 줄어든다.

한번 대치 알고리즘에 대해 알아보자

선입선출 대치 알고리즘

각 페이지가 메모리 안으로 들어간 시간을 이용하여 가장 오래된 페이지부터 대치하는 방식이다.

선입선출이 간단한 구조를 가지고 있으나, 성능이 항상 좋은 것은 아니다

이렇게 프레임이 증가함에도 불구하고 페이지 폴트 수가 증가한다. 이러한 현상을 벨레디의 변이라고 한다.

최적 페이지 대치 알고리즘

앞으로 가장 오랫동안 사용하지 않는 페이지를 대치하는 알고리즘이다. 당연히 모든 알고리즘 중에 페이지 폴트 비율이 가장 낮다

아니 근데, 언제 사용할지 예측을 어떻게 하는데~

그래서 보통 최적 대치 알고리즘은 비교 연구하는 데에서만 사용해용

최근 최소 사용 대치 알고리즘

보통 가장 최근에 엑세스한 페이지는 빠른 시간 내에 다시 엑세스 할 가능성이 있다.(시간 지역성)

그래서 과거 오랫동안 사용하지 않은 페이지를 대치하는게 효율적이다. 이러한 방식이 최근 최소 사용 대치 알고리즘이다.

최근 최소 사용 대치 알고리즘은 과거의 데이터를 이용하여 미래를 예측하는 통계적 개념이다.

메모리의 지역성을 이용한 알고리즘으로 각 페이지에 마지막으로 사용한 시간을 연관한다.

해당 알고리즘을 구현하려면 프레임 순서를 결정해야한다. 이는 다음 두 가지 방겁으로 구현할 수 있다.

1. 카운터를 이용한 순서 결정

프로세서에 논리 클록을 추가한 후 카운터 필드를 덧붙여서 프레임 순서를 결정한다.

MMS는 페이지 참조가 있을 때 마다 페이지 항목에 업데이트한다.

따라서 페이지를 참조할 때마다 클록은 증가한다.

가장 시간값이 작은 페이지가 대체된다.

2. 스택을 이용한 순서 결정

페이지 번호를 스택에 넣어 관리하고, 참조시마다 스택의 탑에 두어 순서를 결정한다.

최근 최소 사용 근접 알고리즘

최근 최소 사용 대치 알고리즘은 하드웨어에서 지원하지 않는 경우도 있어서 다른 알고리즘을 사용하기도 한다.

상당수 시스템이 참조 비트 형태를 지원하여 이 비트를 이용한 최근 최소 사용 알고리즘을 구현한다.

아래가 그 예시다.

1. 참조 비트 알고리즘

8비트(1바이트)에 일정한 간격으로 참조 비트를 기록한다.

그리고 8비트 시프트 레지스터를 이용하여 순서 정보를 얻는다.

값이 낮을 수록 참조가 오래 됐다는 것이다.

2. 시계(2차적 기회 대치) 알고리즘

가장 오랫동안 메인 메모리에 있던 페이지 중 자주 사용하는 페이지의 대치를 방지하는 것에 목적이 있다.

2차적 기회 대치 알고리즘이라고도 한다.

처음에는 0으로 설정하고, 페이지 사용 시 1로 대체한다.

페이지 교체 시기가 되면 원형 버퍼에서 페이지들을 탐색하고, 1이면 0으로 변환, 0이면 해당 페이지를 대치한다.

3. NUR 알고리즘

최근에 사용하지 않는 페이지는 가까운 미래에도 사용하지 않을 가능성이 높다는 전제로 만들어졌다.

비트를 2개 사용하는데

참조 비트(R)는 해당 페이지의 엑세스 여부를 확인하여 최근 사용한 페이지를 메모리에 유지하는 역할을 하고,

수정비트(M)는 페이지 수정 여부를 확인한다.

따라서 페이지 폴트 발생 시 (0,0) (0,1),(1,0),(1,1), 순서로 대치한다.

4. 최소 사용 빈도수 알고리즘

참조 횟수 카운터가 있으며, 가장 작은 페이지를 대치한다.

근데 옛날에 카운트를 오래 늘린 페이지가 오래 있을 수도 있으니 일정 간격으로 카운트를 지수적으로 감소시켜야 한다.

5. 최대 사용 빈도수 알고리즘

방금 들어와서 아직 사용 안했기 때문에, 앞으로 사용할 확률이 높다고 가정한다.

그러고 나서 가장 많이 사용한 페이지를 대체한다.

성능이 개판이다.

6. 페이지 버퍼링

교체 대상으로 선택된 페이지가 즉시 교체되지 않은 채 잠시 메인 메모리에 유지하는 것을 말한다.

프레임 할당 알고리즘

페이지 대치 알고리즘을 쓰면 유연하게 메모리를 관리할 수 있다.

그러나, 프레임을 적절히 할당하여 페이지 부재 횟수를 줄이는 방법도 매우 중요하다.

글머 어떤 식으로 할당할 수 있을까?

균일 - 비례 프레임 할당 알고리즘

가장 쉬운 방법이다 각 프로세스에 똑같이 프레임을 엔빵하는 것이다.

하지만, 서로 요구하는 메모리 양이 다르기 때문에 좋은 방법은 아니다.

그렇다고 맞춤으로 제공을 한다?

그러면 운영체제가 프로세스 정보를 알아야 한다는 문제가 있어 오버헤드가 발생한다.

따라서 현대 운영체제에서는 균일 할당하는 방식과 프로세스 실행 과정에 다르게 할당하는 비례 할당 방법을 혼합하여 이용한다.

스레싱

페이지 교환이 계속 일어나는 현상을 말한다.

보통 어떤 프로세스가 프로세스 수행에 보내는 시간보다 페이지 교환에 보내는 시간이 길면 스레싱에 걸렸다고 표현한다.

스레싱은 왜 발생할까?

프로세스에 고정된 프레임 수가 현재 활동에 충분하지 않아서 서로 뺏고 빼앗기기 때문이다.

스레싱을 줄이려면 다중 프로그래밍의 정도를 낮춰야만 한다

스레싱을 예방할 수 있을까?

프로세서 사용률과 페이지 폴트 비율을 검사하여 감지할 수 있다.

가상 메모리

이게되네 — Sat, 25 Nov 2023 21:50:33 +0900

가상메모리는 실제 메모리 주소가 아닌 가상의 메모리 주소를 주는 방법이다.

메인 메모리보다 더 큰 저장 공간을 제공할 수 있다.

사용자와 논리적 주소를 물리적으로 분리하여 사용자가 메인 메모리 용량알 초과한 프로세스에 주소를 지정헤서 메모리를 제한 없이 사용할 수 있도록 하는 개념이다.

활둉 영역을 메인 메모리에 유지하면서 필요할 때는 메모리 사이에 스로세스 코드와 데이터를 저장한다.

메모리 내에 스왑 인/아웃을 거쳐 프로세스를 제할당하는 것이 특징이다.

어떻게 이런 방식으로 메모리를 관리할 수 있을까? 바로 아래 이유에 있다.

- 실제로는 모든 프로그램이 항상 동시에 실행하지 않음

- 예외 처리 코드는 자주 필요하지 않고, 안쓸수도 있음

- 배열, 리스트 등은 사용 크기보다 항상 더 크게 정의함

- 문서 편집기에서 복사, 붙이기, 잘라내기, 삽입하기는 메뉴 하나만 메인 메모리에 적재하고, 나머지는 메인 메모리에 없어도 됨(한 순간에 한 기능만 씀)

이렇게 메모리 공간 문제를 활용하려면 논리 주소를 통해 물리적 주소를 분리해야 한다.

가상 주소의 특징은 인위적으로 연속적이라는 것이다. 즉, 가상 주소에서는 연속적이라 해도, 실제 메인 메모리에서는 연속적일 필요가 없다는 것이다.

요구 페이징

가상 메모리에서 많이 사용하는 메모리 관리 방법이다.

프로그램 일부만 메인 메모리에 적재하고, 순차적으로 작성되어 있는 프로그램 모듈 처리 시 다른 부분을 실행하지 않는 특징을 이용한다.

요구 페이징은 실행 중인 프로세스들의 요구 페이지만 메모리에 반입(fetch)하여 프로세스의 모든 페이지를 메모리에 동시에 적재하지 않는다. 이를 지연 스와퍼라고 한다.

1은 타당, 0은 비타당이며, 현재 디스크에서 메모리에 올라와 있는 데이터를 유효 페이지, 즉 타당하다고 볼 수 있다.

비타당한 데이터, 즉 아직 메모리에 올라와 있지 않은 데이터를 요청하는 것을 페이지 부재(page fault)라고 한다.

페이지 폴트 발생 시 다음과 같은 순서로 물리 메모리로 가져온다

즉 요구 페이징은 메모리를 절약할 수 있고, 초기 디스크 오버헤드가 적으나, 페이지 폴트가 자주 발생하면 그 만큼 느려지기 때문에 교체 알고리즘을 신경써야한다.

메모리 관리

이게되네 — Fri, 24 Nov 2023 22:51:43 +0900

메모리 관리는 프로세스들을 위해 메모리를 할당하고 제거하며 보호하는 활동이다.

또한 디스크에 있는 프로그램을 실행하기 위해 메모리에 적재한 후 메모리 관리자가 예약된 메모리를 할당해주는 역할을 한다.

여러 프로세스가 메모리에 상주할 수 있도록 운영체제가 동적으로 메모리를 세분화하는 역할도 한다.

메모리 정책

적재정책

디스크에서 메모리로 프로세스를 반입하는 시기를 결정한다.

프로세스가 요청을 할 떄 적재하는 방식(요구 적재)와

시스템이 요청을 미리 예층해서 매모리에 적재(예상 적재)하는 방식이 있다.

배치정책

디스크에서 반입한 프로세스를 메모리 어느 위치에 저장할 것인지 결정하는 방식이다.

충분히 큰 첫 공백에 적재하는 최초적합,

가장 작은 크기 공간에 적재하는 최적 적합,

가장 큰 공간에 적재하는 최악 적합 등이 있다.

대치 정책(재배치 정책, 교체 정책)

메모리가 충분하지 않을 때 현재 메모리에 적재된 프로세스 중 제거할 프로세스를 결정하는 교체 방법이다.

메모리 구조

메모리 주소는 크게 두 관점으로 해석할 수 있다.

프로그래머가 프로그래밍에 사용하는 공간으로 보는 논리적 관점의 논리적 주소,

실제 데이터나 프로그램을 저장하는 공간으로 보는 물리적 관점의 물리적 주소로 볼 수 있다.

논리적 주소는 가상 주소라고도 한다.

논리적 주소와 물리적 주소 변환은 메모리 관리 장치(MMU)가 처리한다.

즉 MMU는 메모리 분할, 페이징, 세그멘테이션 등을 통해 변환할 수 있다.

논리적 주소를 물리적 주소로 매핑 시켜주는 작업을 바인딩이라고 한다.

변환하는 과정을 컴파일 -> 적재 -> 실행 으로 구분할 수 있다.

메모리 관리 관련 용어

동적 적재

바인딩을 최대한 늦춰 실행 직전에 주소를 확정하는 방식

메모리를 효율적으로 운영할 수 있다.

모든 루틴을 메모리에 적재하지 않고, 교체 가능한 형태로 디스크에 적재한다.

프로그램 전체 양이 많을 때 용이하다.

중첩(오버레이)

당장 필요하지 않은 프로그램 일부를 중첩으로 설정할 수 있다.

실행하려는 프로그램이 메모리보다 클 때 용이하다.

보통 초기 - 처리 - 출력 모듈로 나누고, 초기 -> 처리 -> 출력 순으로 실행한다.

중첩은 운영체제 지원 없이 실행이 가능하다.

보통 마이크로 컴퓨터나, 메모리 제안이 큰 하드웨어에서 사용한다

스와핑(프로세스 교체)

프로세스 수행이 완료됐으면 보조기억장치로 보내고(스왑 아웃),

새롭게 시작하는 프로세스는 메모리에 적재하는(스왑 인)

과정을 말한다.

스와핑은 초기 시분할 시스템에서 채택하고, 최근에는 페이지로 발전했다.

메모리 적재 방법

메모리를 프로세스에 적재하는 방법은 크게 두 가지가 있다.

하나는 연속적으로 적재하는 방법(연속 메모리 적재 방법)

다른 하나는 페이지나 세그먼트 단위로 나눠 여러 곳에 적재하는 방법(비연속 메모리 적재 방법, 분산 적재 방법)이 있다.

직접 배치, 중첩, 고장 분할 등이 연속 적재 방법이다.

허나, 내/외부 단편화 문제 및 실행 시간 낭비 분제가 있어서 보통 분산 적재 방법을 사용한다.

연속 메모리 할당

메모리를 프로세스에 적재할 때 연속적으로 적재하는 방식이다.

초기 컴퓨터 시스템에서 많이 사용하던 방식이다.

메모리를 제어하는 권한이 사용자에게 있어서 사용자가 주소를 잘못 지정하면 운영체제가 손상될 수 있다

따라서 경계 레지스터를 두어서 이를 방지한다

기준 레지스터는 물리적 주소, 경제 레지스터는 논리적 주소이다.

연속 메모리 할당은 구조는 단순하나, 한 번에 한 프로그램만 사용할 수 있고, 메모리 효율성이 떨어진다.

또한, 메모리보다 큰 프로그램을 수행할 수 없어서 스와핑으로 제한된 메모리만 확장한다.

자원 낭비도 심하고, 스와핑 비용이 많이 든다.

다중 프로그램이 환경에서 연속 메모리는 크게

메모리를 여러 개의 고정된 크기로 분할하는 고정 분할 방법과,

필요한 만큼만 할당하는 가변 분할 방법이 있다.

고정 분할 방법

프로세스별로 고정된 크기로 할당하는 방식이다.

내부 단편화

고정분할 방식에서는 기준 레지스터와 경계 레지스터를 통해 메모리를 보호한다.

가별 분할 방법

고정된 경계를 없애고, 각 프로세스가 필요한 만큼 메모리를 할당하는 방법이다.

각 메모리 기준 및 크기를 분할 테이블에서 관리한다.

가변 분할 시 메모리 배치 방법으로 크게 최초 적합, 최적 적합 최악 적합 등이 있다.

최초 적합

사용 가능 공간 중 충분히 큰 첫 공간에 할당하는 방식이다.

공간을 빨리 찾을 수 있으나, 공간 활용율이 떨어진다.

최적 적합

사용 가능 공간 중 가장 작은 공간에 할당한다.

사용 가능 공간을 계속 정렬해야해서 속도는 느리나, 공간 활용도를 높일 수 있다.

최악 적합

프로세스를 가장 큰 공간에 할당한다.

이름때문에 이게 최악으로 보이지만, 그런건 아니다.

가장 큰 공간에 할당해서 또 다른 공간을 만들어서

오히려 최적 적합처럼 짜잘한 공간을 만드는 것 보다 공간 활용도가 높을 수 있다.

메모리 낭비 해결 방안

가변 분할에서는 외부 단편화 문제가 발생한다.

따라서 이러한 문제를 메모리 통합 혹은 압출 방법을 생각할 수 있다.

메모리 통합은 한 작업이 끝나면 인접한 다른 빈 공간과 하나로 합치는 것이다.

메모리 압축은 메모리 내용을 움직여서 사용 가능한 큰 블록을 하나 만드는 것이다.

압축을 하는 동안 모든 일을 중지해야하고, 응답 시간이 일정하지 않고, 오버헤드가 발생하고, 자원 소모도 크지만, 통합 방식보다 메모리 활용도가 높다.

버디 시스템

고정 분할이나 동적 분할 모두 단편화 문제가 있었다.

이를 해결하기 위해 버디 시스템을 제안했다.

큰 버퍼를 반복적으로 이등분하여 작은 버퍼를 만들며, 프로세스를 할당할 수 있을 때 제공하는 방식이다.

버디 시스템으로 고정 분할과 가변 분할 방식을 해결할 수 있다.

하지면 최근에는 페이징이나 세그멘테이션을 활용한 가상 메모리를 선호한다.

페이징

작업을 크기가 동일한 페이지로 나눠서 처리하는 방법이다.

프로세스를 크기가 동일한 페이지로 나누고, 메인 메모리도 프레임이라는 고정 크기 블록으로 나누어 프레임에 페이지를 적재하는 방식이다.

페이징 시스템에서는 다음과 같은 작업을 준비해야 한다.

- 프로세스에 필요한 페이지를 결정하여 페이지 번호를 부여

- 메모리의 빈 프레임을 조사하여 프로세스를 적재할 위치 파악

- 프로세스의 페이지를 빈 프레임에 적재하도록 준비

페이징 방법은 빈 프레임에 어떤 페이지든 적재할 수 있어 메모리를 효율적으로 사용할 수 있고, 외부 단편화도 발생하지 않는다.

하지만, 운영체제가 페이지를 관리해야하고, 필요 공간과 페이지 크기가 맞지 않으면 내부 단편화가 발생한다.

페이지 크기가 작을수록 내부 단편화 발생이 적어지지만, 페이지 테이블을 유지하는 부담이 크다.

그러면 OS는 페이지를 어떻게 관리할까?

프로세서가 만드는 논리적 주소는 페이지 번호와 오프셋(Offset)으로 구성된다.

페이지 번호를 기준으로 기준 주소를 얻고, 거기에 오프셋 값을 더하면 물리적 주소가 된다.

이철머 페이지 테이블을 이용하여 논리 주소를 물리 주소로 변환한다.

다중 단계 페이징

논리적 주소가 클수록 페이지테이블 크기도 증가한다.

n단계 페이징 시스템을 구성해서 페이지테이블의 크기를 줄일 수 있다.

세그멘테이션

페이징은 고정 크기로 분할하기에 내부 단편화가 발생할 수 있다.

이와 달리 세그멘테이션은 메모리 크기를 동적으로 분할할 수 있다.

각 스택, 힙, 메인 프로그램, 전역 변수 등 사용자 관점 별로 메모리를 별도로 분리할 수 있다.

각 프로세스는 고유의 세그먼트 테이블을 메모리에 유지해야 한다.

스케줄링 알고리즘

이게되네 — Fri, 24 Nov 2023 16:02:02 +0900

1. FIFO

가장 단순하다!

프로세서를 요청하는 순서대로 할당해준다.

비선점 방법이다.

딱봐도 성능이 안좋아보인다 좀 더 자세히 말하면 호위효과가 발생할 여지가 있다

호위효과 : 긴 프로세스가 실행하는 동안 짧은 프로세스가 길게 대기하는 현상

2. SJF (Shortest Job First)

각 작업 중에서 실행 시간이 가장 짧은 프로세스에 할당하는 방법이다.

평균 대기 시간이 가장 짧지만, 긴 작업은 기아 상태가 발생할 수 있다.

SJF에서 선점이 가능한 알고리즘을 SRTF(Shortest Remaining time first) 스케줄링이라고 한다.

3. 우선순위 스케줄링

프로세스 중에 우선순위가 가장 높은 프로세스를 할당하는 스케줄링이다.

우선순위 별로 실행 큐를 다르게 설정한다.

우선순위는 제한 시간, 자원 요청량, 중요도 등 다양한 요소로 설정 가능하다.

순위가 높은 프로세스가 계쏙 들어오면 우선순위가 낮은 프로세스는 기아상태에 빠진다

이러한 문제는 에이징 방식을 통해 해결할 수 있다.

에이징 : 대기시간이 질어질수록 우선순위가 높아지는 방식

4. 라운드 로빈 스케줄링(Round Robin)

일정 규정 시간동안 할당하고, 시간이 지나면 인터럽트를 발생시키는 방식이다.

모든 프로세서가 균등하게 실행하기 떄문에 기아가 발생하지 않는 것이 특징이다.

클론 타이머가 너무 짧으면 컨텍스트 스위칭이 많이 발생하여 오버헤드가 커지고,

시간이 너무 길면 FIFO와 길어지는 문제가 발생한다.

따라서 경우에 따라 적절한 시간을 조정해야 한다.

5. 다단계 큐 스케줄링(MultiLevel Queue)

각 작업을 서로 다른 묶음으로 분류할 때 사용한다.

전면작업(포그라운드)와 후면 작업(백그라운드)가 분류가 가능할 떄 즉, 우선순위 별로 분할 시에 용이하다.

각 큐는 독자적인 스케줄링을 가지면서, 가장 높은 우선순위 큐부터 실행한다

6. 다단계 피드백 큐 스케줄링(MultiLevel Feedback Queue)

다단계 큐 스케줄링은 한 큐에서만 고정되어 실행한다. 즉, 다른 작업을 큐로 옮기지 않는다.

반면, MLFQ는 프로세서 실행 시간이 너무 길면 낮은 단계 큐로 옮긴다.

그리하여 하래 큐로 내려갈수록, 프로세서다 거 오래 작업할 수 있도록 해서 규정 시간을 더 얻는 방식으로 동작한다.

MLFQ가 프로세서 스케줄링 중 가장 일반적인 알고리즘이다.

매우 유연하여 시스템에 맞게 구성할 수 있는 것이 장점이다.

7. HRN 스케줄링

가변적으로 우선순위를 계산해서 적용하는 알고리즘이다.

실행시간이 짧을수록, 대기시간이 길 수록 우선순위가 높다.

8. 다중 프로세서 스케줄링

각 프로세서에서 독자적인 큐와 스케줄링을 가지는 것을 의미한다.

허나, 하나의 시스템에 종류가 같은 프로세서가 여러 개이면 부하 공유가 발생한다.

이것은 각 프로세서에서 서로 독립된 큐를 제공하여 방지할 수 있다.

이렇게 하면 모든 프로세서를 프로세스에 한 번만 할당하기 떄문에 오버헤드가 적으나, 병렬성이 떨어질 수 있다.

병렬성을 위해 공용 준비큐를 사용해서 프로세서 큐로 가도록 스케줄링 할 수도 있다.

공용 준비큐를 사용하는 경우도 여러 가지가 있는데, 프로세서 자신이 공용 큐에서 직접 뽑아서 스스로 스케줄링할 수도 있고,

비대칭 다중 처리(Asymmetric MultiProccessing)을 할 수도 있다.

한 프로세서가 다른 모든 프로세서 스케줄링을 지정하는 방식인 것이다.