전체 네트워크를 가장 포괄적 인 MySQL의 성능 최적화 연습, 전투 프로그래머 필수 구문! ! !

비문

최근이 회사는 일부 쿼리 기능의 목록을 찾을 오랜만에 라인에 새로운 기능을 추가하는 프로젝트. 그 이유는 기존의 기능 인터페이스를 사용하는 새로운 기능, 이러한 오래된 테이블과 관련된 SQL 쿼리 인터페이스입니다 5,6 쓰기는 SQL 문, 전체 테이블 스캔의 구현에 인덱스의 MySQL의 실패의 결과로, 표준화되지 않습니다. 따라서 쿼리 데이터 문제를 최적화, 집에 가고 떠나 동료에게 무언가를 최적화하기위한 원래 책임 저자의 손에 떨어진다. 온라인 정보 액세스 SQL 최적화 후 저자는 성공적으로보기, 기록의 글로벌 관점에서 이것, 문제를 해결하고 관련 MySQL의 쿼리 최적화 기술을 요약합니다.

둘째, 최적화 아이디어

슬로우 쿼리 데이터는 질문에 기록 된 SQL 문을 의미하지 않는다. 첫째, 우리는 문제의 원인 찾아야 "올바른 약을." MySQL의 최적화 아이디어를 나타내는 흐름도를 사용하여

 

더 이상의 말은 명확하게 느린 데이터 초래하는 등의 이유로, 다양한 쿼리 그림에서 볼 수 없습니다 :; 문제 쓰는 SQL 문 인한 높은 동시 충돌하는 MySQL 서버에 대한 액세스 리드로이 기간 내에 캐시 무효화를, MySQL 서버 문제의 매개 변수, 하드웨어 구성 제한 MySQL의 서비스 성능 문제.

셋째, MySQL 서버의 상태를 보려면 값을 실행

시스템의 동시 요청 수가 높지 않고, 쿼리가 느린 경우,이 단계는 직접 단계를 조정 SQL 문을 생략 할 수 있습니다.

명령을 실행합니다 :

show status

결과가 게시되지 않습니다 반환 너무 많은 결과입니다. 그 중, 결과는 다시, 우리는 "조회", "Threadsconnected"와 "Threadsrunning", 즉 문의, 나사 연결의 수와 실행 스레드 수의 가치에 초점을 맞 춥니 다.

우리는 상태 값을 실행하는 모니터 MySQL 서버에 다음 스크립트를 실행할 수 있습니다

#!/bin/bash
while true
do
mysqladmin -uroot -p"密码" ext | awk '/Queries/{q=$4}/Threads_connected/{c=$4}/Threads_running/{r=$4}END{printf("%d %d %d\n",q,c,r)}' >> status.txt
sleep 1
done

24 시간, 내용에 두번째 MySQL의 서비스 당 요청 번호를 다시 한 Status.txt를 얻기위한 스크립트를 실행 == == AWK에 의해 계산

awk '{q=$1-last;last=$1}{printf("%d %d %d\n",q,$2,$3)}' status.txt

생성 엑셀 그래프 계산 콘텐츠 복사는 주기적으로 데이터를 관찰했다.

주기적인 변화는 캐시 무효화 정책을 수정할 수도 해석 필요로 데이터를 관찰합니다.

예를 들면 :

IN [3,6,9]는 캐시 미스의 시간 간격 등의 값에 의해 취득 된 난수는, 캐시가 유효하므로 분산되고, 따라서 메모리 사용량의 일부를 저장.

캐시 실패 요청의 분할 부분의 피크를 액세스하면, 다른 부분은 따라서 압력 MySQL 서버를 감소 MySQL 데이터베이스 액세스이다.

넷째, 최적화 된 SQL 문을 얻기 위해 필요

4.1 방법 1 : 실행중인 스레드를보기

명령을 실행합니다 :

show processlist

반환 결과 :

mysql> show processlist;
+----+------+-----------+------+---------+------+----------+------------------+
| Id | User | Host      | db   | Command | Time | State    | Info             |
+----+------+-----------+------+---------+------+----------+------------------+
|  9 | root | localhost | test | Query   |    0 | starting | show processlist |
+----+------+-----------+------+---------+------+----------+------------------+
1 row in set (0.00 sec)

