Skip to content
컴퓨터잡담
2010.04.13 19:01

mysql threads_created 뭐냥?

조회 수 10572 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

mysql threads_created  뭐냥?


http://eureka7.com.ne.kr/MySQL_4_1_API/show-status.html




SHOW STATUS 은 , 서버의 스테이터스 정보를 제공합니다 (mysqladmin extended-status 와 같이 ). 출력은 이하와 같이 됩니다 (형식과 수치는 경우에 따라서 다릅니다 ).

+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| Aborted_clients          | 0          |
| Aborted_connects         | 0          |
| Bytes_received           | 155372598  |
| Bytes_sent               | 1176560426 |
| Connections              | 30023      |
| Created_tmp_disk_tables  | 0          |
| Created_tmp_tables       | 8340       |
| Created_tmp_files        | 60         |
| Delayed_insert_threads   | 0          |
| Delayed_writes           | 0          |
| Delayed_errors           | 0          |
| Flush_commands           | 1          |
| Handler_delete           | 462604     |
| Handler_read_first       | 105881     |
| Handler_read_key         | 27820558   |
| Handler_read_next        | 390681754  |
| Handler_read_prev        | 6022500    |
| Handler_read_rnd         | 30546748   |
| Handler_read_rnd_next    | 246216530  |
| Handler_update           | 16945404   |
| Handler_write            | 60356676   |
| Key_blocks_used          | 14955      |
| Key_read_requests        | 96854827   |
| Key_reads                | 162040     |
| Key_write_requests       | 7589728    |
| Key_writes               | 3813196    |
| Max_used_connections     | 0          |
| Not_flushed_key_blocks   | 0          |
| Not_flushed_delayed_rows | 0          |
| Open_tables              | 1          |
| Open_files               | 2          |
| Open_streams             | 0          |
| Opened_tables            | 44600      |
| Questions                | 2026873    |
| Select_full_join         | 0          |
| Select_full_range_join   | 0          |
| Select_range             | 99646      |
| Select_range_check       | 0          |
| Select_scan              | 30802      |
| Slave_running            | OFF        |
| Slave_open_temp_tables   | 0          |
| Slow_launch_threads      | 0          |
| Slow_queries             | 0          |
| Sort_merge_passes        | 30         |
| Sort_range               | 500        |
| Sort_rows                | 30296250   |
| Sort_scan                | 4650       |
| Table_locks_immediate    | 1920382    |
| Table_locks_waited       | 0          |
| Threads_cached           | 0          |
| Threads_created          | 30022      |
| Threads_connected        | 1          |
| Threads_running          | 1          |
| Uptime                   | 80380      |
+--------------------------+------------+

상기의 스테이터스 변수에는 각각 이하와 같은 의미가 있습니다.

