반응형

MariaDB와 Mysql 성능을 테스트하기 위해

 

HammerDB를 사용하다가

 

보니...

 

정작 중요한 my.cnf 설정이 정상적인가? 물음에 도달하게 되었습니다.

 

정확한 설정값을 위해 자동 튜닝 스크립트를 제공하는 사이트를 발견하였습니다.

 

보통 정상적으로 튜닝 범주라고 체크 할려면 48시간이상 이용해야 한다는 사실은 존재합니다.

 


 

virtualbox 상에서 실행한 결과 (OK : 정상 / !! 설정 이상 / -- SKIP)

 

 >>  MySQLTuner 1.7.15 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[OK] Logged in using credentials passed on the command line
[OK] Currently running supported MySQL version 10.3.17-MariaDB
[OK] Operating on 64-bit architecture

-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: /var/lib/mysql/hammerdb.err(0B)
[!!] Log file /var/lib/mysql/hammerdb.err doesn't exist
[!!] Log file /var/lib/mysql/hammerdb.err isn't readable.

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +Aria +CSV +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA +SEQUENCE
[--] Data in InnoDB tables: 999.9M (Tables: 9)
[OK] Total fragmented tables: 0

-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.

-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] User 'root@%' does not specify hostname restrictions.
[!!] There is no basic password file list!