반환 된 결과에서, 우리는 스레드가 명령 / SQL 문 및 실행 시간을 실행하는 것을 이해할 수있다. 실제 응용 프로그램이 쿼리는 결과가 N 기록이있을 것이다 반환합니다.

그 중, 국가의 반환 값이 판사 좋은 또는 나쁜 성능의 열쇠 는 값이 나타납니다이 다음은, 행은 SQL 문을 최적화하는 데 필요한 :

Converting HEAP to MyISAM # 查询结果太大时，把结果放到磁盘，严重
Create tmp table #创建临时表，严重
Copying to tmp table on disk  #把内存临时表复制到磁盘，严重
locked #被其他查询锁住，严重
loggin slow query #记录慢查询
Sorting result #排序

4.2 방법 : 느린 쿼리 로그를 켜

에서 [mysqld를]의 구성 파일 my.cnf의 두 파라미터들의 다음 행을 추가

slow_query_log = 1
slow_query_log_file=/var/lib/mysql/slow-query.log
long_query_time = 2

log_queries_not_using_indexes = 1

상기 식에서, slowquerylog = 1은 느린 쿼리를 돌려 나타낸다 slowquerylogfile 느린 쿼리 로그 저장 위치를 ​​나타냅니다; logqueriesnotusing_indexes = 1 녹음 인덱스 SQL 문을 사용하지 않습니다 longquerytime = 2가 로그인하기 전에 쿼리> = 2 초 있음을 나타냅니다.

참고 : 경로 slowquerylog_file 그냥 쓰기, 그렇지 않으면 지정된 디렉토리에 기록 MySQL의 서버 로그 파일에 대한 권한이 없습니다 수 없습니다. 권장 경로는 바로 위에 복사됩니다.

파일 저장 수정 한 후, MySQL의 서비스를 다시 시작합니다. 그것은은 / var / lib / mysql / 디렉토리에 천천히 query.log 로그 파일을 만듭니다. MySQL 서버에 연결 구성을 보려면 다음 명령을 실행할 수 있습니다.

show variables like 'slow_query%';

show variables like 'long_query_time';

슬로우 쿼리 로그를 테스트 :

mysql> select sleep(2);
+----------+
| sleep(2) |
+----------+
|        0 |
+----------+
1 row in set (2.00 sec)

슬로우 쿼리 로그 파일을 엽니 다

[root@localhost mysql]# vim /var/lib/mysql/slow-query.log
/usr/sbin/mysqld, Version: 5.7.19-log (MySQL Community Server (GPL)). started with:
Tcp port: 0  Unix socket: /var/lib/mysql/mysql.sock
Time                 Id Command    Argument
# Time: 2017-10-05T04:39:11.408964Z
# User@Host: root[root] @ localhost []  Id:     3
# Query_time: 2.001395  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
use test;
SET timestamp=1507178351;
select sleep(2);

우리는 기록 할 수있는 SQL 문을 수행하기 위해 두 초 볼 수 있습니다.

슬로우 쿼리 로그에 기록 느린 SQL 쿼리 정보 만 집중적으로 어려운의 로그 기록을 보는 있지만. 따라서, 우리는 SQL 도구를 통해 필터링 할 필요가있다.

MySQL은 mysqldumpslow 제공하는  로그 분석 도구를 . 우리는 관련 사용량을 볼 수 mysqldumpslow --help 명령을 사용할 수 있습니다.

다음과 같은 공통 매개 변수는 다음과 같습니다

    -s：排序方式，后边接着如下参数
        c：访问次数
        l：锁定时间
        r：返回记录
        t：查询时间
    al：平均锁定时间
    ar：平均返回记录书
    at：平均查询时间
    -t：返回前面多少条的数据
    -g：翻遍搭配一个正则表达式，大小写不敏感

케이스 :

获取返回记录集最多的10个sql
mysqldumpslow -s r -t 10 /var/lib/mysql/slow-query.log

获取访问次数最多的10个sql
mysqldumpslow -s c -t 10 /var/lib/mysql/slow-query.log

获取按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/slow-query.log

 

SQL 문 V. 분석

5.1 방법 1 : 설명

문제가있는 SQL을 선별, 우리는 MySQL을보기 SQL 실행 계획 케이스 (연관 테이블, 테이블 질의 시퀀스, 인덱스 사용 등)을 설명 제공 할 수 있습니다.

