MYSQL 튜닝
DB CAFE
thumb_up 추천메뉴 바로가기
- DBA { Oracle DBA 명령어 > DBA 초급 과정 > DBA 고급 과정 }
- 튜닝 { 오라클 튜닝 목록 }
- 모델링 { 데이터 모델링 가이드 }
목차
1 MySQL 데이터베이스 최적화 성능 튜닝[편집]
1.1 MySQL 모니터링과 서버 튜닝[편집]
1.1.1 MySQL 데이터베이스 모니터링[편집]
- 튜닝의 시작은 현재 시스템의 상태와 문제점을 파악하는 것이 가장 우선
- MySQL을 모니터링하는 방법은 3가지
- 첫째로 커맨드라인 명령어들을 이용해 모니터링
- 두번째는 GUI 기반의 관리 툴인 MySQL Administrator를 통한 모니터링
- 세번째 MySQL이 남긴 각종 로그를 통한 모니터링
1.1.1.1 커맨드라인 명령어들을 통한 모니터링[편집]
- 커맨드라인 명령어들을 통한 모니터링의 가장 큰 장점은 어떤 환경에서도 수행이 가능하며 가장 빠르고 정확하게 자신이 원하는 바를 알아낼 수 있다는 것
- MySQL의 커맨드라인 프로그램 과 SHOW 명령어들
1.1.1.2 mysqladmin[편집]
- mysqladmin은 MySQL 데이터베이스의 커맨드라인 기반인 관리자 프로그램
- Mysqladmin을 통해 시스템의 현재 설정 상황과 동작 상황을 모니터링할 수 있다.
1) Mysqladmin 명령어
extended-status MySQL 데이터베이스의 현재 상황을 보여준다.
flust-hosts MySQL에 캐시된 모든 포스트를 초기화한다.
flust-logs MySQL의 로그 파일을 새로 작성하며 초기화한다.
flust-status MySQL의 상태정보를 초기화한다.
flust-tables MySQL에 캐싱된테이블 정보를 초기화한다.
flust-thread 쓰레드 캐시에 저장된 쓰레드를 초기화한다.
flust-privileges 권한정보 테이블을 다시 읽는다.
kill id 특정 MySQL 프로세스를 죽인다.
Processlist 현재 MySQL 프로세스 목록은 본다.
Refresh 현재 캐시되어 있는 모든 테이블을 초기화하고 log 파일은 새로 만든다.
Variables 설정 가능한 모든 변수를 보여줍니다.2) SHOW VARIABLES 로 본 설정
- SHOW STATUS롤 통해 본 서버의 사용 통계
- SHOW ENGINES
- MySQL의 가장 큰 특징 중 하나는 여러 가지 스토리지 엔진을 가지고 있다는 것이다.
- 이 명령은 현재 MySQL의 시스템이 어떤 스토리지 엔진을 사용할 수 있는지 보여준다.
mysql >SHOW ENGINES
+----------------+---------+----------------------------------------------------------------+
| Engine | Support | Comment |
+----------------+---------+----------------------------------------------------------------+
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance |
| HEAP | YES | Alias for MEMORY |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables |
| MERGE | YES | Collection of identical MyISAM tables |
| MRG_MYISAM | YES | Alias for MERGE |
| ISAM | NO | Obsolete storage engine, now replaced by MyISAM |
| MRG_ISAM | NO | Obsolete storage engine, now replaced by MERGE |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys |
| INNOBASE | YES | Alias for INNODB |
| BDB | NO | Supports transactions and page-level locking |
| BERKELEYDB | NO | Alias for BDB |
| NDBCLUSTER | NO | Clustered, fault-tolerant, memory-based tables |
| NDB | NO | Alias for NDBCLUSTER |
| EXAMPLE | NO | Example storage engine |
| ARCHIVE | YES | Archive storage engine |
| CSV | NO | CSV storage engine |
| BLACKHOLE | NO | Storage engine designed to act as null storage |
+----------------+---------+----------------------------------------------------------------+- SHOW VARIABLES
MySQL은 설정 가능한 값들을 엄청나게 많이 가지고 있으며 SHOW VARIABLE 명령을 통해 현재 설정되어 있는 모든 값을 볼 수 있다.
SHOW VARIABLES로 볼 경우 총 207개 정도의 변수가 표시된다. 오히려 너무 많아서 원하는 값을 찾기가 힘들 정도이다. 그래서 SHOW VARIABLES 명령 뒤에 LIKE ‘%키워드%’를 사용하면 원하는 값만을 볼 수 있다.
- SHOW STATUS
MySQL은 내부적으로 동작 상황에 대한 실시간 통계 정보를 가지고 있다. SHOW STATUS는 이러한 통계 정보를 보기 위한 명령이다. 모니터링할 때 가장 기본이 되는 것이 바로 앞에서 설명한 SHOW VARIABLES의 정보와 SHOW STATUS의 정보이다. 웹 기반의 모니터링 툴을 비롯한 각종 모니터링 툴들이 바로 이 두 명령어를 통해 나온 정보를 조합해 사용하는 것이다. SHOW STATUS도 SHOW VARIABLES와 마찬가지로 LIKE ‘%키워드%’ 사용해 원하는 값만을 볼 수 있다.
- SHOW PROCESSLIST
현재 동작하고 있는 MySQL 데이터베이스 서버의 동작중인 모든 쓰레드와 유저 커넥션 정보를 보기 위한 명령어이다. 이를 통해 얻어진 정보로 시스템 자원을 지나치게 많이 사용하거나 잘못된 수행을 하고 있는 프로세스를 죽일 수 있다.
- SHOW TABLE/TABLE STATUS/INDEX/INNODB STATUS
SHOW TABLE 명령은 현재 데이터베이스에 존재하는 테이블에 대한 기본적인 정보를 보여주며 SHOW TABLE STATUS는 각 테이블의 생성 일자, 테이블 크기, 인덱스 크기 등 구체적인 정보를 보여준다. 하지만 이 때 주의할 점이 하나 있는데 바로 SHOW TABLE STATUS의 경우 테이블의 스토리지 엔진이 MyISAM인 경우에만 정확한 정보를 표시하며 InnoDB의 경우에는 부정확한 정보를 보여준다는 것이다. InnoDB 스토리지 엔진으로 되어 있는 테이블은 SHOW INNODB STATUS로 구체적인 정보를 확인할 수 있으며 SHOW INDEX를 통해 테이블의 인덱스에 대한 각종 정보를 볼 수 있다.
- Server Connetion에서 쓰레드별 정보 확인 - MySQL Administrator를 통해 커넥션 관련 정보를 실시간 모니터링
1.1.1.3 GUI 기반의 모니터링[편집]
모니터링을 위해 이용할 수 있는 툴은
- MySQL Administrator
- MySQL Query Browser
1.1.1.3.1 MySQL Administrator[편집]
- 가장 돋보이는 기능은 모니터링 기능
- MySQL Administrator의 모니터링 관련 메뉴는 Server Connections, Health, Server Logs 등
- Server Connection은 커맨드라인 명령 중 SHOW PROCESSLIST와 같은 역할과 함께 각 유저 별 접속 현황을 알 수 있다.
- 모니터링 기능의 백미는 바로 Health 메뉴
- Health 메뉴에서는 기본적으로 Connection Health, Memory Health, Status Variables, System Variables 등 네 가지 항목을 가지고 있으며 이전 커맨드라인 모니터링에서 하던 대부분의 모니터링 작업을 여기서 수행할 수 있다.
- 가장 큰 특징이라면 기본적으로 보여주는 주요 사항에 대한 모니터링 외에도 SHOW STATUS를 통해 볼 수 있는 모든 항목에 대한 모니터링 그래프를 추가할 수 있다는 것이다.
- 직관적인 화면상의 변화를 보며 사용자 수의 변화나 시간대별 변화에 대한 쉽고 편한 모니터링을 할 수 있게 되었다.
1.1.1.4 MySQL Query Browser[편집]
- 기존 MySQL 관리자나 프로그래머들이 많이 이용하던 SQLGate와 비슷한 역할을 수행하는 프로그램이다.
- GUI 상에서 MySQL 쿼리들을 수행할 수 있으며 여러 탭을 이용해 빠른 작업을 할 수 있게 되었다.
- 도움말과 명령어들에 대한 하이라이팅을 지원함으로써 편리하고 정확한 작업을 할 수 있다.
- 커맨드라인 명령어들을 여기에서 모두 실행해 볼 수 있다.
1.1.1.5 로그를 통한 모니터링[편집]
- 적절한 수준의 로그를 남기는 것은 빠르고 건강한 MySQL을 유지하는 비결.
- 일반적으로 운영되는 서버라면 에러 로그와 슬로우 쿼리 로그를 남기는 정도로 충분하지만 서비스를 위한 시험 기간이거나 문제를 찾는 시점이라면 일반 쿼리 로그(General Query Log)를 남겨 어떤 쿼리가 가장 많이 사용되는지 파악하고 그 쿼리를 더 빠르게 할 수 있는 방법이 없는지를 찾는 것은 데이터베이스 최적화하는 좋은 방법 중 하나이다.
- 일반적으로 MySQL을 사용하는 사용자들의 경우 기본적으로 지원하는 에러 로그만을 남기고 슬로우 쿼리 로그를 남기지 않는 경우가 많은데 슬로우 쿼리는 MySQL의 성능을 떨어뜨리는 주범이다. 반드시 슬로우 쿼리 로그를 남기고 확인해 개선점을 찾도록 하자.
1.1.2 MySQL 서버 튜닝[편집]
- MySQL의 데이터베이스 시스템 관련 파라미터들에 대한 튜닝과 각각의 스토리지 엔진 관련 튜닝으로 나눠진다.
- MySQL의 시스템 관련 튜닝은 MySQL의 설정 파일인 my.cnf(윈도우의 경우는 my.ini) 파일을 수정하게 되며 MySQL 커넥션에 관한 부분과 메모리에 관한 부분으로 나눌 수 있다.
1.1.2.1 MySQL 커넥션 튜닝[편집]
- 커넥션에 관련된 모니터링은
SHOW STATUS LIKE ‘%CONNECT%’
mysql> SHOW STATUS LIKE ‘%CONNECT%’;
+-------------------------------+---------------+
| Variable_name | Value |
+-------------------------------+---------------+
| Aborted_connects | 12 |
| Connections | 212 |
| Max_used_connections | 112176 |
| Threads_connected | 168 |
+-------------------------------+---------------+
4 rows in set (0.00 sec)
mysql> SHOW STATUS LIKE ‘%CLIENT%’;
+-------------------------------+---------------+
| Variable_name | Value |
+-------------------------------+---------------+
| Aborted_clients | 2 |
+-------------------------------+---------------+
1 row in set (0.00 sec)1.1.2.1.1 connect_timeout[편집]
- MySQL이 클라이언트로부터 접속 요청을 받는 경우 몇 초까지 기다릴지를 설정하는 변수
- 기본 값은 5초이며 일반적으로 수정할 필요는 없다.
1.1.2.1.2 Interactive_timeout[편집]
- ‘mysql>’과 같은 콘솔이나 터미널 상에서의 클라이언트 접속
- 기본 값으로 8시간이 잡혀 있으나 1시간 정도로 낮추는 것이 좋다.
- 이런 접속은 그다지 빈번하지 않으며 작업을 위해 접속하는 경우가 많기에 따로 설정하지 않아도 큰 영향은 없다.
1.1.2.1.3 wait_ timeout[편집]
- wait_timeout은 접속한 후 쿼리가 들어올 때까지 기다리는 시간이다.
- 접속이 많은 데이터베이스 시스템에서는 이 값을 낮춰 sleep 상태로 커넥션만 유지하고 있는 클라이언트들의 접속을 빠르게 끊어줘 동시 접속을 낮추는 것으로 전체 성능을 크게 향상시킬 수 있다.
- 주의할 점은 너무 낮추게 되면 실제로 서비스를 하기도 전에 끊어진다든지 지나치게 잦은 커넥션이 발생한다는 것이다.
- 일반적으로 15~20 사이의 값이 적당하며 SHOW STATUS를 통해 aborted_client가 가장 적게 발생하도록 값을 맞춰야 한다.
- Aborted client는 2% 아래인 것이 바람직하며 물론 없는 것이 가장 좋은 상태이다.
1.1.2.1.4 net_buffer_length/max_allowed_packet[편집]
- MySQL의 커넥션은 쓰레드 단위로일어나는데 각 쓰레드가 생성되면서 메시지 전송을 위한 버퍼를 생성하게 된다.
- 일반적으로 max_allowed_packet만을 정해 놓는 경우가 많은데 net_buffer_ length를 설정해 두면 그 용량을 넘는 메시지를 전달해야 할 경우 자동으로 이 값을 늘리게 된다.
- 그러므로 가장 효율을 높이기 위해서는 net_buffer_length를 일반적인 쿼리에서 전송되는 바이트 값의 평균 정도를 생각하여 충분히 낮은 값을 설정해두고 max_allowed_ packet은 최대로 전송될 수 있는 높은 값을 설정하는 것이 좋다.
- max_allowed_packet은 1GB까지 설정할 수 있다.
1.1.2.1.5 max_connections/back_log[편집]
- max_connections는 서버가 허용하는 최대한의 커넥션 수이다.
- MySQL 데이터베이스를 운영하고 있는 서버의 사양에 따라 달라질 수 있으며 일반적으로 120~250개 정도로 설정하는 것이 보통이다.
- 접속이 많고 고용량 서버의 경우 1000개 정도의 높은 값을 설정하는 것도 가능하다.
- Too many connection 에러가 발생하지 않도록 적절한 값을 설정하는 것이 중요하다.
- Back_log의 경우 max_connection 이상의 접속이 발생할 때 얼마만큼의 커넥션을 큐에 보관할지에 대한 설정 값이다.
- 기본 값은 50이며 접속이 많은 서버의 경우 이 값을 늘릴 필요가 있다.
1.1.2.1.6 skip-name-resolve[편집]
- 외부로부터 접속 요청을 받을 경우 인증을 위해 IP를 호스트네임으로 바꾸는 과정이 수행된다.
- hostname lookup 과정이 수행되는데 접속이 많은 서버에서는 이 과정에서 상당히 많은 과부하가 발생한다.
- 그러므로 인증 부분을 호스트 기반이 아닌 IP 기반으로 변경하고 이 같은 옵션을 통해 hostname lookup 과정을 생략하면 눈에 띄는 성능 향상을 경험할 수 있을 것이다.
1.1.3 MySQL 메모리 튜닝[편집]
- 데이터베이스 시스템 튜닝은 메모리 관련 파라미터를 조정하는 것이 90% 정도를 차지
- MySQL의 메모리 부분 튜닝은 사실 대부분 스토리지 엔진에 특화된 부분이다.
- 시스템 전체에 영향을 미치는 메모리 설정 2가지
- 쓰레드 관련 메모리 설정
- 쿼리 캐시관련 메모리 설정
1.1.3.1 쓰레드 관련 메모리 튜닝[편집]
- MySQL은 커넥션마다 하나의 쓰레드를 생성시켜 요청을 처리하게 된다.
- 쓰레드가 생성되는 시점에 쓰레드에 메모리가 할당되며 많은 쓰레드가 생성되고 사라지면서 과부하가 발생한다.
- 일반적인 시스템에서는 쓰레드 관련 파라미터들의 조정할 필요는 없지만 부하가 심한 서버에서는 모니터링 결과에 따라 이 설정을 변경해 성능 향상을 이룰 수 있다.
1.1.3.1.1 현재 쓰레드와 관련된 상태 조회[편집]
mysql> SHOW STATUS LIKE ‘%THREAD%’;
+-------------------------------+---------------+
| Variable_name | Value |
+-------------------------------+---------------+
| Delayed_insert_threads | 0 |
| Slow_launch_threads | 0 |
| Threads_cached | 0 |
| Threads_connected | 1 |
| Threads_created | 2 |
| Threads_running | 1 |
+-------------------------------+---------------+
6 rows in set (0.00 sec)- 항목 중 Threads_connected가 Threads_ cached에 비해 매우 높다면 thread_cache_size를 높여줄 필요가 있다.
- Thread_cache_size는 지나치게 높여둘 필요는 없으며 일반적으로 threads_connected의 피크 치보다 약간 낮은 수치 정도를 설정하는 것이 좋다.
- 이를 통해 쓰레드가 생성되고 소멸되면서 겪게 되는 메모리, 각종 자원, 시간 등의 낭비를 줄일 수 있다.
- 쓰레드와 관련해 또 하나 설정할 수 있는 옵션은 thread_concurrency인데 이 옵션은 솔라리스 외의 시스템에서는 신경 쓸 필요가 없으며 솔라리스에서는 CPU 수에 2를 곱한 값을 넣어주면 된다.
1.1.3.2 캐싱 관련 메모리 튜닝[편집]
- MySQL 데이터베이스 시스템에서 메모리 관련 주요 설정들은 대부분 캐싱과 관련된 파라미터들이다.
- 버퍼 풀(buffer pool) 크기, 키 캐시(key cache) 크기, 쿼리 캐시 크기 등이 있는데, 이 중 앞의 두 개는 InnoDB와 MyISAM의 핵심 파라미터
- 현실적으로 어려운 이야기지만 이 같은 경우는 줄이면 줄일수록 쿼리 캐시의 사용률과 효율을 높여 더 빠른 성능을 기대할 수 있다.
1.1.3.3 쿼리 캐시의 사용[편집]
- 먼저 현재 사용하고 있는 MySQL이 쿼리 캐시를 지원하는 버전인지 아닌지 확인
mysql> SHOW VARIABLES LIKE ‘HAVE_QUERY_CACHE’;
+-------------------------------+---------------+
| Variable_name | Value |
+-------------------------------+---------------+
| have_query_cache | YES |
+-------------------------------+---------------+
1 row in set (0.00 sec)1.1.3.3.1 쿼리 캐시를 지원하는 버전일 경우[편집]
- ‘query_cache_size=64M’와 같은 방식으로 정확한 쿼리 캐시 크기를 정해 주는 것만으로 쿼리 캐시를 사용하게 된다.
- 그리고 쿼리 캐시의 동작 방식을 정해주는 옵션으로 query_cache_type이라는 옵션이 있는데 0은 쿼리 캐시를 비활성화시키게 되고
- 1은 사용 가능한 모든 쿼리가 쿼리 캐시를 이용하게 되며,
- 2는 쿼리 캐시를 이용하라고 정해주는 쿼리만 쿼리 캐시를 이용하게 된다.
- 2의 경우는 쿼리문 뒤에 SQL_CACHE라고 덧붙여주면 된다.
1.1.3.3.2 쿼리 캐시 최적화[편집]
- 데이터베이스 관련 모든 메모리 설정은 높다고 다 좋은 것이 아니다
- 중요한 것은 균형 값을 찾아내는 것.
- 쿼리 캐시와 MyISAM의 키 캐시, InnoDB의 버퍼 풀은 소중한 메모리 공간을 놓고 서로 경쟁하는 관계
- 먼저 쿼리 캐시 크기를 결정.
- 일반적으로 시스템 전체 메모리의 5%에서 10% 사이를 사용하는 것이 보통.
- 일단 이 사이의 값으로 설정한 후 모니터링을 통해 쿼리 캐시 사용률이 100%에 가깝도록 하는 것이 좋다.
- 이를 모니터링하는 가장 좋은 방법은 MySQL Administrator를 사용하는 것으로 MySQL Administ rator의 Health 부분에서 쿼리 캐시의 효율을 지속적으로 모니터링할 수 있기 때문이다.
- 쿼리 캐시에서 받아들일 쿼리의 최대 크기를 설정하는 것이 필요하다.
- Query_cache_limit 옵션으로써 기본 값은 1MB이나 이는 너무 큰 값일 경우가 많다.
- 빈번하게 사용되는 쿼리의 용량이 어느 정도인지 살펴본 후 이보다 10% 정도 높은 값을 설정
설명:
Aborted_clients : 클라이언트가 연결을 적절히 닫지않아서 죽었기때문에 끊어진 연결수.
Aborted_connects : 연결실패된 mysql서버에 연결시도 수.
Bytes_received : 모든 클라이언트로 부터 받은 바이트 수
Bytes_sent : 모든 클라이언트에게 보낸 바이트수
Connections : mysql서버에 연결시도한 수
Created_tmp_disk_tables : sql문을 실행하는 동안 생성된 디스크에 존재하는 임시테이블 수
Created_tmp_tables : sql문을 실행하는 동안 생성된 메모리에 존재하는 임시테이블 수
Created_tmp_files : 얼마나 많은 임시파일을 mysqld가 생성했는가
Delayed_insert_threads : 사용중인 insert handler threads가 지연되고 있는 수
Delayed_writes : INSERT DELAYED로 쓰여진 rows수
Delayed_errors : 어떤 에러(duplicate key로인한 때문에 INSERT DELAYED로 쓰여진 rows수
Flush_commands : 초과 flush명령수
Handler_delete : 테이블로 부터 지워진 rows수
Handler_read_first : 인덱스로 부터 읽혀진 처음 entry수. 이것이 높으면 서버는 많은 full
index scans를 하고 있다는 것을 의미. 예를 들어 SELECT col1 FROM
foo는 col1은 인덱스되었다는 것을 추정.
Handler_read_key : 키가 존재하는 row를 읽는 요청수. 이것이 높으면 당신의 쿼리와 테이블
이 적절히 인덱스화되었다는 좋은 지적이 된다.
Handler_read_next : 키순서대로 다음 row를 읽는 요청수. 이것은 만약 range constraint와
함께 인덱스컬럼을 쿼리할 경우 높아질 것이다. 이것은 또한 인덱스 스캔
하면 높아질 것이다.
Handler_read_rnd : 고정된 위치에 존재하는 row를 읽는 요청수. 이것은 결과를 정렬하기를
요하는 많은 쿼리를 한다면 높아질 것이다.
Handler_read_rnd_next : 데이타파일에서 다음 row를 읽기를 요청수. 이것은 많은 테이블 스
캔을 하면 높아질 것이다.
Handler_update : Number of requests to update a row in a table.
한테이블에 한 row를 업데이트를 요청하는 수
Handler_write : 한테이블에 한 row를 insert요청하는 수
Key_blocks_used : key 캐시에서 블럭을 사용하는 수
Key_read_requests : 캐시에서 키블럭을 읽기를 요청하는 수
Key_reads : 디스크로부터 키블럭을 물리적으로 읽는 수
Key_write_requests : 캐시에서 키블럭을 쓰기위해 요청하는 수
Key_writes : 디스크에 키블럭을 물리적으로 쓰는 수
Max_used_connections : 동시사용 연결 최대수
Not_flushed_key_blocks : 키캐시에서 키블럭이 바뀌지만 디스크에는 아직 flush되지 않는다.
Not_flushed_delayed_rows : INSERT DELAY queue에서 쓰여지기를 기다리는 row수
Open_tables : 현재 오픈된 테이블수
Open_files : 현재 오픈된 파일수
Open_streams : 주로 logging에 사용되는 현재 오픈된 stream수
Opened_tables : 지금까지 오픈된 테이블 수
Select_full_join : 키없이 조인된 수(0이 되어야만 한다)
Select_full_range_join : reference table에서 range search를 사용한 조인수
Select_range : 첫번째 테이블에 range를 사용했던 조인수. 보통 이것이 크더라도 위험하진 않다.
Select_scan : 첫번째 테이블을 스캔했던 조인수
Select_range_check : 각 row후에 key usage를 체크한 키없이 조인한 수(0이어야만 한다)
Questions : 서버에서 보낸 쿼리수
Slave_open_temp_tables : 현재 slave thread에 의해 오픈된 임시 테이블 수
Slow_launch_threads : 연결된 slow_launch_time보다 더 많은 수를 갖는 쓰레드수
Slow_queries : long_query_time보다 더 많은 시간이 걸리는 쿼리 수. Slow Query Log참고
Sort_merge_passes : 정렬해야만 하는 merge수.
이 값이 크면 sort_buffer를 증가하는것에 대해 고려해야 한다.
Sort_range : Number of sorts that where done with ranges.
Sort_rows : 정렬된 row수
Sort_scan : 테이블 스캔에 의해 행해진 정렬수
Table_locks_immediate : 즉시 획득된 테이블 lock 시간 (3.23.33부터 추가된 항목)
Table_locks_waited : 즉시 획득되지 않고 기다림이 필요한 테이블 lock 시간. 이것이 높아지면 성능에 문제가 있으므로, 먼저 쿼리를 최적화 시키고, 테이블을 분산시키거나 복제를 사용해야 한다. (3.23.33부터 추가된 항목)
Threads_cached : 스레드 캐시에서 쓰레드 수
Threads_connected : 현재 오픈된 연결수
Threads_created : 연결을 다루기위해 생성된 쓰레드 수
Threads_running : sleeping하지 않는 쓰레드 수
Uptime : 서버가 스타트된 후로 지금까지의 시간