-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 34m 1s (279K q [136.873 qps], 133 conn, TX: 74M, RX: 38M)
[--] Reads / Writes: 50% / 50%
[--] Binary logging is disabled
[--] Physical Memory     : 1.8G
[--] Max MySQL memory    : 15.2G
[--] Other process memory: 0B
[--] Total buffers: 1.4G global + 28.2M per thread (500 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[!!] Maximum reached memory usage: 1.7G (94.00% of installed RAM)
[!!] Maximum possible memory usage: 15.2G (845.58% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory
[OK] Slow queries: 0% (0/279K)
[OK] Highest usage of available connections: 2% (11/500)
[OK] Aborted connections: 1.50%  (2/133)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[!!] Query cache may be disabled by default due to mutex contention.
[!!] Query cache efficiency: 0.0% (0 cached / 1M selects)
[OK] Query cache prunes per day: 0
[OK] No Sort requiring temporary tables
[OK] No joins without indexes
[OK] Temporary tables created on disk: 0% (22 on disk / 37K total)
[OK] Thread cache hit rate: 90% (13 created / 133 connections)
[OK] Table cache hit rate: 95% (141 open / 147 opened)
[OK] Open file limit used: 1% (59/4K)
[OK] Table locks acquired immediately: 100% (108 immediate / 108 locks)

-------- Performance schema ------------------------------------------------------------------------
[--] Performance schema is disabled.
[--] Memory used by P_S: 0B
[--] Sys schema isn't installed.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 2 thread(s).
[--] Using default value is good enough for your version (10.3.17-MariaDB)

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.2% (24M used / 134M cache)
[OK] Key buffer size / total MyISAM indexes: 128.0M/123.0K
[OK] Read Key buffer hit rate: 98.9% (180 cached / 2 reads)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 4
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 1.0G/999.9M
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (99.609375 %): 340.0M * 3/1.0G should be equal to 25%
[!!] InnoDB buffer pool <= 1G and Innodb_buffer_pool_instances(!=1).
[--] Number of InnoDB Buffer Pool Chunk : 8 for 8 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 99.84% (26160668 hits/ 26202270 total)
[!!] InnoDB Write Log efficiency: 83.1% (617680 hits/ 743341 total)
[OK] InnoDB log waits: 0.00% (0 waits / 125661 writes)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is enabled.
[OK] Aria pagecache size / total Aria indexes: 128.0M/1B

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: MIXED
[--] XA support enabled: ON
[--] Semi synchronous replication Master: OFF
[--] Semi synchronous replication Slave: OFF
[--] This is a standalone server

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    Restrict Host for user@% to user@SpecificDNSorIp
    MySQL was started within the last 24 hours - recommendations may be inaccurate
    Reduce your overall MySQL memory footprint for system stability
    Dedicate this server to your database for highest performance.
    Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
    Performance schema should be activated for better diagnostics
    Consider installing Sys schema from https://github.com/mysql/mysql-sys for MySQL
    Consider installing Sys schema from https://github.com/good-dba/mariadb-sys for MariaDB
    Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (=0)
    query_cache_type (=0)
    query_cache_limit (> 1M, or use smaller result sets)
    performance_schema = ON enable PFS
    innodb_log_file_size should be (=85M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
    innodb_buffer_pool_instances (=1)

 


Perl로 작성된 쉘이 아래 주소에 있으며,

 

https://github.com/major/MySQLTuner-perl

 

major/MySQLTuner-perl

MySQLTuner is a script written in Perl that will assist you with your MySQL configuration and make recommendations for increased performance and stability. - major/MySQLTuner-perl

github.com

 

2019.08.14 

mysqltuner.pl
0.22MB

 

실행법

#> perl mysqltuner.pl --user root --pass='root'

 

지원하는 DB는

 

Test result are available here: Travis CI/MySQLTuner-perl

  • MySQL 8 (partial support, password checks don't work)
  • MySQL 5.7 (full support)
  • MySQL 5.6 (full support)
  • MariaDB 10.3 (full support)
  • MariaDB 10.2 (full support)
  • MariaDB 10.1 (full support)
  • MariaDB 10.0 (full support, 6 last month support)
  • Percona Server 5.7 (full support)
  • Percona Server 5.6 (full support)
  • Percona XtraDB cluster (full support)
  • MySQL 3.23, 4.0, 4.1, 5.0, 5.1, 5.5 (partial support - deprecated version)
  • Perl 5.6 or later (with perl-doc package)
  • Unix/Linux based operating system (tested on Linux, BSD variants, and Solaris variants)
  • Windows is not supported at this time (Help wanted !!!!!)
  • Unrestricted read access to the MySQL server (OS root access recommended for MySQL < 5.1)
  • CVE vulnerabilities detection support from https://cve.mitre.org

 

반응형
반응형


출처 : http://blog.naver.com/onlywin7788?Redirect=Log&logNo=140155221360

출처 : http://cafe.naver.com/ocmkorea/book2025209/9365


/*


--> 방식 1. (이 sql문은 이 방식임)

        1. 테이블 전체 목록 조회

           SQL> select * from tab;


        2. 수행한 쿼리의 Plan을 조회

           SQL> @xplan.sql


        3. 정확한 통계를 위해 힌트 실행

           SQL> select /*+ gather_plan_statistics */ * from tabs;


        * 오타 나지 않도록 주의함.


--> 방식 2

        1. 실행시 Plan  수집

           SQL> EXPLAIN FOR

                 SELECT * FROM TAB;


        2. 실제 정보 조회

           SQL> select * from tab(dbms_xplan.display());


                or


           SQL> select *

                from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST +alias +outline +predicate'))

/




--> 인자 정보


        dbms_xplan.display_cursor(인자1, 인자2, 인자3);


        인자1 : plan table 명을 입력하며, 따로 지정하지 않았을 때는 기본으로 'PLAN_TABLE'이다.


        인자2 : Execution Plan시 Set STATEMENT_ID를 지정한 경우 이를 불러올 수 있다.

                값이 Null일 경우 마지막에 실행된 문장을 불러온다.


        인자3 : 출력 포맷 형태 지정한다.



--> 세번째 인자의 포맷 정보


        1) 기본 Format Controller : 반드시 적용되어야 하는 기본적인 Controller임.

                                    적용하지 않더라도 자동으로 기본값으로 적용된다.


        -----------------------------------------------------------------------------------------------------------------------------------------------------------------------


                basic    : 가장 기본적인 포맷으로서 Id, Operation, Object Name을 출력한다.

                typical  : basic 옵션에서 한발 더 나아가서 Optimizer가 예상할 수 있는 모든 것을 보여준다.

                           출력되는 정보로는 예상 Rows, 예상 Bytes, 예상 Temporary Space 사용량, Cost 예상 시간 Predicate Imformat(Operation 별로 Access 및 Filter 정보)이다.

                serial   : typical과 같으나 Parallel 쿼리 사용시 관련정보가 나오지 않는다.

                all      : Plan 정보는 typical과 같으나 Plan이외의 정보 중에서 Outline Data 정보를 제외하고 전부 출력한다.

                advanced : all과 같지만 Peeked Binds, Outline Data, Note 등을 더 보여준다.


        -----------------------------------------------------------------------------------------------------------------------------------------------------------------------


        2) 세부 Format Controller : 기본 포맷정보에 의해서 표시되거나 생략되는 세부적인 포맷을 Control한다.

                                    이 Control은 +표시로 추가되거나 - 표시로 생략이 가능하다.


        -----------------------------------------------------------------------------------------------------------------------------------------------------------------------


                alias    : 가장 기본적인 포맷으로서 Id, Operation, Object Name을 출력한다.

                bytes    : basic 옵션에서 한발 더 나아가서 Optimizer가 예상할 수 있는 모든 것을 보여준다.

                           출력되는 정보로는 예상 Rows, 예상 Bytes, 예상 Temporary Space 사용량, Cost 예상 시간 Predicate Information (Operation 별로 Access 및 Filter 정보)이다.

                cost     : typical과 같으나 Parallel쿼리 사용시 관련 정보가 나오지 않는다.

                note     : Plan 정보는 typical과 같으나 Plan이외의 정보 중에서 Outline Data 정보를 제외하고 전부 출력한다.

                outline  : all과 같지만 Peeked Binds, Outline Data, Note 등을 더 보여준다.

                parallel : Parallel 쿼리인 경우 TQ, IN-OUT, PQ Distribute 등의 정보를 Control한다.

                partition : Partition Access가 포함된 경우

                peeked_binds : Bind 변수의 값을 control 한다. 단, _optim_peek_user_binds 파라미터의 값이 true로 되어 있는 경우에만 해당되며 파라미터는 세션 단위로 수정이

                               가능하다. (Explain Plan은 출력되지 않음)

                predicate : Predicate Information을 Control한다. Operation 별로 Access 및 Filter 정보를 나타낸다.

                            일반적인 튜닝시 가장 눈 여겨봐야 할 정보이다.

                projection : Projection Information을 Control한다. Operation 별로 Select 되는 컬럼 정보를 나타낸다.

                remote   : DB Link를 사용할 때 Remote 쿼리의 수행 정보를 Control한다.

                rows     : Plan상의 E-Rows 수를 Control한다.


        -----------------------------------------------------------------------------------------------------------------------------------------------------------------------


        3) 실행통계 Format Controller : 이 Control을 적용하면 실행시의 PGA 통계를 출력한다.


        이 정보들은 DBMS_XPLAN.DISPLAY 함수에는 적용되지 않는다.

        왜냐하면 Explain Plan은 실제 수행되는 것이 아니므로 실행통계정보가 없기 때문이다.


        또한 DBMS_XPLAN.DISPLAY_CURSOR 이나 DBMS_XPLAN.DISPLAY_AWR등의 함수 수행시에도 GATHER_STATISTICS 힌트를 주거나 아니면 STATISTICS_LEVEL 파라미터를 ALL로 설정해야 출력이 가능하다.


        -----------------------------------------------------------------------------------------------------------------------------------------------------------------------


                allstats : I/O 통계정보(Buffers, Reads, Writes)와 PGA 통계 정보(OMem, 1Mem, Used-Mem, Used-Tmp, Max-Tmp 등)를 동시에 Control 한다.

                iostats  : I/O 통계정보(Buffers, Reads, Writes)를 Control 한다.

                last     : 실행 통계 출력시 이 Control을 명시하면 가장 마지막에 수행된 실행 통계를 출력한다.

                           이 Control을 명시하지 않으면 실행 통계츼 누적치를 출력하므로 주의가 필요합니다.

                memstats : PGA 통계정보(OMem, 1Mem, Used-Mem, Used-Tmp, Max-Tmp등)를 동시에 Control한다.

                runstats_last : iostats과 last Control 과 동일하다.

                                이 Control은 Oracle 10g Release 1에서만 사용할 수 있다.

                runstats_tot : iostats Control과 동일하다.

                               이 Control은 oracle 10g Release 1 에서만 사용할 수 있다.


                * runstats_last와 runstats_tot를 제외한 4가지의 Control은 Oracle 10g Release 2 이상에서만 사용할 수 있다.


        -----------------------------------------------------------------------------------------------------------------------------------------------------------------------


        4) format 사용 예제


        Format중 가장 많은 정보를 출력 할 수 있는 포맷은 'advanced allstats last'이며 출력 가능한 모든 내용이 출력되게 되므로 상황이나, 자신에 맞는 포맷을 사용해야 적절함.


        4-1) 쿼리 변형이 없는 단순 쿼리 튜닝의 경우(최대한 단순한 포맷형태 사용)


             SQL> select * from table(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'allstats last-rows + predicate');


             => 포맷을 'allstats last-rows + predicate'로 주었으므로 예측 Row 수(E-row)가 생략되고 실행통계와 Predicate Information 만 출력된다.


        4-2) 쿼리 변형이 발생하거나 복잡한 쿼리 튜닝시 쿼리 블러과 힌트 정보를 추가로 출력


             SQL> select * from table(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'allstats last-rows + alias + outline + predicate');


             => 'allstats last-rows + alias + outline + predicate' 포맷을 사용하면 Query Block Name / Object Alias 정보와 Outline Data 정보가 추가로 출력된다.


                + alias는 쿼리블럭 정보를 추가하는 것이며, + Outline는 오라클이 내부적으로 사용하는 힌트정보 출력의 의미이다.


                쿼리 변형이 발생한 경우나 뷰(혹은 인라인뷰) 등을 튜닝할 경우 적합한 옵션이다.


        -----------------------------------------------------------------------------------------------------------------------------------------------------------------------



        10046 + tkprof 와 동일한 정보를 조회는

        select /*+ gather_plan_statistics */ * from tab;


        select *

        from table(dbms_xplan.display_cursor(null, null, 'advanced ALLSTATS LAST +alias +outline +predicate'))


        -----------------------------------------------------------------------------------------------------------------------------------------------------------------------



