본문 바로가기
Database

[HANA] 2222250 - FAQ: SAP HANA workload Management

이반&핫버드 2019. 5. 6. 00:20

* https://launchpad.support.sap.com/#/notes/2222250

 

https://launchpad.support.sap.com/#/notes/2222250

 

launchpad.support.sap.com

 

What is SAP HANA workload

  • HANA에서의 Workload
    • OLAP workload - BW system
    • OLTP workload - transactions in an ERP system
    • Mixed workload - both OLAP and OLTP = modern ERP system
    • Internal workload - merges, backups and savepoints
  • 병목이 될 수 있는 resource
    • Memory
    • CPU and threads
    • Network --> 관련된 configuration 없음

 

 

Memory를 위한 설정 

  • Memory limit for SQL Statement
    • single SQL statement의 메모리 사용의 제한 가능 (HANA 1.0 SPS08이후)
    • 파라미터 설정-1
      • gloabl.ini -> [memorymanager] -> statement_memory_limit = <maximum_memory_allocation_in_gb>
      • Restart 불필요
      • Host specific = Scale-out 장비에서도 각 host별 적용되는 메모리 제한
      • 설정에 주의 필요 (backup 또는 주요한 업무쿼리의 termination 유발가능)
      • 초과 시 terminate 되며 OOM dump 발생
    • 파라미터 설정-2
      • global.ini -> [memorymanager] -> statement_memory_limit_threshold = <percentage_of_global_allocation_limit>
      • 파라미터가 설정되지 않으면 할당 된 메모리와 관계없이 설정된 memory limitaion이 일반적으로 적용 됨
      • 매우 큰 할당 요청의 경우(Threshold를 고려하지 않고 이미 할당된 메모리만 고려하기 때문) 문제가 발생할 수 있으므로 특정 요구사항의 경우에만 파라미터를 설정하는 것이 좋음
  • SQL Statement of specific database user
    • DB User별 statement memory 설정 가능 (HANA 1.0 SPS09 이후)
    • Comman
      • 설정 = ALTER USER <db user> SET PARAMETER STATEMENT MEMORY LIMIT = '<maximum_memory_allocation_ib_gb>'
      • 해제 = ALTER <db user> CLEAR PARAMETER STATEMENT MEMORY LIMIT
  • SQL Statements of specific workload class
    • 특정 statement memory 설정을 위해 workload class 설정 가능 (HANA 1.0 SPS10 이후)
    • 특정 workload class의 전체 메모리 사용의 제한 가능 (HANA 2.0 SPS02 이후)
    • 주의사항
      • 설정을 위해서 다음 3개의 properties가 set로 설정 되어야 함
        • TOTAL STATEMENT THREAD LIMIT, TOTAL STATEMENT MEMORY LIMIT, PRIORITY
      • statement-level 또는 total properties 설정 (동시 설정은 안됨)
      • HANA workload management (Internal) 참조
  • SQL Statement globally on host
    • DB request의 전체 메모리 할당 제한이 가능 (HANA 2.0 SPS00 이후)
    • 파라미터 설정
      • global.ini -> [memorymanager] -> total_statement_memory_limit = <maximum_memory_allocation_in_gb>
    • 주의사항
      • 파라미터 설정 시 내부적인 메모리 blocking 문제가 전반적인 OOM 이 발생될 수 있으므로 주의가 필요함
      • 다음 Role을 가진 user에는 적용되지 않음 (SESSION ADMIN, WORKLOAD ADMIN)

 

 

