Berkeley DB Reference Guide: Access method tuning

Berkeley DB Reference Guide:
Access Methods

Access method tuning

There are a few different issues to consider when tuning the performance of Berkeley DB access method applications.

(액세스 메소드 성능과 관련된 튜닝 이슈들..)

access method

An application's choice of a database access method can significantly affect performance. Applications using fixed-length records and integer keys are likely to get better performance from the Queue access method. Applications using variable-length records are likely to get better performance from the Btree access method, as it tends to be faster for most applications than either the Hash or Recno access methods. Because the access method APIs are largely identical between the Berkeley DB access methods, it is easy for applications to benchmark the different access methods against each other. See Selecting an access method for more information.

(액세스 메소드는 성능에 중대한 영향을 미친다.고정길이의 레코드나 정수키를 사용하는 애플은 큐를 사용할때 성능이 높다.가변길이의 레코드일경우는 Btree메소드가 성능이 높고 대부분의 애플에서 해시나 Recno를 사용하는 경우보다 일반적으로 빠른 경향이 있다.액세스 메소드 API는 비슷하기때문에 엑세스메소드를 바꿔가면서 벤치마킹이 쉽다.)

cache size

The Berkeley DB database cache defaults to a fairly small size, and most applications concerned with performance will want to set it explicitly. Using a too-small cache will result in horrible performance. The first step in tuning the cache size is to use the db_stat utility (or the statistics returned by the DB->stat function) to measure the effectiveness of the cache. The goal is to maximize the cache's hit rate. Typically, increasing the size of the cache until the hit rate reaches 100% or levels off will yield the best performance. However, if your working set is sufficiently large, you will be limited by the system's available physical memory. Depending on the virtual memory and file system buffering policies of your system, and the requirements of other applications, the maximum cache size will be some amount smaller than the size of physical memory. If you find that db_stat shows that increasing the cache size improves your hit rate, but performance is not improving (or is getting worse), then it's likely you've hit other system limitations. At this point, you should review the system's swapping/paging activity and limit the size of the cache to the maximum size possible without triggering paging activity. Finally, always remember to make your measurements under conditions as close as possible to the conditions your deployed application will run under, and to test your final choices under worst-case conditions.

(버클리디비의 디폴트 캐쉬 크기는 매우 작다.성능에 민감한 애플은 명시적으로 크기를 결정하고 싶을 것이다.너무작은 크기의 캐쉬는 성능을 극도로 나쁘게 만든다.캐쉬크기튜닝의 첫번째 단계는 db_stat유틸(또는 DB->stat 에서 리턴된 통계정보)을 사용하여 현재캐쉬의 효율성을 측정하는것이다.목표는 캐쉬의 hit rate를 최대화 하는것이다.특히 hit rate가 100%에 이르도록 캐쉬크기를 늘리거나 levels off하는것은 최대의 성능을 가져온다.그러나 만약 워킹셋이 충분히 크다면 여러분은 시스템의 사용가능한 물리적 메모리에 제한을 받게 된다.먄약 db_stat 가 증가된 캐쉬크기가 hit rate를 향상시켰지만 성능이 더 좋아지거나 나빠지면 그것은 시스템 제한때문일수 있다.이시점에서 여러분은 시스템의 스와핑/페이징 동작과 페이징을 발생시키지 않는 최대 케쉬 크기 리미트에 대해 살펴보아야 한다.마지막으로 이러한 측정은 실제 애플이 도는 상황과 근접한 환경에서 실행되어야 하고 최악의 상황을 베이스로 튜팅해야 된다는 점을 기억하기 바란다.)

shared memory

By default, Berkeley DB creates its database environment shared regions in filesystem backed memory. Some systems do not distinguish between regular filesystem pages and memory-mapped pages backed by the filesystem, when selecting dirty pages to be flushed back to disk. For this reason, dirtying pages in the Berkeley DB cache may cause intense filesystem activity, typically when the filesystem sync thread or process is run. In some cases, this can dramatically affect application throughput. The workaround to this problem is to create the shared regions in system shared memory (DB_SYSTEM_MEM) or application private memory (DB_PRIVATE), or, in cases where this behavior is configurable, to turn off the operating system's flushing of memory-mapped pages.