AWR 정보를 이용

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR(SQL_ID입력,NULL,NULL, 'ADVANCED ALLSTATS LAST'));


사용 권한 뷰


DISPLAY_CURSOR 함수 : V$SQL_PLAN, V$SESSION, V$SQL_PLAN_STATISTICS_ALL 뷰에 대한 SELECT 권한 필요

DISPLAY_AWR    함수 : DBA_HIST_SQL_PLAN, DBA_HIST_SQLTEXT, V$DATABASE 뷰에 대한 SELECT 권한 필요

DISPLAY_SQLSET 함수 : ALL_SQLSET_STATEMENTS, ALL_SQLSET_PLANS 뷰에 대한 SELECT 권한 필요


*/

select *

  from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST +alias +outline +predicate'))

/




반응형
반응형

10g에 추가된 Tuning Advisor


SQL ID 와 Begin SNAP 부분은 addm 을 통해 조회하여 입력하는 것이 좋음.(자동 생성 SH은 비밀글 참조...)


출처 : http://blog.daum.net/onjshop/175


★★ www.oraclejava3.co.kr 에서 더욱 유용한 정보를 확인하실 수 있습니다. ★★ 
(분당정자점은 양재, 강남에서 15분 거리에 있습니다. ^^)

Automatic SQL Tuning in Oracle Database 10g(SQL Tuning Advisor) 