변수의미
Aborted_clients접속을 닫기 전에 클라이언트가 종료해 버렸기 때문에 중단된 접속수. See 항A.2.10. 「통신 에러/Aborted connection」.
Aborted_connectsMySQL 서버에의 접속 시행 실패 회수. See 항A.2.10. 「통신 에러/Aborted connection」.
Bytes_received모든 클라이언트로부터 수신한 아르바이트수.
Bytes_sent모든 클라이언트에 송신된 아르바이트수.
Com_xxx각 xxx 커멘드의 실행 회수.
ConnectionsMySQL 서버에의 접속 시행 회수.
Created_tmp_disk_tables스테이트먼트 실행중에 , 디스크상에 작성된 암묵적 텐포라리테이불의 수.
Created_tmp_tables스테이트먼트 실행중에 , 메모리상에 작성된 암묵적 텐포라리테이불의 수.
Created_tmp_filesmysqld 하지만 작성한 임시 파일의 수.
Delayed_insert_threadsINSERT DELAYED 핸들러 thread의 수.
Delayed_writesINSERT DELAYED 그리고 기입해진 레코드의 수.
Delayed_errors에러 발생(중복 키의 가능성이 높다 )에 의해 ,INSERT DELAYED 그리고 기입해진 레코드의 수.
Flush_commandsFLUSH 커멘드의 실행 회수.
Handler_commit내부 COMMIT 커멘드수.
Handler_delete테이블에서 레코드가 삭제된 회수.
Handler_read_first최초의 엔트리가 인덱스로부터 읽어내진 회수. 이 값이 큰 경우 , 서버가 몇번이나 풀 인덱스 스캔을 실행하고 있다고 생각된다. 예를 들면 ,SELECT col1 FROM foo 을 실행했을 때에 col1 가 인덱스가 되어 있으면(자) 그렇게 된다.
Handler_read_key키에 근거하는 레코드 독해 요구의 회수. 이 값이 큰 경우 , 쿠에리 및 테이블이 적절히 인덱스화 되고 있다고 생각된다.
Handler_read_next키 순서에서의 다음의 레코드의 독해 요구의 회수. 범위 지정을 해 인덱스 컬럼에 대해서 쿠에리를 실행하면(자) , 이것이 인크리먼트(increment) 된다. 인덱스 스캔을 실행해도 인크리먼트(increment) 된다.
Handler_read_prev키 순서에서의 전의 레코드의 독해 요구의 회수. 이것은 주로 ,ORDER BY ... DESC 를 최적화하는데 사용된다.
Handler_read_rnd고정 위치에 근거하는 레코드 독해 요구의 회수. 결과의 소트를 필요로 하는 쿠에리를 많이 실행하면(자) , 이 값이 커진다.
Handler_read_rnd_next데이터 파일에서의 다음의 레코드의 독해 요구의 회수. 테이블 스캔이 많이 실행되면(자) , 이 값이 커진다. 이 경우 , 일반적으로 , 테이블이 적절히 인덱스화되어 있지 않은지 , 쿠에리가 인덱스를 유효하게 이용하고 있지 않는가를 의미한다.
Handler_rollback내부 ROLLBACK 커멘드수.
Handler_update테이블내의 레코드의 갱신 요구 회수.
Handler_write테이블에의 레코드의 삽입 요구 회수.
Key_blocks_used키 캐쉬의 사용 블록수.
Key_read_requests캐쉬로부터의 키 블록 독해 요구 회수.
Key_reads디스크로부터의 키 블록의 물리적 독해 회수.
Key_write_requests캐쉬에의 키 블록의 기입 요구 회수.
Key_writes디스크에의 키 블록의 물리적 기입 회수.
Max_used_connections동시 사용 가능한 최대 접속수.
Not_flushed_key_blocks변경되었지만 , 디스크에의 플래시는 아직되어 있지 않은 키 캐쉬의 키 블록.
Not_flushed_delayed_rowsINSERT DELAY 큐로 기입을 기다리고 있는 레코드의 수.
Open_tables열려 있는 테이블의 수.
Open_files열려 있는 파일의 수.
Open_streams열려 있는 시냇물의 수(주로 로그용으로 사용).
Opened_tables열린 테이블의 수.
Rpl_statusfail-safe인 replication의 스테이터스( 아직 사용되어 있지 않다 ).
Select_full_join키를 사용하지 않는 결합의 수(이 값이 0 나오지 않는 경우 , 테이블의 인덱스를 체크할 필요가 있다 ).
Select_full_range_join참조 테이블로 범위 지정의 검색을 사용한 결합의 수.
Select_range최초의 테이블의 범위 지정된 부분만을 사용한 결합의 수(통상 , 이 값이 커도 문제는 되지 않는다 ).
Select_scan최초의 테이블로 풀 스캔을 실시한 결합의 수.
Select_range_check각 레코드의 다음에 키 사용을 체크하는 , 키를 사용하지 않는 결합의 수(이 값이 0 나오지 않는 경우 , 테이블의 인덱스를 체크할 필요가 있다 ).
Questions서버에 송신된 쿠에리의 수.
Slave_open_temp_tables슬레이브 thread에 의해 현재 열리고 있는 텐포라리테이불의 수.
Slave_running마스터에 접속되고 있는 슬레이브의 경우는 ON.
Slow_launch_threads생성에 slow_launch_time 보다 시간이 걸린 thread의 수.
Slow_querieslong_query_time 초부터 시간이 걸린 쿠에리의 수. See 항4.10.5. 「슬로우 쿠에리 로그」.
Sort_merge_passes소트 알고리즘으로 필요했던 머지 패스의 회수. 이 값이 크면 ,sort_buffer 의 값을 크게 하는 것을 고려해야 한다.
Sort_range범위 지정으로 행해진 소트의 회수.
Sort_rows소트 된 레코드의 수.
Sort_scan테이블의 스캔에 의해 실행된 소트의 회수.
ssl_xxxSSL 에 의해 사용되는 변수( 아직 도입되어 있지 않다 ).
Table_locks_immediate테이블 락이 곧바로 실행된 회수. 3.23.33 그리고 도입.
Table_locks_waited테이블 락이 곧바로는 실행되지 않고 , 대기가 필요했던 회수. 이 값이 큰 경우 , 퍼포먼스상의 문제가 있다. 우선 쿠에리를 최적화해 , 다음에 테이블을 분할할까 replication를 사용해야 한다. 3.23.33 그리고 도입.
Threads_cachedthread 캐쉬내의 thread수.
Threads_connected현재 열려 있는 접속의 수.
Threads_created접속을 처리하기 위해서 작성된 thread의 수.
Threads_runningsleeve 상태로 되어 있지 않은 thread의 수.
Uptime서버의 가동초수.

