mysql의 innodb_flush_method 메소드의 자세한 예

다음 편집기에서는 innodb_flush_method 값 방법에 대한 기사를 제공합니다(예제 설명). 에디터가 꽤 좋다고 생각해서 지금 공유해서 참고용으로 올려보겠습니다. 편집자를 따라가서 살펴보겠습니다

innodb_flush_method의 몇 가지 일반적인 값

fsync: InnoDB uses the fsync() system call to flush both the data and log files. fsync is the default setting.

O_DSYNC: InnoDB uses O_SYNC to open and flush the log files, and fsync() to flush the data files. InnoDB does not use O_DSYNC directly because there have been problems with it on many varieties of Unix.

O_DIRECT: InnoDB uses O_DIRECT (or directio() on Solaris) to open the data files, and uses fsync() to flush both the data and log files. This option is available on some GNU/Linux versions,FreeBSD, and Solaris.

값을 구하는 방법은 mysql공식 문서에서 권장하는 것

How each settings affects performance depends on hardware configuration and workload. Benchmark
your particular configuration to decide which setting to use, or whether to keep the default setting.
Examine the Innodb_data_fsyncs status variable to see the overall number of fsync() calls for
each setting. The mix of read and write operations in your workload can affect how a setting performs.
For example, on a system with a hardware RAID controller and battery-backed write cache, O_DIRECT
can help to avoid double buffering between the InnoDB buffer pool and the operating system's file
system cache. On some systems where InnoDB data and log files are located on a SAN, the default
value or O_DSYNC might be faster for a read-heavy workload with mostly SELECT statements. Always
test this parameter with hardware and workload that reflect your production environment

즉, 특정 값은 하드웨어 구성 및 작업 부하에 따라 달라집니다. 스트레스 테스트를 수행하여 결정하는 것이 가장 좋습니다. 그러나 일반적으로 RAID 컨트롤러 및 다시 쓰기 전략을 사용하는 Linux 환경에서는 저장 매체가 SAN인 경우 o_direct가 더 나은 선택이며 기본 fsync 또는 osync를 사용하는 것이 더 나을 수 있습니다.

일반적으로 대부분의 사람들이 o_direct 값을 설정하고, 맨 아래 레이어에 레이드 카드가 있고, 읽기 및 쓰기 정책이 write-back으로 설정되어 있는 것 같습니다. sysbench를 사용하여 oltp 유형을 스트레스 테스트할 때 성능 면에서 o_direct가 fsync보다 더 낫다는 것을 알았습니다. 그러나 최근에 이러한 SQL을 접했는데 이 경우 고객 피드백이 매우 느렸습니다. 같은 메모리를 사용하더라도 제가 구축한 클라우드 호스트의 성능이 훨씬 빨라졌는데, 나중에 보니 innodb_flush_method의 설정값 차이로 인한 엄청난 성능 차이가 주된 원인이었습니다.

테스트 시나리오 1

innodb_flush_method가 기본값으로 fsync, 캐시 풀 512M, 테이블 데이터 볼륨 1.2G, 캐시풀 영향 제외하면 안정적인 결과

mysql> show variables like '%innodb_flush_me%';
+---------------------+-------+
| Variable_name    | Value |
+---------------------+-------+
| innodb_flush_method |    |
+---------------------+-------+
1 row in set (0.00 sec)


mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+--------------------------+
| SUM(outcome)-SUM(income) |
+--------------------------+
|        -191010.51 |
+--------------------------+
1 row in set (1.22 sec)


mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+--------------------------+
| SUM(outcome)-SUM(income) |
+--------------------------+
|        -191010.51 |
+--------------------------+
1 row in set (1.22 sec)
mysql> explain SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
| id | select_type | table  | type | possible_keys | key    | key_len | ref  | rows  | Extra         |
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
| 1 | SIMPLE   | journal | ref | account_id  | account_id | 62   | const | 161638 | Using index condition |
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
1 row in set (0.03 sec)

테스트 시나리오 2

innodb_flush_method를 o_direct로 변경, 캐시 풀의 영향 제외, 안정적인 결과

mysql> show variables like '%innodb_flush_me%';
+---------------------+----------+
| Variable_name    | Value  |
+---------------------+----------+
| innodb_flush_method | O_DIRECT |
+---------------------+----------+
1 row in set (0.00 sec)


mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+--------------------------+
| SUM(outcome)-SUM(income) |
+--------------------------+
|        -191010.51 |
+--------------------------+
1 row in set (3.22 sec)


mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+--------------------------+
| SUM(outcome)-SUM(income) |
+--------------------------+
|        -191010.51 |
+--------------------------+
1 row in set (3.02 sec)


mysql> explain SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main';
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
| id | select_type | table  | type | possible_keys | key    | key_len | ref  | rows  | Extra         |
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
| 1 | SIMPLE   | journal | ref | account_id  | account_id | 62   | const | 161638 | Using index condition |
+----+-------------+---------+------+---------------+------------+---------+-------+--------+-----------------------+
1 row in set (0.00 sec)

결과 비교:

둘 다 실행 계획은 똑같지만 성과는 많이 다릅니다. 데이터베이스 에서 처음 시작했을 때 쿼리의 결과도 매우 다르며, o_direct도 매우 다릅니다(테스트 결과 생략). 이 경우 운영 체제 캐시를 추가하면 읽기 효율성이 스트레스 테스트를 기반으로 해야 하는 이유가 무엇인지 잘 모르겠습니다. 실제로는 효과가 우세할 것이며 경험 가치는 맹목적으로 신뢰할 수 없습니다.

개선 조치:

innodb_flush_method를 변경하지 않고도 이 SQL은 결합된 인덱스 ( account_id,outcome,income)을 적용하여 인덱스 스캔을 처리하면 응답 시간을 크게 줄일 수 있습니다

[관련 권장 사항]

1. Mysql 무료 동영상 튜토리얼

2. MySQL에서 새로운 사용자 권한을 추가하는 자세한 예

3. MySQL에서 비밀번호 변경 및 액세스 제한에 대한 자세한 예

4 . 정규식을 사용하여 데이터베이스의 콘텐츠를 바꾸는 자세한 예 해결방법

5. mysql에 이미지를 저장하는 PHP의 예에 대한 자세한 설명

위 내용은 mysql의 innodb_flush_method 메소드의 자세한 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!