(디폴트로 버클리 디비는 디비환경의 공유역역들을 메모리 백업 파일시스템에 생성한다.어떤 시스템에서는 dirty 페이지를 디스크로 플러싱할때 일반 파일시스템 페이지와 메모리 맵 페이지를 구별하지 않는다.이같은 이유로 버클리디비 캐시의 dirty 페이지는 파일시스템동작을 많이 발생시킬 수 있다.특히 쓰레드와 프로세스를 동기화하는 파일시스템일때는 더욱 그러하다.어떤경우에는 이것은 애플의 처리속도에 극적으로 많이 영향을 미칠수있다.이러한 문제를 회피하기 위해서는 시스템공유메모리(DB_SYSTEM_MEM )나 애플리케이션 프라이빗 메모리(DB_PRIVATE)에 공유영역을 생성하거나 이러한 문제에 대해 시스템적으로 설정가능하다면 메모리 맵페이지의 플러싱을 off시켜야 한다.)

large key/data items

Storing large key/data items in a database can alter the performance characteristics of Btree, Hash and Recno databases. The first parameter to consider is the database page size. When a key/data item is too large to be placed on a database page, it is stored on "overflow" pages that are maintained outside of the normal database structure (typically, items that are larger than one-quarter of the page size are deemed to be too large). Accessing these overflow pages requires at least one additional page reference over a normal access, so it is usually better to increase the page size than to create a database with a large number of overflow pages. Use the db_stat utility (or the statistics returned by the DB->stat method) to review the number of overflow pages in the database.

(큰 키/데이타를 디비에 저장하는 것은 Btree,Hash,Recno디비의 성능특성을 변경시킨다.첫번째로 생각해볼 것은 디비 페이지 크기다.키/데이타 아이템이 너무크면 하나의 디비페이지에 위치될수 없다.이것은 일반적 디비 구조 밖의 오퍼블로우 페이지에 저장된다.(특히 페이지크기의 1/4보다 큰 아이템은 너무 크다고 생각해야 한다.).이 오버플로우 페이지를 접근하기 위해서는 일반적인 액세스에 비해 최소한 하나의 추가적 페이지 참조가 필요하다.그래서 많은 수의 오버플로우 페이지를 가진 디비를 생성하기보다는 페이지 크기를 늘리는것이 더 좋다.디비의 오버플러우 페이지수를 보기위해 db_stat utility (or the statistics returned by the DB->stat method)를 사용하라.)

The second issue is using large key/data items instead of duplicate data items. While this can offer performance gains to some applications (because it is possible to retrieve several data items in a single get call), once the key/data items are large enough to be pushed off-page, they will slow the application down. Using duplicate data items is usually the better choice in the long run.

(두번째 이슈는 복사된 데이타 아이템 대신 큰 키/데이타 아이템을 사용하는 문제다.이러한 사용이 단일 함수 호출로 여러개의 데이타 아이템을 가져올 가능성이 있기 때 어떤애플의 성능향상에 도움을 줄수도 있지만 키/데이타 아이템이 오프페이지에 푸시될만큼 크다면 결국 애플을 느리케한다.복사된 데이타 아이템은 오랜 수행을 할때는 더좋은 선택이다.)

A common question when tuning Berkeley DB applications is scalability. For example, people will ask why, when adding additional threads or processes to an application, the overall database throughput decreases, even when all of the operations are read-only queries.

(버클리 디비 애플 튜닝에 대한 흔한 질문중 하나는 확장성이다.예를들어 사람들은 왜 그리고 언제 쓰레드나 프로세스가 애플에 추가되어야 하는지 그리고 (심지어 모든 오퍼레이션이 읽기전용 쿼리일때도)전체디비의 처리량의 감소시키는지를 물어 볼것이다.)