CPU and Thread를 위한 설정

  • Overview
    • CPU consumption의 제어 = active HANA thread 개수 제어
    • CPU 사용율이 높은 경우 우선 성능튜닝 접근으로 제한이 가능한지 여부부터 확인 필요
  • SQL executors
    • SQL excutors (soft limit) - general
      • <service>.ini -> [sql] -> sql_executors
        - default = 0 (number of loggical CPU cores of host)
        - Restart 불필요
      • 일반적인 SQL request의 처리를 책임지는 thread
      • max_sql_executor 보다는 less restrict (실제 used SQL executor 수는 설정을 넘을 수 있음)
    • SQL executors (hard limit) - general
      • <service>.ini -> [sql] -> max_sql_executors
        - default  = 0 (제한 없음)
        - Restart 불필요
      • HANA node별 최대 SQL Executor 수
      • 특별한 이유로 설정된 값을 넘는 경우 transaction은 error와 함께 terminated 될 수 있음
        -> 주의 깊게 설정 필요
    • Soft limit에 도달한 경우의 처리 방식 - general
      • <service>.ini -> [session] -> busy_executor_threshold
        - default = 1000000 (단위 = micro-seconds, 1 second)
        - Restart 불필요
      • HANA가 sql_executor의 soft limit에 도달한 경우 설정된 값만큼 대기 후 추가적인 SQL thread를 시작함 -> 값이 클 수록 더 적은 추가 SQL executor가 실행 됨
      • 각 세션별로 새로운 SQL executor가 생성될 수 있음 -> 전체 추가된 SQL executor는 기대했던 값보다 클 수 있음
        • 예) 설정 = 1초, 10개 session, SQL executor 제한 5초간
        • => 10 * 5 = 50 개의 추가적인 SQL Executor 수행 됨
  • Job worker
    • System wide - general
      • <service>.ini -> [execution] -> max_concurrency
        - default = 0 (논리적 CPU core 숫자 / 최소 4)
        - Restart 불필요
      • JOB worker는 OLAP load와 내부적인 activity (savepoint, gc등)를 처리하는 thread
      • HANA node 별 JobWorker 수를 제한 함
      • 각 active job worker가 현재 CPU를 100% 사용하고 있지 않으면 설정값보다 많은  추가적인 job work가 활성화 가능
      • Active job worke가 시간이 지남에 따라 CPU 사용을 늘리면 정의된 수의 논리적 CPU를 초과할 수 있음 
    • For database request - >= HANA1.00.102.03
      • <service>.ini -> [execution] -> default_statement_concurrency_limit
        - default = 0 (no limit)
        - Restart 불필요
      • Single database 요청에 대한 최대 전체 병렬화를 제어
    • For single parallelism operation of database request - general
      • <service>.ini -> [execution] -> max_concurrency_hint
        - default = 논리적 CPU core 수 (<= HANA1.0 SPS08)
        - Restart 불필요
      • <service>.ini -> [parallel] -> num_cores
        - default = max_concurrency (>= HANA1.0 SPS09)
        - Restart 필요
      • HANA Noe별 job worker 수를 정의 (max_concurrency와 유사)
        • 개별 병렬 처리를 위해 생성된 job의 수
        • 전체 job의 개수는 설정값을 일반적으로 초과함 
      • num_cores는 HANA2.0부터 더이상 사용하지 않음 (0으로 설정하면 안됨)
    • Dynamic max_concurency reduction in phases of high load - >= 2.00.030
      • <service>.ini -> [execution] -> max_concurrency_dyn_min_pct
        - default = 40
        - Restart 불필요
      • 높은 OLTP 로드의 경우 max_concurrency 제한의 자동 동적 감소를 구성
      • SqlExecutor에 의해 사용되는 것이 더 좋은 CPU 자원을 많은 수의 jobWorker가 사용하는 위험을 줄일 수 있음

    • Dynamic max_concurency_hint reduction in phases of high load - >= 2.00.030

      • <service>.ini -> [execution] -> max_concurrency_hint_dyn_min_pct
        - default 50
        - Restart 불필요
      • High workload인 경우에 max_concurency 제한의 자동 동적 감소를 구성
      • Dynamic concurrency hint를 줄이는 다른 mechanism에 추가로 적용됨 -> 50% 이하로 줄어들 수도 있음
      • 특정 단일 병렬처리가 많은 CPU를 사용하여 성능이 느려지는 위험을 줄일 수 있음
  • Check table consistency
    • not started by ESS - >= 1.00.97.01
      • <service>.ini -> [table_consistency_check] -> check_max_concurrency
        - default 0 (Host의 논리 CPU Core 수)
        - Restart 불필요
      • Consistency check를 사용하는 병렬 처리되는 table 수를 제어
      • 단일 테이블의 분석이 서버 측에서 병렬처리 될 수 있음
    • started by ESS - >= 1.00.97.01
      • <service>.ini -> [table_consistency_check] -> internal_check_max_concurrency
        - default 0 (= max(1, min (8, 논리 CPU core 수 / 10)))
        - Restart 불필요
      • 기본적으로 최대 8개의 CPU가 사용되며 노드에 80개 미만의 CPU Core가 있는 경우 더 적은 수의 CPU가 사용됨
      • 단일 테이블의 분석이 서버 측에서 병렬처리 될 수 있음
  • Job queue
    • Text indexing job queue
      • preprocessor.ini -> [jobqueue] -> num_cores
        - Restart 필요
      • fulltext indexing과 같은 preprosessor activity를 위한 thread 의 최대 개수 설정
  • Internal Operation
    • Persistence garbage collection - general
      • <service>.ini -> [persistence] -> max_gc_parallelity
        - default 0 (논리적 CPU Core 수)
        - Restart 필요
      • GC의 병렬처리를 제어함
      • 기본적으로 다소 높은 병렬처리가 사용되므로 높은 시스템 CPU 사용이 발생 가능
        • 파라미터를 줄이면 여기의 Overhead를 줄일 수 있음
        • 줄이면 GC 지연, 증가하는 지속성 및 DB Full 상황이 발생할 수 있음
    • Delta merges - general
      • indexserver.ini -> [mergedog] -> load_balancing_func
        - defualt  = 1 + LCC (AHM/GAL) * (100 - CL) / 100
        - Restart 불필요
      • indexserver.ini -> [mergedog] -> token_per_table
        - default 2
        - Restart 불필요
      • indexserver.ini -> [indexing] -> parallel_merge_threads
        - default 2
        - Restart 불필요
      • load_balancing_func이 전체 merge load를 제어하며 token_per_table 및 parallel_merge_threads는 단일 테이블(파리션)의 merge load를 제한 함
    • Metadata recompilation - general
      • indexserver.ini -> [metadata] -> max_num_recompile_threads
        - default = 0 (논리적 CPU Core 개수)
        - Restart 불필요
      • Metadata recompile에 사용되는 thread 개수를 제어
      • 많은 dependency를 가진 object를 recompile하는 경우에는 특별히 큰 값일 수 있음
      • 값을 줄이는 것이 crash에 대한 workaround 일 수 있음 (SAP Note 2664814, SAP Note 2678230)
    • Optimize compression - general
      • indexserver.ini -> [optimize_compression] -> change_compression_threads
        - default = 8
        - Restart 불필요
      • indexserver.ini -> [optimize_compression] -> estimate_compression_threads*
        - default = 8
        - Restart 불필요
      • indexserver.ini -> [optimize_compression] -> get_candidates_threads*
        - default = 0 (automatic)
        - Restart 불필요
      • indexserver.ini -> [optimize_compression] -> prepare_threads
        - default = 8
        - Restart 불필요
      • indexserver.ini -> [optimize_compression] -> row_order_optimizer_threads*
        - default = 0 (max_concurrency_hint)
        - Restart 불필요
      • Optimize compression 수행의 여러단계에서 병렬 thread 수를 제어
      • (*) SAH HANA 112.02 이후 사용 가능
    • Recovery - general
      • global.ini -> [persistence] -> recovery_queue_count
        - default = 0 (논리적 CPU core 수)
        - Restart 불필요

      • 복구 수행의 초히대 병렬 수를 제어함
      • 설정값 조정은 다음 경우에 유용
        • Crash during liveCache recovery (SAP Note 1964645)
        • 적은 수의 복구 요청은 replication 시나리오에서 log replay 모드의 secondary site의 높은 CPU 사용을 줄일 수 있음
    • Dynamic Tiering - >= 1.00.90
      • esserver.ini -> [startup] -> max_concurrent_connections
        - default = 5
        - Restart 불필요
      • esserver.ini -> [startup] -> max_concurrent_queries
        - default = 32
        - Restart 불필요
      • Dynamic tiering service에서 사용되는 동시접속 및 쿼리의 최대 수를 제어
    • Embeded statistics server - >= 1.00.744, ESS
      • indexserver.ini -> [statisticsserver] -> threadpool
        - default = 5
        - Restart 불필요
      • statistics server용 동시접속 을 위한최대 trhead 수를 제어
    • Row store batch INSERTs
      • indexserver.ini -> [row_engine] -> dynamic_parallel_insert_max_workers
        - default = 1/3 of 논리적 CPU core 수
        - Restart 불필요
      • Row store table의 batch INSERTs에 사용되는 thread 수를 제어
      • SAP Note 2253121 참조
    • Capture and replay
      • global.ini -> [workload_replay] -> loading_thread
        - default = 10
        - Restart 불필요
      • global.ini -> [workload_replay] -> table_partition_size
        - default = 40
        - Restart 불필요
      • workload capture and replay의 context에서 시작된 thread 수를 제어
      • SAP Note 276800 참조
    • CPUs per services - >= 1.00.90
      • daemon.ini -> [<service_name>] -> affinity
        - default = No assignment
        - Restart 필요
      • 서비스 당 CPU 사용량 (예: statisticsserver, idexserver 등)을 제어 
  • Object 관리 
    • Repartitioning (table) - general
      • indexserver.ini -> [partitioning] -> split_threads
        - default = 16 (1~128 선택 가능)
        - Restart 불필요
      • Repartition 수행 시 병렬도 제어
      • SAP Note 2044468 참조
    • Repartitioning (history table) - general
      • indexserver.ini -> [partitioning] -> split_history_parallel 
        - default = no
        - Restart 불필요
      • History 테이블의 main 및 history 부분이 병렬로 repartition 여부를 제어함
    • Table reload - general
      • indexserver.ini -> [parallel] -> tables_preloaded_in_parallel
        - default = 5
        - Restart 필요
      • DB start 시 병렬로 얼마나 많은 테이블이 load되는지를 제어함
      • SAP Note 2127458 참조
    • Table redistribution - >= 1.00.73
      • indexserver.ini -> [table_redist] -> num_exec_threads
        - default 20 (SPS >= 11, 그 이전은 10)
        - Restart 불필요
      • 테이블 redistrubution 수행 시 시작되는 thread의 수를 제어
      • SAP Note 281591 참조
      • 늘리면 redistrubution 시간은 줄일 수 있으나 System 자원 (CPU, Memory, I/O)의 소비가 증가함
    • Table replication - >= 1.00.110
      • indexserver.ini -> [transaction] -> num_of_async_rep_queue
        - default = 1/3 of 논리적 CPU core 수
        - Restart 불필요
      • Asynchronous table replication 모드인 경우 table data의 replicate에 사용 되는 thread 수를 제어
      • SAP Note 2340450 참조
  • SQL Statement of specific workload class

 

 

 

DB Request의 우선순위 설정

  • 특정 유저에 설정
    • ALTER USER <db_user_name> SET PARAMETER PRIORITY = '<priority>'
    • 0~9 (default = 5)
  • 특정 workload class에 설정
    • CREATE WOKLOAD CLASS "<workloa_class>" SET PRIORITY = '<priority>
    • ALTER WORKLOAD  CLASS "<workloa_class>" SET PRIORITY = '<priority>
    • 0~9 (default = 5)

 

 

 

HANA Adminssion control

저작자표시 비영리 변경금지

'Database' 카테고리의 다른 글

[HANA] 2700084 - FAQ: SAP HANA Persistent Memory  (0) 2019.05.08
[HANA] Admission control  (0) 2019.05.06
[HANA] Trouble shooting - Version GC Issue  (0) 2019.05.03
[HANA] Trouble shooting - MVCC Issue  (0) 2019.05.03
[HANA] Workload Management (internal)  (0) 2019.05.01

'Database' Related Articles

티스토리툴바