mysql my.cnf 최적화 중 - 메모리 사용량이 위험할 정도로 높습니다.
나는 인터넷에 있는 몇 가지 팁을 따라 mysql을 튠업했습니다.
하지만 웹사이트 로딩 속도가 느리고 첫 번째 바이트까지의 시간이 매우 높습니다. 그래서 조사를 시작했고 제가 보기에는 mysql과 높은 메모리 사용량 때문입니다.
./mysqltuner.pl AND ./tuning-tuning-messages에서 받은 제안에 따라 my.cnf를 변경할 때마다.shit은 다른 제안을 합니다.사실 어떤 가치들은 서로 균형을 이루어야 합니다.나는 누군가가 mysql의 고성능 사용을 얻는 동시에 서버 상태를 관리하는 방법을 알기를 바랍니다.
MariaDB 서버 버전: 10.0.20-MariaDB 로그 MariaDB 서버 정보:Intel Core i7-3770 2x HDD 3,0TB SATA 4x RAM 8192MB DDR3 Cloudlinux + Cpanel 설치 Apache/2.4.16 + eAccelerator + mod_pagespeed
SLOW QUERIES
Error: slow_query_log_file=/var/log/mysql/log-slow-queries.log
Current long_query_time = 10.000000 sec.
You have 1944 out of 25401054 that take longer than 10.000000 sec. to complete
**Your long_query_time seems to be fine**
BINARY UPDATE LOG
The binary update log is NOT enabled.
**You will not be able to do point in time recovery**
See http://dev.mysql.com/doc/refman/10.0/en/point-in-time-recovery.html
WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 6
Current threads_per_sec = 0
Historic threads_per_sec = 0
**Your thread_cache_size is fine**
MAX CONNECTIONS
Current max_connections = 151
Current threads_connected = 6
Historic max_used_connections = 43
The number of used connections is 28% of the configured maximum.
**Your max_connections variable seems to be fine.**
No InnoDB Support Enabled!
MEMORY USAGE
Max Memory Ever Allocated : 20.96 G
Configured Max Per-thread Buffers : 24.81 G
Configured Max Global Buffers : 13.89 G
Configured Max Memory Limit : 38.70 G
Physical Memory : 31.12 G
**Max memory limit exceeds 90% of physical memory**
KEY BUFFER
Current MyISAM index space = 29 M
Current key_buffer_size = 384 M
Key cache miss rate is 1 : 870
Key buffer free ratio = 78 %
**Your key_buffer_size seems to be fine**
QUERY CACHE
Query cache is enabled
Current query_cache_size = 512 M
Current query_cache_used = 222 M
Current query_cache_limit = 1.00 G
Current Query cache Memory fill ratio = 43.41 %
Current query_cache_min_res_unit = 4 K
**MySQL won't cache query results that are larger than query_cache_limit in size**
SORT OPERATIONS
Current sort_buffer_size = 16 M
Current read_rnd_buffer_size = 8 M
**Sort buffer seems to be fine**
JOINS
./tuning-primer.sh: line 402: export: `2097152': not a valid identifier
Current join_buffer_size = 128.00 M
You have had 10199 queries where a join could not use an index properly
join_buffer_size >= 4 M
**This is not advised
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.**
OPEN FILES LIMIT
Current open_files_limit = 16162 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
**Your open_files_limit value seems to be fine**
TABLE CACHE
Current table_open_cache = 8000 tables
Current table_definition_cache = 8000 tables
You have a total of 7347 tables
You have 8000 open tables.
**Current table_cache hit rate is 21%
, while 100% of your table cache is in use
You should probably increase your table_cache**
TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 16 M
Of 592173 temp tables, 36% were created on disk
**Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.**
TABLE SCANS
Current read_buffer_size = 16 M
Current table scan ratio = 74 : 1
**read_buffer_size is over 8 MB there is probably no need for such a large read_buffer**
TABLE LOCKING
Current Lock Wait ratio = 1 : 4366
**You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=ALWAYS'.**
root@my [~]# ./mysqltuner.pl
>> MySQLTuner 1.4.0 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[!!] Currently running unsupported MySQL version 10.0.20-MariaDB-log
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB +MRG_MyISAM
[--] Data in MyISAM tables: 82M (Tables: 925)
[--] Data in InnoDB tables: 7G (Tables: 6334)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[--] Data in MEMORY tables: 0B (Tables: 2)
[!!] Total fragmented tables: 159
-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 14h 42m 18s (25M q [480.374 qps], 81K conn, TX: 71B, RX: 6B)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 13.9G global + 168.3M per thread (151 max threads)
**[!!] Maximum possible memory usage: 38.7G (124% of installed RAM)**
[OK] Slow queries: 0% (1K/25M)
[OK] Highest usage of available connections: 28% (43/151)
[OK] Key buffer size / total MyISAM indexes: 384.0M/29.8M
[OK] Key buffer hit rate: 99.9% (12M cached / 14K reads)
[OK] Query cache efficiency: 44.9% (20M cached / 44M selects)
**[!!] Query cache prunes per day: 2013573**
[OK] Sorts requiring temporary tables: 0% (1K temp sorts / 1M sorts)
**[!!] Joins performed without indexes: 10207
[!!] Temporary tables created on disk: 58% (345K on disk / 592K total)**
[OK] Thread cache hit rate: 98% (1K created / 81K connections)
[OK] Table cache hit rate: 21% (8K open / 38K opened)
[OK] Open file limit used: 12% (1K/16K)
[OK] Table locks acquired immediately: 99% (10M immediate / 10M locks)
[OK] InnoDB buffer pool / data size: 10.0G/7.7G
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
**Run OPTIMIZE TABLE to defragment tables for better performance
Reduce your overall MySQL memory footprint for system stability
Increasing the query_cache size over 128M may reduce performance
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses**
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
query_cache_size (> 512M) [see warning above]
join_buffer_size (> 128.0M, or always use indexes with joins)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)
그리고 여기 제가 설정한 my.cnf 설정이 있습니다.
[mysqld]
#http://blog.secaserver.com/2011/08/mysql-recommended-my-cnf-settings-innodb-engine/
# GENERAL #
default-storage-engine=InnoDB
tmpdir=/tmp_mysql
group_concat_max_len=10000000
local-infile=1
# LOGGING #
slow_query_log = 1
slow_query_log_file=/var/log/mysql/log-slow-queries.log
long_query_time = 10
log-error = /var/log/error.log
log-queries-not-using-indexes
# CACHES AND LIMITS AND SAFETY #
max_allowed_packet = 512M #16
query_cache_size = 512M
query_cache_limit = 1024M
thread_cache_size = 8
table_definition_cache = 8000
table_open_cache = 8000
sort_buffer_size = 16M
read_buffer_size = 16M #2
read_rnd_buffer_size = 8M
join_buffer_size = 128M
thread_concurrency = 0 # Try number of CPU's*2 for thread_concurrency
key_buffer = 256M
# INNODB #
innodb_file_per_table=1
innodb_file_format = Barracuda
innodb_sort_buffer_size = 128M
innodb_data_home_dir = /var/lib/mysql
innodb_log_group_home_dir = /var/lib/mysql
innodb_thread_concurrency=0
innodb_flush_method=O_DIRECT
innodb_lock_wait_timeout = 120
innodb_buffer_pool_size=10G
innodb_log_file_size = 1536M # Set .. innodb_log_file_size to 25 % of innodb_buffer_pool_size -You can set .. innodb_buffer_pool_size up to 50 - 80 %
innodb_log_buffer_size = 3072M
innodb_additional_mem_pool_size = 20M
#innodb_read_io_threads=16
#innodb_write_io_threads=16
#innodb_io_capacity=500
#innodb_flush_log_at_trx_commit=1
#sync_binlog=1
#innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
# MyISAM #
key_buffer_size = 384M
myisam_sort_buffer_size = 64M
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[myisamchk]
key_buffer_size = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
요약
- 메모리 "문제"에 대해 걱정하지 마십시오.
- 느린 로그를 보십시오. 처리해야 할 몇 가지 심각한 최적화가 있습니다.
- 왜 수천 개의 테이블?이것은 아마도 설계 결함일 것입니다.
- 조각화에 대한 설명을 무시합니다.
- 나머지 테이블을 InnoDB로 변환합니다.
세부 사항
당신의 긴_query_time은 괜찮은 것 같습니다.
아니, 크랭크long_query_time2까지 내려가고 느린 쿼리를 주시합니다.
InnoDB 지원 사용 안 함!
[--] InnoDB 테이블의 데이터: 7G (테이블: 6334)
그 진술들은 서로 모순됩니다!InnoDB가 선호되는 엔진입니다.다른 출력에는 InnoDB가 사용 중이라고 나와 있는 것 같습니다. (스크립트의 버그?)
최대 메모리 제한이 물리적 메모리의 90%를 초과합니다.
[!!] 최대 가능 메모리 사용량: 38.7G(설치된 RAM의 124%)
결점이 없는 포룸라는 없습니다.당신은 아마 괜찮을 거예요.
당신의 key_buffer_size는 괜찮은 것 같습니다.
그key_bufferMyISAM_only 서버에서 가장 큰 메모리 사용량이어야 합니다.하지만 당신은 작은 데이터베이스를 가지고 있기 때문에 문제 없습니다.innodb_buffer_pool_sizeInnoDB를 사용할 때 가장 큰 메모리 사용자여야 합니다.현재 값이 양호합니다.
innodb_buffer_pool_size = 10G
key_buffer_size = 384M
현재 쿼리_cache_size = 512M
[OK] 쿼리 캐시 효율성: 44.9%(20M 캐시/44M 선택)
[!!] 일일 캐시 자두 쿼리: 2013573
512M은 성능을 저하시키므로 50M으로 제한합니다.다른 두 줄은 QC가 그렇게 유용하지 않으며 오버헤드가 많이 발생한다고 말합니다.
결론:조심해서 해보세요.
query_cache_size = 0
query_cache_type = OFF
./tuning-tuning-tuning.sh: line 402: 내보내기: '2097152': 올바른 식별자가 아닙니다.
대본에 버그?
"log-query-not-use-index"를 사용하도록 설정해야 합니다.
아니요, 그것은 느린 로그를 혼란스럽게 할 뿐입니다.인덱스가 없는 한 줄 테이블이나 인덱스가 없는 100행 테이블도 "충분히 빠릅니다.
대신 기존의 느린 쿼리를 보고 작업할 항목을 결정합니다.
은 총 7347 7347 테이블을 가지고 .
표: 6334)
그것은 데이터베이스의 설계 결함입니다.
592173개의 임시 테이블 중 36%가 Disk에 생성됨
느린 로그는 최악의 쿼리를 식별하는 데 도움이 됩니다.그런 다음 인덱스를 추가하거나 쿼리를 재구성하여 수정할 수 있습니다.
총 표:[!!] 총 조각난 표: 159
OPTIMATE TABLE을 실행하여 테이블 조각 모음
무시 - 사실상 모든 테이블은 사실상 항상 조각화되어 있습니다.여기에 작업 항목이 없습니다.
[189.374 qps]
InnoDB에 가는 좋은 이유.
: [!!] 인덱스 없이 수행된 조인: 10207
: 총 592,)[!!] 디스크에 생성된 임시 테이블: 58%(디스크 345K/총 592K)**
느린 로그 항목을 확인해야 합니다.당신이 이미 잡은 10초짜리부터 시작하겠습니다.
#innodb_flush_log_at_trx_commit=1
2로 설정을 제안합니다.
(이것은 내가 처음 보는 것입니다.tuning-primer.sh저는 감명받지 않았습니다.)
다음 두 블로그가 유용할 것으로 예상됩니다.
불완전한 인덱싱 문제일 가능성이 더 높아 보입니다.
느린 쿼리의 WHERE 절에 있는 모든 필드가 올바르게 인덱싱되었는지 확인
N개의 필드-in-one 인덱스가 있는 경우, 첫 번째 필드만 실제로 인덱싱되거나 모두 하나의 aWHERE 절로 함께 인덱싱되므로 개별적으로 분산해 보십시오.
중복 인덱싱 방지(예: 사례 또는 고급 비트)
db 구조도 약간의 터치가 필요할 수 있습니다. 하지만 이것은 당신의 db 프로필과 물론 데이터가 업데이트되고 보는 방법에 달려 있습니다. (건당 혼합 유형의 엔진을 사용하여 개선할 수 있습니다. 하지만 당신은 my.cnf를 적절하게 조정하는 방법을 알아야 합니다.)
언급URL : https://stackoverflow.com/questions/31904175/optimizing-mysql-my-cnf-memory-usage-is-dangerously-high
'programing' 카테고리의 다른 글
| 구글 크롬에서 실패한 아약스 요청을 디버그하는 방법은 무엇입니까? (0) | 2023.08.25 |
|---|---|
| SQL 서버:인덱스 열은 유사하게 사용됩니까? (0) | 2023.08.25 |
| jQuery를 사용하여 div에 특정 클래스의 자식이 있는지 확인 (0) | 2023.08.25 |
| Opensl : "인증서 체인의 자체 서명된 인증서" 오류 (0) | 2023.08.25 |
| XHR에 대한 404 오류 감지 (0) | 2023.08.25 |