First, while read-only operations are logically concurrent, they still have to acquire mutexes on internal Berkeley DB data structures. For example, when searching a linked list and looking for a database page, the linked list has to be locked against other threads of control attempting to add or remove pages from the linked list. The more threads of control you add, the more contention there will be for those shared data structure resources.

(첫째,읽기전용 오퍼레이션이 논리적인 동시성을 갖는다면 그것들은 버클리디비 내부적으로 뮤텍스를 얻는 동작을 하게 된다.예를 들어 링크드리스트를 검색하고 디비페이지를 찾을때 링크드리스는 링크드리스트에 페이지(역자주:링크드리스트의 아이템)의 추가삭제를 뮤텍스로 막하야 한다.더많은 쓰레드를 애플에 추가할수록 공유리소스를 쓰기위한 더많은 경쟁이 있게 된다.)

Second, once contention starts happening, applications will also start to see threads of control convoy behind locks (especially on architectures supporting only test-and-set spin mutexes, rather than blocking mutexes). On test-and-set architectures, threads of control waiting for locks must attempt to acquire the mutex, sleep, check the mutex again, and so on. Each failed check of the mutex and subsequent sleep wastes CPU and decreases the overall throughput of the system.

(두번째로 경쟁의 시작이 발생하게 되면 애플은 또한 락을 얻기위한 동작이 실행된다(뮤텍스를 블락킹하기보다 테스트-셋 스핀 뮤텍스만을 지원하는 아키텍서에서는 더더욱).테스트-셋 아키텍쳐에서는 락을 기다리는 쓰레드는 뮤텍스얻기시도,슬립,다시 뮤텍스얻기시도,슬립을 계속반복해야만 한다.뮤텍스얻기의 각각의 실패와 이어지는 슬립은 CPU를 소모시키고 전체적인 처리량을 감소시킨다.)

Third, every time a thread acquires a shared mutex, it has to shoot down other references to that memory in every other CPU on the system. Many modern snoopy cache architectures have slow shoot down characteristics.

(세번째..공유된 뮤텍스를 어던 쓰레드가 얻을때마다 이것(뮤텍스얻기)는 그 시스템의 다른 CPU에 대해 다른 메모리 참조를 shoot down시켜야 한다.현대의 많은 스누피캐시 아키텍쳐는 slow 슈다운 특성을 가지고 있다.)

Fourth, schedulers don't care what application-specific mutexes a thread of control might hold when de-schedule a thread. If a thread of control is descheduled while holding a shared data structure mutex, other threads of control will be blocked until the scheduler decides to run the blocking thread of control again. The more threads of control that are running, the smaller their quanta of CPU time, and the more likely they will be descheduled while holding a Berkeley DB mutex.

(네번째,스케쥴러는 쓰레드를 de-스케쥴링할때 어떤쓰레드가 가지고 있는 뮤텍스에 대해 고려하지 않는다.만약 뮤텍스를 가진 쓰레드가 de-스케쥴링되면 뮤텍스를 가진 쓰레드가 다시 스케쥴링될때까지 모든 다른 쓰레드는 블락킹되게 된다.더많은 쓰레드가 돌수록 CPU점유시간은 더 적고 뮤텍스를 가지고 있을동안 더 많이 de스케쥴링 될것이다.)

The results of adding new threads of control to an application, on the application's throughput, is application and hardware specific and almost entirely dependent on the application's data access pattern and hardware. In general, using operating systems that support blocking mutexes will often make a tremendous difference, and limiting threads of control to to some small multiple of the number of CPUs is usually the right choice to make.

(쓰레드를 애플에 추가시켰을때의 결과는 애플,하드웨어에 따라 다르고 거의 전체적으로 애플리케이션 액세스패턴과 하드웨어에 의존적이다.일반적으로 블락킹뮤텍스를 지원하는 운영체계를 사용하는 것은 대단한 차이점을 만든다(역자주:더좋다는 소리다.). 그리고 쓰레드수를 CPU수와 같을 정도로 적게 제한하는 것은 보통 좋은 선택이다. )

Berkeley DB Reference Guide:Access Methods

Access method tuning

Berkeley DB Reference Guide:
Access Methods