이번 강좌에서는 오라클 10g의 새 특징인 자동 SQL 튜닝기능에 대해 알아 보도록 하겠습니다. 

Normal Mode에서 오라클 옵티마이저는 아주 짧은 시간에 최적의 실행 계획을 계산해 내야 합니다. 그러므로 항상 최선의 실행 계획을 만들어 낼 수는 없다 이겁니다~^^ 

Oracle 10g는 옵티마이저가 튜닝 모드에서 실행될 수 있도록 하여 추가적인 통계 정보를 모아 추후에는 튜닝된 최적의 실행 계획을 만들어 낼 수 있도록 지원 합니다. 물론 이러한 프로세스는 하나의 SQL문장에 대해 몇 분이 걸릴지도 모르므로 리소스를 많이 잡아 먹는 경향이 있습니다. 

튜닝모드에서 옵티마이저가 하는 일에 대해 정리해 볼까요? 

- 통계 분석(statistics Analysis) : 옵티마이저는 오래전에 만들어진 통계 정보나 또는 통계 정보가 없는 부분에 대해 통계 정보를 생산 하는 것을 권고 하며 SQL Profile안에 부가적인 객체에 대한 통계 정보를 저장 합니다. 

- SQL Profileing : CBO(Cost Base Optimizer)로 수행될 때 SQL문을 위해서는 부가 정보들이 필요 합니다. 이러한 SQL문의 정보들을 SQL 프로파일이라는 형태로 수집해 놓습니다. 이러한 SQL 프로파일이 필요할 때마다 SQL Tuning Advisor 에 의해 업데이트됩니다. 

- 실행 경로 분석(Access Path Analysis) : 어떤 인덱스를 통해 데이터를 접근하여 추출할지를 결정 합니다. 필요하다면 SQL Access Advisor를 호출해 인덱스에 대한 권고를 요구하기도 합니다. 

- SQL 구조 분석(SQL Structure Analysis) : SQL문이 비효율적인 실행 계획을 생성할 경우 같은 결과를 보여줄 수 있는 비슷한 SQL문을 생성해 권고하는 역할을 합니다. 

이러한 Automatic SQL Tuning 특징은 EM(Enterprise Manager)의 “Advisor Central” 을 이용해서도 사용 할 수 있으며 또한 PL/SQL의 DBMS_SQLTUNE 패키지를 이용해서도 사용 가능 합니다. 본 강좌에서는 PL/SQL에 초점을 맞추어서 진행토록 하겠습니다. 

SQL Tuning Advisor 

SQL Tuning API에 접근 하기 위해서는 ADVISOR라는 권한이 있어야 합니다. 

아래처럼 하면 됩니다. 

SQL>CONN sys/password AS SYSDBA 
SQL>GRANT ADVISOR TO scott; 
SQL>CONN scott/tiger 