보충 코멘트

  • Opened_tables 치가 큰 경우 ,table_cache 변수가 너무 작다고 생각된다.

  • Key_reads 값이 큰 경우 ,key_buffer_size 변수가 너무 작다고 생각된다. 캐쉬 미스 레이트는 ,Key_reads/Key_read_requests 그리고 계산된다.

  • Handler_read_rnd 값이 큰 경우 ,MySQL 가 테이블 전체를 스캔 할 필요가 있는 쿠에리가 너무 많은지 , 키를 적절히 사용하지 않는 결합이 있다고 생각된다.

  • Threads_created 값이 큰 경우 ,thread_cache_size 변수를 크게 하는 것을 고려해야 한다. 캐쉬 히트 레이트는 ,Threads_created/Connections 그리고 계산된다.

  • Created_tmp_disk_tables 값이 큰 경우 ,tmp_table_size 변수를 크게 해 , 디스크 베이스는 아니고 메모리베이스로 텐포라리테이불을 취득할 수 있도록(듯이) 한다.





    [thread_cache_size]


    많이 헷갈리는 이 부분에 대해서 설명합니다.


    먼저 이 값은 bytes 단위 등의 크기가 아닙니다.

    정수 단위의 '수'를 의미합니다.

    (mysql에서 단위를 헷갈리게 하는 부분임)


    mysql 클라이언트가 mysql 서버에 접속할때(Connections)

    thread를 생성하는데 cache에 thread가 있으면 생성하지

    않고 그 thread 를 사용합니다.


    클라이언트에서 접속이 끊어지면(disconnects) MySQL 서버는

    이전의 클라이언트 thread 수가 thread_cache_size 값보다

    작으면 현재 thread를 cache 에 올려놓습니다.


    cache에 올려놓은 thread는 Threads_cached로 확인할 수

    있습니다.(이 정보가 빠져있군요)


    cache에 있는 thread 재사용수 설정 ==> thread_cache_size

    입니다. 즉 얼만 만큼의 thread 수를 cache에 올려놓을

    것인지 결정하는 항목입니다.


    여기에서 cache에 있는 thread를 사용하지 않고

    새로운 thread가 생성되면 Threads_created 값이 1씩

    증가하고, cache에 있는 thread를 사용할 경우는

    Threads_created 값은 증가하지 않습니다.


    기준은 Questions가 아니고 Connections 입니다.


    즉 Connections 값과 Threads_created 값, 그리고

    현재 MySQL 서버가 얼마정도로 바쁜지를 파악하여

    이 thread_cache_size 값을 조절해 줘야 합니다.


    기본값은 thread_cache_size = 0 입니다.


    이 의미는 Connections 이 이루어질때 cache에 있는

    thread를 사용하지 말고 새로운 thread를 생성하여 사용

    하라는 의미입니다.


    즉 매우 바쁜 MySQL 서버가 아니면 0 또는 2 값 정도면

    충분합니다.


    그러나 MySQL 서버가 상당히 바쁘고(STATUS == busy 이상)

    이 값이 작으면 Connections이 이루어질때마다 새로운

    thread가 생성된다는 단점(?)이 있습니다.


    MySQL 영문 매뉴얼에서는 Threads_created 값이 크면(big)

    thread_cache_size 값을 올려주라고 권고하지만

    얼마만큼이 그 기준인지에 대해서는 따로 언급이 없습니다.


    다만 (Threads_created / Connections)값을 계산해 보라는

    정도입니다.



    그렇다면 성능면측에서 생각해보면,

    서버가 상당히 바쁘면 새로운 thread 를 생성하여 사용하는

    것 보다는 기존의 cache 에 있는 thread를 재사용하는

    것이 더 유리합니다.


    그러나 성능 좋은 thread 실행(implementation) 시스템에서는

    그리 크게 낫은 성능은 없습니다.


    어째튼 서버가 매우 바쁜 정도라면 이 값을 어느 정도까지

    올려주는 것이 좋습니다.


    본 프로그램에서는 (Threads_created / Connections)값이

    0.01 즉 1% 이상이면 thread_cache_size 값을 올려주라고

    comments하고 있습니다.


    보통 none interactive 모드에서,

    하나의 커넥션이 맺어지고 exit 까지는 대략 1초 미만이 대부분입니다.

    길게 1초라고 가정하고,


    얼마자 자주 커넥션이 들어오는지(초당 커넥션)를 계산하면,


      커넥션 관련 통계

      (

          cps = Connecions / Uptime    ; // 초당 커넥션 수

          spc = Uptime / Connections   ; // 커넥션 주기(초)

          cpq = Question / Connections ; // 커넥션당 요청 쿼리 수

      )


    cps 값으로 알 수 있습니다.


    평균적인 계산이기 때문에 이 cps 값이 필요로 하는 thread_cache_size

    값이 됩니다. 이 cps 값도 한계가 있죠.. max_connections 이 제한점이기

    때문에..


    따라서,


      ccps  : ceil(Connecions / Uptime); // 올림

      최소 : (1 초 * ccps) + 0

      권장 : (2 초 * ccps) + 1

      최대 : (3 초 * ccps) + 2

      극대 : (4 초 * ccps) + 3


    이 정도로 계산하면 됩니다.


    단, 계산된 thread_cache_size 도 한계가 있습니다.

    당연히 max_connections 보다 작아야 하고, 1 절에서 구한 LTP 에 의해서

    (LPT * cps) 보다 작아야 합니다.

    또한 back_log 보다 작아야 합니다.



    [thread_cache_size 값을 설정하는 방법]


    1. MySQL 4.0.3 이상이면


    mysql> SET GLOBAL thread_cache_size = 8;


    2. MySQL 4.0.3 이하이면


    shell> mysqladmin [OPTIONS] shutdown

    shell> safe_mysqld -O thread_cache_size=8 &


    또는 /root/.my.cnf

    [mysqld]

    ...

    set-variable    = thread_cache_size=8

    ...


    이렇게 추가하고


    shell> safe_mysqld &


    3. 시스템 재부팅시 자동으로 설정해 줄 경우


    /etc/rd.c/rc.local 파일 이용시


    safe_mysqld -O thread_cache_size=8 &


    권장 방법


    safe_mysqld --defaults-file=/root/.my.cnf &


    *주의)

    rc.local 파일에 `safe_mysqld &` 이와 같이 입력하면

    /root/.my.cnf 내용을 참조하지 못하는 경우가 있으므로

    --defaults-file=/root/.my.cnf 옵션을 추가해 주는 것이

    좋습니다.





로그인 후 댓글쓰기가 가능합니다.

?

http://urin79.com

우린친구블로그

sketchbook5, 스케치북5

sketchbook5, 스케치북5

나눔글꼴 설치 안내


이 PC에는 나눔글꼴이 설치되어 있지 않습니다.

이 사이트를 나눔글꼴로 보기 위해서는
나눔글꼴을 설치해야 합니다.

설치 취소