땅콩의 일기장

stack property stack property란, 캐시사이즈가 n개일때 들어있는 내용이 캐시사이즈가 n+1개일때도(캐시사이즈를 늘렸을때도) 다 들어있는 성질이다. optimal, LRU정책의 경우 stack property를 만족하기 때문에 캐시 사이즈가 늘어나면 hit ratio가 좋아진다. 반면, FIFO의 경우 stack property를 만족하지 않기 때문에 캐시사이즈를 늘렸을 때 오히려 성능이 나빠지기도 한다. (Belady's anomaly) 각 정책별 workload optimal과 LRU는 locality에 따라 캐시를 교체하고, FIFO는 locality 고려 없이 무조건 오래된 캐시를 교체하고, random은 아무런 기준없이 랜덤하게 캐시를 교체한다. 이런 여러 정책별로 캐시사이..

앞서 physical memory의 한계를 극복하기 위해 main memory를 hard disk의 캐시처럼 사용하는 demand paging을 살펴보았다. 이제 demand paging에서 메인 메모리가 부족할 때 전에 캐싱된 내용의 변경(swapping)이 어떤 정책으로 일어나는지를 살펴보자. average memory access time (AMAT) TM = Memory Access Latency TD = Disk Access Latency Pmiss = 1 - Phit 위의 수식에서 알 수 있듯이 hit ratio는 전체 성능에 큰 영향을 주고, 이 hit ratio에 큰 영향을 주는 것이 교체 정책이다. 교체 정책 (page replacement policies) 1. Optimal polic..

메모리 계층 구조 1. cpu의 register = 가장 빠른 저장공간 2. 캐시 메모리 3. 메인 메모리 (DRAM) 4. 굉장히 큰 용량의 저장 장치 (하드디스크, 테이프 등..) demand paging 앞서 paging의 속도가 느린 이슈는 TLB로 해결하고, page table이 너무 큰 이슈는 hybrid/ multi level paging으로 해결했다. 그럼 physical memory 자체의 용량이 부족한 한계점은 어떻게 해결할 수 있을까? 바로 메인메모리를 하드디스크의 캐시처럼 사용하는 demand paging을 통해 우리는 거의 무한대에 가까운 virtual momory공간을 확보할 수 있다. 메인메모리의 내용이 캐시메모리에 캐싱되는 것처럼, 하드디스크의 내용이 메인메모리로 캐싱될 수 ..

paging base and bound, segmentation과 구분되는 paging의 장점은 고정된 페이지 크기를 사용하여 메모리 관리가 편리하다는 점이다. 하지만 주소변환정보를 담고 있는 page table과 관련해서 두가지의 문제가 있다. 1. 속도의 문제 page table이 물리적 메모리에 위치하고 있기 때문에, 하나의 명령어를 수행하기 위해 여러번 메모리에 접근해야 해서 속도가 느림. >> 이것은 TLB로 해결할 수 있다. 2. 크기의 문제 page table에서 VPN를 인덱스로 PFN를 담고있는 entry를 가져오기 위해서는 페이지 테이블이 연속된 공간을 확보해야 한다. 그런데 page table이 너무 커진다. 그렇다고 page의 크기를 크게 하면, page table entry개수는 ..

데이터 중심 설계의 문제점 기본 매핑 예제를 보면 데이터베이스 테이블의 외래키를 객체에 그대로 가져오며 테이블 설계에 객체를 맞춘 것을 볼 수 있다. @Entity @Table(name = "ORDERS") //order가 예약어로 걸려있는 경우가 있어서 ORDERS로 많이 쓴다. public class Order { @Id @GeneratedValue @Column(name = "ORDER_ID") private Long id; @Column(name = "MEMBER_ID") private Long memberId; //누가 주문했는지. private LocalTime orderDate; @Enumerated(EnumType.STRING) private OrderStatus Status; } 그리고 ..

paging이 느린 이유와 TLB memory에 접근하기 위해 주소 변환을 하는데, 이 주소 변환 정보(page table)는 매우 커서 memory에 저장된다. 다시말해 memory에 접근하려고 주소변환을 하는데 그 정보가 또 메모리에 있는 것이다. 이 때문에 memory에 매번 추가로 한번 더 access해야한다. 그래서 이것을 빠르게 하고자 TLB(translation lookaside buffer)를 사용한다. TLB는 mmu안에 들어있고, 구조적으로는 캐시메모리이기 때문에 address translation cache라고도 부른다. 주소변환이란 앞서 설명했듯이 VPN를 PFN로 변환하는 과정이고, 여기서 캐시메모리를 사용하여 주소변환정보를 기억했다가 다시 사용하도록 하는 것이 TLB이다. TLB..

paging paging은 base and bound, segmentation과는 달리 address space를 고정된 크기로 나눈다. virtual memory(address space)의 이 고정된 크기의 한 단위를 page라고 하고, 이것을 실제로 가지고 있는 물리적 메모리에서는 slot, page frame, frame이라고 부른다. 왼쪽 그림과 같이 64 바이트의 address space를 addressing하려면 2^6 = 6비트가 필요하다. 페이지가 4개로 나뉘기 때문에 상위 2비트는 virtual page number를 가리키고(VPN) 나머지 4비트는 한 페이지 내에서 addressing하는데에 사용된다. 또 virtual address가 오른쪽 그림같은 실제 물리적 메모리의 어디에 저..

데이터베이스 스키마 자동 생성 jpa에서는 DDL을 애플리케이션 실행 시점에 자동으로 생성해준다. 데이터베이스 방언(dialect)을 이용해서 데이터베이스에 맞는 적절한 DDL을 생성한다. 그리고 이렇게 생성된 DDL은 개발 장비에서만 사용하고 운영서버에서는 사용하지 않는다. (사용하더라도 다듬고 사용) hibernate.hbm2ddl.auto 옵션 create 기존 테이블 삭제 후 다시 생성 (drop + create) create-drop create와 같으나 종료 시점에 테이블 drop update 변경분만 반영(운영 DB에는 사용하면 안됨!) validate 엔티티와 테이블이 정상 매핑되었는지만 확인 none 사용하지 않음. 운영장비에는 절대 create, create-drop, update를 사..

엔티티 매니저 팩토리와 엔티티 매니저 고객의 요청이 올 때마다 엔티티매니저를 생성하고, 이 엔티티 매니저는 데이터 커넥션을 사용해서 db에 접근하게 된다. 영속성 컨텍스트란? 영속성 컨텍스트란, 엔티티를 영구 저장하는 환경이다. 논리적인 개념으로 눈에 보이지는 않고 엔티티 매니저를 통해서 영속성 컨텍스트에 접근한다. //엔티티를 영속성 컨텍스트에 저장한다. EntityManager.persist(entity); 엔티티 생명주기 1. 비영속 (new/transient) = 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태 2. 영속 (managed) = 영속성 컨텍스트에 관리되는 상태 3. 준영속 (detached) = 영속성 컨텍스트에 저장되었다가 분리된 상태 4. 삭제 (removed) = 삭제된 상태 ..

JPA란? JAVA Persistence API. 객체와 관계형데이터베이스의 차이때문에 생기는 SQL의존적인 개발을 피하기 위해 사용하는 자바 진영의 ORM 기술 표준! 애플리케이션과 JDBC 사이에서 동작하며, 프로그래머가 객체중심으로 데이터베이스에 접근하며 개발할 수 있도록 도와준다. JPA 구동 방식 객체와 테이블을 생성하고 매핑하기 @Entity는 jpa가 관리할 객체를 알려주고, @Id는 데이터베이스의 pk와 매핑된다. //객체생성 @Entity public class Member { @Id private Long id; private String name; } //테이블생성 create table Member ( id bigint not null, name varchar(255), primar..