SQL Tuning Advisor를 사용하기 위한 첫 번째 단계는 CREATE_TUNING_TASK를 이용하여 새로운 tuning task를 만드는 일입니다. 분석되고자 하는 SQL 문장은 AWR이나 CURSOR CACHE, SQL Tuning set 또는 매뉴얼하게 만들어져 검색 될 수 있습니다. 

SET SERVEROUTPUT ON 

-- Tuning task created for specific a statement from the AWR. 
DECLARE 
l_sql_tune_task_id VARCHAR2(100); 
BEGIN 
l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task ( 
begin_snap => 764, 
end_snap => 938, 
sql_id => '19v5guvsgcd1v', 
scope => DBMS_SQLTUNE.scope_comprehensive, 
time_limit => 60, 
task_name => '19v5guvsgcd1v_AWR_tuning_task', 
description => 'Tuning task for statement 19v5guvsgcd1v in AWR.'); 
DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id); 
END; 


-- Tuning task created for specific a statement from the cursor cache. 
DECLARE 
l_sql_tune_task_id VARCHAR2(100); 
BEGIN 
l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task ( 
sql_id => '19v5guvsgcd1v', 
scope => DBMS_SQLTUNE.scope_comprehensive, 
time_limit => 60, 
task_name => '19v5guvsgcd1v_tuning_task', 
description => 'Tuning task for statement 19v5guvsgcd1v.'); 
DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id); 
END; 


-- Tuning task created from an SQL tuning set. 
DECLARE 
l_sql_tune_task_id VARCHAR2(100); 
BEGIN 
l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task ( 
sqlset_name => 'test_sql_tuning_set', 
scope => DBMS_SQLTUNE.scope_comprehensive, 
time_limit => 60, 
task_name => 'sqlset_tuning_task', 
description => 'Tuning task for an SQL tuning set.'); 
DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id); 
END; 


-- Tuning task created for a manually specified statement. 
DECLARE 
l_sql VARCHAR2(500); 
l_sql_tune_task_id VARCHAR2(100); 
BEGIN 
l_sql := 'SELECT e.*, d.* ' || 
'FROM emp e JOIN dept d ON e.deptno = d.deptno ' || 
'WHERE NVL(empno, ''0'') = :empno'; 

l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task ( 
sql_text => l_sql, 
bind_list => sql_binds(anydata.ConvertNumber(100)), 
user_name => 'scott', 
scope => DBMS_SQLTUNE.scope_comprehensive, 
time_limit => 60, 
task_name => 'emp_dept_tuning_task', 
description => 'Tuning task for an EMP to DEPT join query.'); 
DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id); 
END; 



만약 TASK_NAME 파라미터에 값이 있다면 SQL tune task의 식별자로서 사용 되구요, 생략된다면 시스템에서 “TASK_1478” 등과 같이 만들어서 리턴 합니다. 

NVL이 SQL 문장에 사용되다면 옵티마이저로부터 반작용을 유발 하며 부가적으로 그러한 테이블에 관한 통계정보를 지우는 것도 가능 합니다. 

EXEC DBMS_STATS.delete_table_stats('SCOTT','EMP'); 

위에서 tuning task에 대해 정의를 했는데 그 다음으로 할 일은 EXECUTE_TUNING_TASK procedure를 이용하는 일 입니다. 

EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'emp_dept_tuning_task'); 

물론 아래처럼 task를 중단하거나 재시작 하거나 취소하거나 하는 것들이 가능 합니다. 

-- Interrupt and resume a tuning task. 
EXEC DBMS_SQLTUNE.interrupt_tuning_task (task_name => 'emp_dept_tuning_task'); 
EXEC DBMS_SQLTUNE.resume_tuning_task (task_name => 'emp_dept_tuning_task'); 

-- Cancel a tuning task. 
EXEC DBMS_SQLTUNE.cancel_tuning_task (task_name => 'emp_dept_tuning_task'); 

-- Reset a tuning task allowing it to be re-executed. 
EXEC DBMS_SQLTUNE.reset_tuning_task (task_name => 'emp_dept_tuning_task'); 
다음과 같이 tuning task는 DBA_ADVISOER_LOG라는 뷰를 통해서 확인 가능 합니다. 

SQL>SELECT task_name, status FROM dba_advisor_log WHERE owner = 'SCOTT'; 

TASK_NAME STATUS 
------------------------------ ----------- 
emp_dept_tuning_task COMPLETED 

tuning task가 성공적으로 수행 되면 REPORT_TUNING_TASK라는 함수를 통해 권고를 확인 할 수 있습니다. 

SET LONG 10000; 
SET PAGESIZE 1000 
SET LINESIZE 200 
SELECT DBMS_SQLTUNE.report_tuning_task('emp_dept_tuning_task') AS recommendations FROM dual; 
SET PAGESIZE 24 