사용법 :

explain select * from category;

반환 결과 :

mysql> explain select * from category;
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | category | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

필드 설명 : 1) ID : 질의 시퀀스 번호를 선택합니다. 동일한 ID, 실행 순서 위에서 아래로, 식별 다른 더 큰 값보다 높은 우선 순위 번호는 첫번째 실행될

2) SELECT_TYPE : 값이 다음과 같은 동작이다 질의 데이터 유형 :

• 단순 : 간단한 쿼리는 서브 쿼리 나 조합을 포함하지 않는
• 1 차 : 복잡한 서브 쿼리를 포함, 값의 바깥 쪽 쿼리 마크
• 부질 : 또는 여기서 선택 이루어지는 서브 쿼리,이 값은 표지
• 파생 : 목록에 포함 된 하위 쿼리는이 값에서 표시됩니다, MySQL을 것이다 재귀이 하위 쿼리, 임시 테이블의 결과
• 노동 조합 : 노동 조합에 이어 두 번째 선택이 나타납니다는, 그 값을 표시 한 경우. 외층에서 서브 쿼리에 포함되는 조합이 선택되면 표시된 유래
• 노조 결과 : 노조 테이블에서 결과를 선택할 수

3) 테이블 : 테이블의 행 데이터를 디스플레이

4) 파티션 : 파티션 경기

5) 유형 : 접속 테이블의 종류, 그 값이 높은 순서의 끝에서 다음 특성 :

• 시스템 : 테이블이 시스템 테이블에 해당하는 만 행이
• CONST : 인덱스를 통해 일단 데이터 매칭의 한 행을 찾을 수
• eq_ref : 고유 인덱스는 테이블 경기에서 하나 개의 레코드 만, 각 인덱스 키를 스캔. 일반적으로 기본 키 또는 고유 인덱스 스캔에 사용
• REF : 고유하지 않은 인덱스 스캔, 별도의 값과 일치하는 모든 행을 반환합니다. A = <또는> 오퍼레이터는 열 색인
• 범위 : 행만을 선택하는 인덱스를 사용하여, 소정의 범위의 행을 검색한다. 일반적으로>, <상황간에 사용
• 인덱스 : 인덱스 트리만을 탐색
• ALL : 전체 테이블 스캔, 최악의 성능

참고 : 처음 다섯 사례 이상적인 상황 인덱스 사용합니다. 보통 레벨 범위에 적어도 최적화, 그것은 심판을 최적화하는 것이 가장 좋습니다

6)이 possible_keys : MySQL은 행을 찾으려면이 테이블에 사용할 인덱스를 나타냅니다. 값이 NULL 인 경우 성능을 향상시키기 위해 색인을 생성 할 수있는 인덱스 설명을 사용하지 않는

7) 키 : 표시 인덱스 MySQL이 실제로 사용. NULL 경우, 인덱스 쿼리를 사용하지 않는

8)에있는 key_len : 인덱스에 사용되는 바이트의 수는 쿼리에 사용 인덱스 컬럼 길이로 산출했다. 정확도 손실없이, 길이가 짧은, 더 나은 디스플레이는 인덱스 필드의 최대 길이가 아닌 실제 길이입니다

9) REF : 표시하는 테이블 분야 테이블과 연관된 인덱스 필드

10) 행 : 선택 테이블 통계 케이스수록 원하는 기록 또는 판독, 작은 값을 찾는 데 필요한 라인의 개수의 대략적

11) 여과 : 행의 수의 비율이 판독 된 행의 수를 나타내는 결과를 반환수록 값

12) 추가 : 다른 열에 표시하지만 추가 정보를 매우 중요 부적절 포함, 공동의 가치는 다음과 같습니다 :

• filesort를 사용 : MySQL은 대신 테이블의 인덱스 순서를 읽는, 외부 데이터 순서 인덱스를 사용하여 설명한다. 값의 출현은 최적화되어야 SQL
• 일시적으로 사용 : 임시 테이블의 사용은 중간 결과를 개최, MySQL의 쿼리 결과를 정렬 할 때 임시 테이블을 사용합니다. 정렬에 의해 쿼리 그룹을 그룹화하여 위해 일반적인. 값의 출현은 최적화되어야 SQL
• 사용 지수 : 데이터 액세스 테이블 행을 피하기 위해 해당 인덱스를 선택하여 대응하는 동작을 좋은 효율로 표시
• 어떤 라인 where 절을 제한합니다 어디에 사용
• 버퍼 조인 사용 : 사용 연결 캐싱
• 구분 : 첫 번째 이상의 라인의 현재 행 조합에 대한 일치, 정지 검색을 찾을 수

