VPS를 위한 MySQL 최적화

VPS를 위한 MySQL 최적화

VPS(Linux/Cpanel) mysql 설정을 최적화하는 데 약간의 문제가 있습니다. 저는 Mysql에 대해 잘 모르고 약 50개의 다른 웹사이트에 이 VPS를 사용하고 있습니다. 그들은 모두 매일 방문자가 100명 미만이었기 때문에 교통량이 많지 않아서 문제가 되지 않았습니다. 내 VPS는 현재 잘 작동하고 있지만 mysqltuner.pl의 [!!] 경고가 걱정됩니다. 걱정할 필요가 있나요?

=> 내 VPS 정보:

Processor Information
**Total processors: 6**
Processor #1
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #2
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #3
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #4
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #5
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #6
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB

Memory Information
Memory: 30789880k/**32505856k** available (5336k kernel code, 1050056k absent, 665920k reserved, 7016k data, 1288k init)

System Information
Linux xl.xlxlxl.com 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Current Memory Usage
             total       used       free     shared    buffers     cached
Mem:      30812400   30064332     748068        244    3883652   17129112
-/+ buffers/cache:    9051568   21760832
Swap:            0          0          0
Total:    30812400   30064332     748068

=> 내.cnf:

[mysqld]
max_allowed_packet=268435456
open_files_limit=10000
query_cache_type=1
query_cache_size=768M
query_cache_limit=2048M
sort_buffer_size=4M
join_buffer_size=26M
read_rnd_buffer_size = 1M
max_heap_table_size = 1024M
tmp_table_size = 1024M
table_open_cache = 15000
innodb_log_buffer_size = 64M
max_connections=200
wait_timeout=26000
interactive_timeout=26000
innodb_buffer_pool_size=256M

=> Mysqltuner.pl:

 >>  MySQLTuner 1.4.0 - Major Hayden <[email protected]>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
[OK] Currently running supported MySQL version 5.6.23
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 3G (Tables: 3156)
[--] Data in InnoDB tables: 183M (Tables: 1455)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[!!] Total fragmented tables: 5

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 20h 23m 59s (11M q [45.850 qps], 381K conn, TX: 85B, RX: 2B)
[--] Reads / Writes: 82% / 18%
[--] Total buffers: 2.1G global + 31.4M per thread (200 max threads)
[OK] Maximum possible memory usage: 8.2G (27% of installed RAM)
[OK] Slow queries: 0% (4/11M)
[OK] Highest usage of available connections: 7% (14/200)
[OK] Key buffer size / total MyISAM indexes: 8.0M/432.3M
[OK] Key buffer hit rate: 99.6% (493M cached / 1M reads)
[OK] Query cache efficiency: 59.6% (5M cached / 8M selects)
[!!] Query cache prunes per day: 143463
[OK] Sorts requiring temporary tables: 0% (16 temp sorts / 434K sorts)
[!!] Joins performed without indexes: 2610
[!!] Temporary tables created on disk: 83% (458K on disk / 550K total)
[OK] Thread cache hit rate: 99% (36 created / 381K connections)
[!!] Table cache hit rate: 13% (1K open / 12K opened)
[OK] Open file limit used: 1% (324/30K)
[OK] Table locks acquired immediately: 99% (4M immediate / 4M locks)
[!!] Connections aborted: 18%
[OK] InnoDB buffer pool / data size: 256.0M/183.9M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Increasing the query_cache size over 128M may reduce performance
    Adjust your join queries to always utilize indexes
    Temporary table size is already large - reduce result set size
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
    Your applications are not closing MySQL connections properly
Variables to adjust:
    query_cache_size (> 768M) [see warning above]
    join_buffer_size (> 26.0M, or always use indexes with joins)
    table_open_cache (> 15000)

답변1

더 나은 성능을 위한 조치를 권장하는 것이 mysqltuner의 아이디어입니다. 최적화 테이블은 조각화에 관심을 갖습니다. 그러나 큰 테이블에 대한 최적화에는 시간이 좀 걸리며 최적화 중인 테이블은 잠겨 있습니다. 일반적으로 접두사가 붙은 경고 참고 사항이 섹션 [!!]에 설명되어 있습니다 General recommendations.

mysql의 기본 매개변수를 조정하기 전에 SQL 문과 SQL 연결을 확인해야 합니다. 인덱스 없이 조인하면 성능이 크게 저하됩니다. slow_queries최적화할 쿼리를 식별하는 데 사용해 보세요 .

또한 결과 집합 크기가 너무 큰 경우가 많습니다. 데이터베이스가 있는 상점 시스템을 생각해 보십시오.

상점 시스템에 10,000개의 항목이 있다고 가정하면 호출 select * from items;은 10,000개의 항목을 모두 반환하므로 결과 집합 크기는 10,000입니다. 그러나 실제로 10,000개의 항목이 동시에 모두 필요한 경우는 거의 없습니다.

실제로 SQL의 주요 목적은 인덱스에서 가장 효과적으로 작동하는 필터를 사용하여 결과 집합을 줄이는 것입니다. 예를 들어 노란색을 갖는 모든 항목을 검색하는 경우 결과 세트 크기를 다음과 같이 줄입니다.select * from items where color="yellow";

그러나 수백 개의 노란색 항목이 있는 경우 웹 페이지에 표시하기에는 여전히 너무 많습니다. 그래서 결과를 제한합니다.

select * from items where color="yellow" limit 1,10

10개 항목 중 첫 번째 페이지에 대해

select * from items where color="yellow" limit 11,20

다음 페이지 등등....

따라서 데이터베이스를 조정하기 전에 명령문을 조정하는 것이 좋습니다. 테이블 인덱스를 수정하고 큰 결과 집합을 제한하면 훨씬 더 많은 성능을 얻을 수 있기 때문입니다. 이것이 mysqltuner가 이러한 경고를 내뱉는 이유입니다.

조인 및 인덱스를 디버그하는 가장 유용한 도구 중 하나는 explainselect 문 앞에 사용하는 것입니다.

explain select i.name, l.address
    from items i
         inner join location l on i.location = l.id
    where l.description like '%universe%';

결과를 컴파일하는 데 사용되는 인덱스가 있거나 없는 테이블 행의 수가 표시됩니다.

관련 정보