결과는 아래와 같습니다. 

RECOMMENDATIONS 
-------------------------------------------------------------------------------- 
GENERAL INFORMATION SECTION 
------------------------------------------------------------------------------- 
Tuning Task Name : emp_dept_tuning_task 
Scope : COMPREHENSIVE 
Time Limit(seconds): 60 
Completion Status : COMPLETED 
Started at : 05/06/2004 09:29:13 
Completed at : 05/06/2004 09:29:15 

------------------------------------------------------------------------------- 
SQL ID : 0wrmfv2yvswx1 
SQL Text: SELECT e.*, d.* FROM emp e JOIN dept d ON e.deptno = d.deptno 
WHERE NVL(empno, '0') = :empno 

------------------------------------------------------------------------------- 
FINDINGS SECTION (2 findings) 
------------------------------------------------------------------------------- 

1- Statistics Finding 
--------------------- 
Table "SCOTT"."EMP" and its indices were not analyzed. 

Recommendation 
-------------- 
Consider collecting optimizer statistics for this table and its indices. 
execute dbms_stats.gather_table_stats(ownname => 'SCOTT', tabname => 
'EMP', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, 
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE) 

Rationale 
--------- 
The optimizer requires up-to-date statistics for the table and its indices 
in order to select a good execution plan. 

2- Restructure SQL finding (see plan 1 in explain plans section) 
---------------------------------------------------------------- 
The predicate NVL("E"."EMPNO",0)=:B1 used at line ID 2 of the execution plan 
contains an __EXPRESSION!__ on indexed column "EMPNO". This __EXPRESSION!__ prevents 
the optimizer from selecting indices on table "SCOTT"."EMP". 

Recommendation 
-------------- 
Rewrite the predicate into an equivalent form to take advantage of 
indices. Alternatively, create a function-based index on the __EXPRESSION!__. 

Rationale 
--------- 
The optimizer is unable to use an index if the predicate is an inequality 
condition or if there is an __EXPRESSION!__ or an implicit data type conversion 
on the indexed column. 

------------------------------------------------------------------------------- 
EXPLAIN PLANS SECTION 
------------------------------------------------------------------------------- 

1- Original 
----------- 
Plan hash value: 1863486531 

---------------------------------------------------------------------------------------- 
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
---------------------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT | | 1 | 107 | 4 (0)| 00:00:01 | 
| 1 | NESTED LOOPS | | 1 | 107 | 4 (0)| 00:00:01 | 
| 2 | TABLE ACCESS FULL | EMP | 1 | 87 | 3 (0)| 00:00:01 | 
| 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 20 | 1 (0)| 00:00:01 | 
| 4 | INDEX UNIQUE SCAN | PK_DEPT | 1 | | 0 (0)| 00:00:01 | 
---------------------------------------------------------------------------------------- 

Note 
----- 
- dynamic sampling used for this statement 

------------------------------------------------------------------------------- 


1 row selected. 

Tuning task는 다음처럼 DROP 합니다. 

BEGIN 
DBMS_SQLTUNE.drop_tuning_task (task_name => '19v5guvsgcd1v_AWR_tuning_task'); 
DBMS_SQLTUNE.drop_tuning_task (task_name => '19v5guvsgcd1v_tuning_task'); 
DBMS_SQLTUNE.drop_tuning_task (task_name => 'sqlset_tuning_task'); 
DBMS_SQLTUNE.drop_tuning_task (task_name => 'emp_dept_tuning_task'); 
END; 

 

반응형

'Database > ORACLE' 카테고리의 다른 글

one port multi listener 설정 하기  (0) 2012.12.24
DBMS_XPLAN 정보 조회  (0) 2012.09.07
10G OCP 자격증 관련  (2) 2012.07.08
오라클 패키지 CURSOR(커서) 출력 값 조회  (0) 2012.02.23
일정 시간 별로 쿼리 정보 조회  (0) 2012.02.20
반응형


VMWARE에 XP를 깔아서 사용하는데...

속도가 무진장 느린것이 문제였다..

외국사이트에 많은 내용이 있었는데

그 중 효과가 있는것들만 추려본다.

1. Disable Memory Page Trimming
  VMWARE에서 사용하고 난 뒤 사용하지 않는 자원을 환원하는 작업을 끈다. (가상시스템 작업량을 줄인다.)
  (Select: VM > Settings > Options > Advanced > Disable memory page trimming  체크 함)

2. Disable real-time anti-virus protection (실시간 바이러스 백신 보호를 사용하지 말아라)
   실시간으로 바이러스 백신을 켜두는 것은 도움이 되지 않는다.
   차라리 VMWARE 파일 자체를 실시간 바이러스 검사를 하라