참고 : 두 값의 출현하기 전에, SQL 문을 최적화해야합니다.

5.2 두 번째 방법 : 프로파일 링

SQL 문 (실행의 각 단계의 비용) 자원을 소모에 대한 자세한 내용을 보려면 프로파일 명령을 사용하십시오.

5.2.1 정보보기 케이스 오픈

select @@profiling;

반환 결과 :

mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
|           0 |
+-------------+
1 row in set, 1 warning (0.00 sec)

0 차례로 1 대표, 오프 나타냅니다

프로필을 사용 5.2.2

set profiling = 1;  

반환 결과 :

mysql> set profiling = 1;  
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
|           1 |
+-------------+
1 row in set, 1 warning (0.00 sec)

연결이 끝나면 프로파일 상태가 자동 폐쇄 상태로 설정된다.

실행 된 SQL 5.2.3 목록보기

show profiles;

반환 결과 :

mysql> show profiles;
+----------+------------+------------------------------+
| Query_ID | Duration   | Query                        |
+----------+------------+------------------------------+
|        1 | 0.00062925 | select @@profiling           |
|        2 | 0.00094150 | show tables                  |
|        3 | 0.00119125 | show databases               |
|        4 | 0.00029750 | SELECT DATABASE()            |
|        5 | 0.00025975 | show databases               |
|        6 | 0.00023050 | show tables                  |
|        7 | 0.00042000 | show tables                  |
|        8 | 0.00260675 | desc role                    |
|        9 | 0.00074900 | select name,is_key from role |
+----------+------------+------------------------------+
9 rows in set, 1 warning (0.00 sec)

명령이 실행되기 전에, SQL 문은 (는) 추가 녹화를 수행해야합니다.

5.2.4 쿼리 ID 지정된 실행 세부 사항

show profile for query Query_ID;

반환 결과 :

mysql> show profile for query 9;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000207 |
| checking permissions | 0.000010 |
| Opening tables       | 0.000042 |
| init                 | 0.000050 |
| System lock          | 0.000012 |
| optimizing           | 0.000003 |
| statistics           | 0.000011 |
| preparing            | 0.000011 |
| executing            | 0.000002 |
| Sending data         | 0.000362 |
| end                  | 0.000006 |
| query end            | 0.000006 |
| closing tables       | 0.000006 |
| freeing items        | 0.000011 |
| cleaning up          | 0.000013 |
+----------------------+----------+
15 rows in set, 1 warning (0.00 sec)

각 줄은 상태 변화 과정뿐만 아니라 기간입니다. 국가의 열과 쇼 PROCESSLIST의 상태는 동일합니다. 따라서,주의가 상술과 같은 점에서 최적화되어야한다.

CPU, 블록 IO 및 기타 정보를 얻을 5.2.5

show profile block io,cpu for query Query_ID;

show profile cpu,block io,memory,swaps,context switches,source for query Query_ID;

show profile all for query Query_ID;

여섯째, 최적화 방법

주로 설명하는 디자인을 사용하여 쿼리 최적화, 인덱스 및 테이블 구조이다.

6.1 쿼리 최적화

1) SELECT *을 피하고 필요한 것 데이터는 해당 필드를 쿼리합니다.

2) 작은 테이블 중심 큰 테이블, 즉 작은 데이터 세트는 대용량 데이터 세트를 구동한다. 예컨대 다음 A, B 개의 테이블, 예를 들어, 두 개의 테이블 ID 필드를 대응하여.

B가 적은 테이블 데이터 테이블에 존재 최적화 세트보다 경우 표 B, 표 A의 순서를 확인하고 확인하기 위해, 두 개의 테이블이 수행에 사용

select * from A where id in (select id from B)

A가 B보다 작 으면 테이블 데이터 세트 테이블에 최적화 존재, 존재하여, 두 테이블은 다음 표 A 검사의 순서는 표 B를 확인하기 위해 수행

select * from A where exists (select 1 from B where B.id = A.id)

3) 어떤 경우에는 연결의 사용은 가입 이후, MySQL은 메모리에 임시 테이블을 만들지 않습니다, 대신에 하위 쿼리를 사용할 수 있습니다.

4) 바람직하게 연관된 테이블을 줄이고, 중복 필드를 추가했다.

5) 인덱스의 합리적인 사용 ()는 후술. 이에 따라 다음 filesort을 피하기 위해, 그룹, 인덱스 필드를 정렬합니다. 더 : 데이터 구조 및 최적화 재고에 MySQL의 인덱스

6.2을 사용하여 색인

인덱스 장면의 사용 6.2.1

1) 기본 키는 자동으로 고유 인덱스를 생성

쿼리 조건 자주 2) 필드

필드 3) 다른 테이블과 관련된 쿼리

4) 쿼리 필드를 정렬

5) 통계 질문 또는 필드 그룹

사용 지수에 적합하지 6.2.2 장면

1) 자주 업데이트 분야

2) 현장 조건 미만으로

3) 테이블도 기록

4) 일반 테이블 CRUD

5) 상기 차분 필드 값 또는 약간 높은 반복성

6.2.3 인덱스 생성 및 사용 원칙

1) 단일 테이블 쿼리 : 쿼리에 대한 열, 컬럼에 인덱스를 생성

2) 멀티 테이블 쿼리 : 당신은 가입 떠날 때, 오른쪽 테이블 관련 분야에 추가 인덱스, 오른쪽에 가입 할 때, 인덱스가 왼쪽 필드의 상관 관계 테이블에 추가

3) 어떤 동작을 수행하지 않음 (계산 형식 변환) 컬럼 인덱스

4) 인덱스 열을 사용하지 않음! =, <> 동일하지 않은

5) 열 인덱스가 비어 있지이며, 사용하지 않는 널 또는 널 분석 아니다

6) 인덱스 필드는 문자열 유형의 쿼리 조건 따옴표 '의 값을 증가 자동 전환을 방지하기 위해 바닥을 입력하는

위의 원칙에 위배 인덱스의 오류가 발생할 수 있으며, 특정의 상황을 볼 명령을 설명 할 필요가

6.2.4 실패 인덱스 케이스

인덱스 생성 및 사용의 원칙을 위반하는 것 외에도, 다음과 같은 경우는 인덱스의 실패로 이어질 수 있습니다 :

1) 퍼지 조회는 %로 시작하는 경우

2)로 사용하거나 : 필드 1 (비 인덱싱) 또는 필드 2 (인덱스) 실패 인덱스를 일으킬 것이다.

3) 제 인덱스 열을 사용하지 않고, 복합 지표를 사용하는 경우.

지표 (A, B, C)는, 예를 들면 지수로서 A, B, C를 필드한다 :

 

해당 데이터 유형의 데이터베이스 테이블 구조 6.3 디자인 선택 6.3.1

1)를 사용하여 최소의 데이터 유형의 데이터를 저장할 수있다

단순 데이터 유형 2) 사용. 간단한보다는 MySQL의 과정에서 INT VARCHAR 타입

3) 메이크업 사용 TINYINT, 오히려 일체형 int로서보다 SMALLINT, MEDIUMINT

널 공간의 4 바이트를 차지하기 때문에 4), NOT NULL을 사용하여 가능한 한 필드를 정의

5) 텍스트 형식의 사용을 최소화, 아닌 서브 테이블을 사용할 때 고려해야 할 권장하지 않습니다

6) 날짜 타임 스탬프 대신 사용해보십시오

(가) (20)를 권장 내 7), 너무 많은 단일 테이블 필드가하지 마십시오

분할 표 6.3.2

데이터베이스의 데이터가 매우 큰 경우, 쿼리 최적화 계획, 우리는 분할 테이블을 고려할 수 느린 쿼리의 문제를 해결하지 않을 것이다, 각 테이블 때문에 데이터가 작고, 따라서 개선 쿼리 효율성되고있다.

1) 수직 분할은 다음 표에 복수 열에서 다른 테이블로 구분되어있다. 예를 들어, 사용자 테이블의 일부 필드는 테이블의 이러한 필드가 추가 필드의 숫자가없는 다른 테이블에 사용, 자주 액세스 할 수 있습니다. 때 삽입 된 데이터는 트랜잭션을 사용하여 두 테이블의 데이터 일관성을 보장합니다.