3. Disable memory sharing
   VMWARE 상에서 메모리와 다른 응용 프로그램간에 메모리 공유 금지 옵션 추가
    .vmx 파일내에 다음 라인 추가
   sched.mem.pshare.enable = “FALSE”


세가지 모두를 적용했더니... 왠만큼의 성능이 나온다 ~ 좋다 !

출처 : http://vivekagarwal.wordpress.com/2008/07/08/improving-vmware-server-performance-on-windows-xp/
반응형

'UTILITY' 카테고리의 다른 글

VI 완전 정복하기  (1) 2011.01.06
vmplayer 3.1.1 개인용  (1) 2010.12.10
Windows에서 Mac 주소 바꾸기(변경)  (0) 2010.12.06
VMWARE 게임가드 회피...  (1) 2010.12.03
VMWARE 7.1.2 32 and 64 bit ~  (0) 2010.12.02
반응형

앞선 IBM JVM 튜닝 - 2 포스팅에서 AF를 줄이는 방안을 연구해 보자고 했다.

AF란 결국 아래의 두 논리의 경합이다.
1. heap memory상에는 움직일수 없는 객체들이 존재한다. (unmovable objects)
2. heap memory에 객체가 할당되기 위해서는 연속된 memory공간이 필요하다. (contiguous memory block)

여기서 '움직일수 없는 객체(unmovable object)'의 두가지 type에 대해 살펴보도록 하자.

pinned objects

  • java heap 영역이 아닌 space로 부터 참조를 당하고 있는 객체들을 말한다.
    (여기서 java heap 영역이 아닌 space란 말은 native heap, thread stack등의 영역을 의미하는데 이는 포스팅 진행중 설명하겠다.)
  • jvm 내부 스트럭처의 일부분 혹은, jni의 내부의 변수, 혹은 다른 pinned objects등에 의해 reference를 가진 객체를이 해당된다.

dosed objects

  • 순간적으로 pinned objects화 된 객체등을 의미한다.
  • java 코드내의 local variable, 혹은 method 간의 호출에 사용되는 parameter 객체들이 될 수있다.
  • GC Thread가 돌때, 위에서 설명한 dosed object들은 active로 간주되어 GC의 대상에서 벗어나게 되고,이후 GC Thread에 의해서 reference 참조 여부가 결정된 후, 일반 객체처럼 수거된다.

아래의 그림을 보면 쉽게 이해가 갈 것이다.

이러한 unmovable objects들 중, 다행히 dosed object들은 생명이 짧다. 따라서 곧 mark-sweep될 가능성이 많다.
하지만, 문제는 pinned object들 이다. 이 녀석들은 대부분 긴 생명력을 자랑하면서, 제한된 Heap 공간에 자기 멋대로 자리를 틀어 버리기 때문이다.
필연적으로 이러한 pinned objects들이 다수 존재하게 되면, 그만큼 AF가 발생할 확률이 높다는 말이 된다.

그렇다면, 어떠한 방법이 있을까?

사례 1) Heap사용률은 높지 않지만, 다수의 pinned object에 의해 AF가 발생.
이경우는, pinned objects들만 사용할 수 있는 전용공간을 Heap상에 만들어 주면 된다.
이때 사용되는 대표적인 옵션은 아래와 같다.
-Xknnn  -Xpiii[k][,ooo[k]] 

  • nnn is the maximum number of classes used by the application,
  • iii is the size of the primary pinned cluster, 
  • ooo is the size of the overflow pinned clusters in bytes, and
  • Using k changes value from bytes to kilobytes.

윗 영문해설은 'ibm'사이트에서 발췌한 항목에 대한 설명인데, 개인적으로는 다음과 같이 이해하고 있다.
 'nnn'은 메모리에 로딩된 application class의 총 개수를 의미하며, 'iii'는 pinned objects를 연속된 공간에 묶기 위한 cluster된 공간의 크기인데, WAS등이 부팅되면서 로딩시키는 class들 중, pinned성격의 object들이 먼저 위치하는 공간의 크기를 의미하며, 'ooo'는 JVM Runtime시 종종 생성되고 사라지는 pinned object들이 위치하는 공간이다.
통상, -Xk로 표현되는 옵션을 'KCluster'라고 부르며, -Xp로 표현되는 옵션을 'PCluster'라고 부른다.

통상적인 경우, 1.3.1_07 이상 및 1.4.2 이상의 ibm jdk에서는 이를 산출하기 위한 back data를 볼 수 있는 옵션을 제공하고 있다.

  • 1.3.1_07 이상의 1.3대 jvm
    -verbosegc -Xtgc2
  • 1.4.2 이상의 jvm
    -verbosegc -Dibm.dg.trc.print=st_verify