2) 수평 분할 : 행 분할. 예컨대 사용자 테이블, 사용자 ID, 이상 10 접근에 대한 사용자 ID, 표 0-9에서, 사용자 (10)에 사용자 데이터의 고른 분포. 때이 규칙에 따라 또한 쿼리 데이터를 찾을 수 있습니다.

6.3.3 별도의 읽기 및 쓰기

데이터베이스에 대한 정상적인 상황이에서 "읽기 - 쓰기 적은." 즉, 데이터베이스의 압력은 주로 작업의 다수 발생 데이터를 읽을 수 있기 때문이다. 우리는, 데이터베이스 클러스터 솔루션을 사용하여 라이브러리로 주요 라이브러리를 사용하여 데이터를 기록 할 책임이있다, 다른 라이브러리 라이브러리에서 데이터를 읽기위한 책임이 있습니다. 이 데이터베이스에 액세스에 대한 압력을 완화합니다.

세븐, 서버 조정 매개 변수

7.1 메모리 관련

메모리 버퍼 사이즈 정렬 sortbuffersize

연결 joinbuffersize를 사용하여 버퍼 사이즈

전체 테이블은 크기 readbuffersize 버퍼 할당 스캔 할 때

7.2 IO 관련

Innodblogfile_size 트랜잭션 로그 크기

트랜잭션 로그의 Innodblogfilesingroup 번호

Innodblogbuffer_size 트랜잭션 로그 버퍼 크기

Innodbflushlogattrx_commit 트랜잭션 로그 재생 전략, 그 값은 다음과 같습니다 :

0 : 매 초마다 로그 캐시를 작성하고, 디스크에 플러시 로그

1 : 각 트랜잭션 로그 쓰기 캐시에 제출하고, 디스크에 플러시 로그

2 : 트랜잭션이 커밋 될 때마다 캐시에 기록 실행 로그 데이터는 디스크에 두 번째 플러시 로그에 한 번 실행

7.3 보안 관련

expirelogsdays는 일수의 자동 정리를 지정 바이너리 로그

maxallowedpacket MySQL은 수신 된 패킷의 크기를 제어 할 수있다

skipnameresolve 안 DNS 조회

READ_ONLY 비 슈퍼 사용자 권한 쓰기 권한 금지

skipslavestart 수준 당신은 노예 자동 복구를 사용

기타 7.4

최대 연결 수는 제어 MAX_CONNECTIONS에 의해 허용

임시 테이블 크기를 tmptablesize

최대 메모리 크기 테이블 maxheaptable_size

내가 MySQL 서버 튜닝, 실적 결과에 이러한 매개 변수를 사용하여 특정 세부 사항을 소개하지 않았다 기사의 끝 부분에있는 정보를 참조하거나 바이하시기 바랍니다.

여덟, 하드웨어 구입 및 매개 변수 최적화

하드웨어의 성능은 직접 MySQL 데이터베이스의 성능을 결정합니다. 하드웨어 성능 병목 직접 운영 데이터 및 MySQL 데이터베이스의 효율성을 결정합니다.

소프트웨어 개발자 프로그래머로서, 우리는 당신이 이해 수있는 하드웨어를 최적화하기 위해 콘텐츠를 최적화 소프트웨어에 초점을

8.1 메모리 관련

빠른 하드 드라이브를 많이 이상의 IO 메모리, 당신은 시스템의 버퍼 용량을 증가시킬 수 있습니다, 데이터는 디스크 IO를 줄이기 위해 더 이상 메모리에 유지

8.2 디스크 I / O 관련

1) 또는 SSD SSD PCle 장치를 이용하여, IOPS 해제 시간 중 적어도 수백 또는 수천 수득

2) 동시에 수집 카드 어레이 CACHE BBU 모듈 크게 IOPS을 향상시킬 수있다

3) 가능한 RAID-10의 선택, RAID-5 등 대신에

8.3 구성 관련 CUP

다음과 같이 BIOS 설정 서버에서 조정 :

1) 와트 당 성능 최적화 (DAPC) 모드를 선택 최대의 CPU 성능을 재생

2) 닫기 C1E C, 대한민국 및 기타 옵션을 CPU 효율성을 향상

3) 메모리 주파수 (주파수 메모리) 선택 최대 성능