위의 설정이 작동하게 되면, standard out 에 아래와 같은 로그가 찍히게 된다.
<GC(VFY-SUM): pinned=3000(classes=2755/freeclasses=0) dosed=9388 movable=1045582 free=3340>
해석해 보면, 총 2755개의 application class들이 로딩되어 있으며, 이중 unmovable object로는 pinned objects가 3000개, 그리고 순간 pinned화 된 dosed object가 9388개 존재한다. 기타 movable한 object는 1045582개 존재하며, mark가 끊긴 object들은 3340개 존재한다.

위와같은 로그를 획득하였다면, -Xk와 -Xp의 sizing을 해 보자.

  • -Xk sizing
    통상적으로 로딩된 class개수의 10%정도를 더 설정해 주는 것을 권고한다. 위의 data를 기반으로 산출해 보면 아래와 같다.
    2755 + (2755x0.1) = 3030, 따라서 -Xk3030과 같이 설정한다.
  • -Xp sizing
    이부분에 대한 명쾌한 설명을 하고 있는 자료를 본적이 없다. IBM에서도 아래와 같이 설명하고 있다.
    If the problem still persist after setting a -Xk value then you may want to look at setting  -Xp as well and examining the application code to see if you can reduce the size of the larger objects that are being requested.
    Sizing the -Xp option is a complex task and should only be done with assistance from IBM Support.


    위에서 설명한데로, -Xpiii[k][,ooo[k]]형식이 되는데, 'iii'는 pinned objects를 연속된 공간에 묶기 위한 cluster된 공간의 크기인데, WAS등이 부팅되면서 로딩시키는 class들 중, pinned성격의 object들이 먼저 위치하는 공간의 크기를 의미하며, 'ooo'는 JVM Runtime시 종종 생성되고 사라지는 pinned object들이 위치하는 공간으로 이해한다.

    따라서, -Xk옵션으로 별다른 개선효과가 없다면, AF가 발생했을 당시의 gc로그를 기반으로, AF를 유발한 object 크기를 유형별로 산출하여, 단위시간에 몰리는 object크기의 총 합정도를 설정하여, 반복테스트를 통하여 가장 좋은 성능을 발휘하는 임계치를 찾는 방법을 사용해야 할 것 같다.

사례 2) unmovable obejcts는 많지 않지만, 다수의 dosed objects들에 의한 AF발생.

  • -Xcompactgc
    모든 GC사이클 수행시마다, compact를 수행한다. 성능은 크게 감소할 것을 감수해야 한다.
    하지만, 해당 옵션을 활성화 시켜서 AF가 많이 줄어 든다고 판단되면, dosed objects들에 의한 AF가 많다라고 간주하는데 판단기준이 될 수 있다.
  • -Xpartialcompatgc
    compact trigger가 자주 발생한다. 즉, 기존의 full compaction을 점진적(incremental)으로 진행한다.
    비활성화는 -Xnopartialcompactgc로 설정하면 되고, full compaction 모드로 작동하게 된다.
  • -Xgcpolicy
    IBM JVM 튜닝 - 1 을 참조한다.

사례 3) unmovable obejcts는 많지 않지만, 다수의 large size objects들에 의한 AF발생.
large object를 위한 loa(large object area)영역을 지정한다.

  • jdk 1.4 이상
    -Xloratio : loa 영역의 크기를 백분률로 지정한다. 
                   loa 영역을 지정한 경우, 통상적으로 Xmx영역을 일정비율 늘려줘야 한다. 
                   공식은 아래와 같다.               
                                       New Xmx = Current Xmx / (1 - loratio)
  • jdk 1.5이상
    -Xloa : 64k 이상의 large object들만을 담는 loa(large object area)를 활성화 한다.
    -Xloainitial : loa영역의 초기 백분률로 0~0.95의 수치를 지정한다. 기본값은 0.05(5%)이다.
    -Xloamaximum : loa영역의 최대 백분률로 0~0.95의 수치를 지정한다. 기본값은 0.5(50%)이다.



포스팅을 마무리하고 보니, IBM JVM 튜닝중 AF쪽에 포커스가 맞추어 진 느낌이다.
다음에는 IBM JVM 전반에 걸쳐 포스팅을 해볼까 한다.

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

'WAS > JEUS' 카테고리의 다른 글

JEUS 5 세션 공유  (0) 2011.03.09
JEUSMain.xml Datasource 암호 설정  (0) 2011.01.13
제우스 환경 설정 부분  (0) 2009.03.05
JAVA HEAPDUMP 분석방법  (0) 2009.03.05
웹상에서 제우스 로그 확인하기  (0) 2009.03.05

+ Recent posts