MySQL InnoDB Caching
|
110601 |
v1.0 |
|
|
|
|
|
|
|
|
|
1.
InnoDB
Caching
아래의 Reality of InnoDB Caching, InnoDB
Caching 은 MySQL Performance Blog 의 ‘Peter Zaitsev’ 가 기고한 글을 해석한 것이다.
A.
Reality
of InnoDB Caching
|
I have mentioned few times Innodb caches data in pages
and even if you have working set consisting of relatively few rows your
working set in terms of pages can be rather large. InnoDB 는 당신이 상대적으로 적은 로우로 구성된 워킹셋을 가지고 있다 하더라도 페이지의 데이터를 캐싱한다고 이야기 했었다. Now I came to do a little benchmark to show it in
practice. I’m using standard “sbtest” with 10mil rows with data file of
2247098368 which gives us 224 bytes of gross storage per row, including all
overhead etc. 표준 sbtest 를 사용해 한 로우에 대해 224 바이트라는 비대한 크기를 가진 2기가 상당의 천만개 로우를 이용해 간단히 벤치하겠다. Actual row size in this table is smaller but lets use
this number for our math. For benchmark I’m using set number of random IDs
which are repeatedly selected in random order, which would illustrate data
set with 이 테이블의 실제 로우 사이즈는 작지만 이 수를 사용해보겠다. 벤치마크를 위해 나는 정렬되어 있지 않은 random ID 집합을 무작위 정렬하여 반복적으로 select 하여 사용했고, 이는 hot rows 무작위로 분산하는 것으로 보였다. 각각의 로우를 사전에 읽어들였고, 그럼으로써 메모리가 충분히 존재한다면 아무런 disk reads 가 발생하지 않을 것이다.
나는 128M 의 buffer pool 을 이 테스트에 사용하였고, 이는 224 바이트에 50만 로우정도의 크기이다. 여기서 벤치마크의 결과를 보겠다. |
|
As we see in this case database can really fit only
somewhere between 6400 and 12800 different rows which is about 1/50 of
“projected size”. This number is very close to what I would have estimated – With 224 bytes per row we have some 70 rows per page so
with random distribution you would expect up to 70 times data which have to
be fetched to the database than you need. 이 케이스에서 6400 ~ 12800 의 다른 로우에 대해서는 예상크기의 1/50 으로 맞아들었다. 로우당 224 바이트며 페이지당 70 로우를 가지니 랜덤분산으로 당신이 패치되기를 기다리는 양의 70배를 예상할 수 있다.. I’m wondering if any over storage engine can show
better results in such benchmark. Falcon with plans for row cache would fair
better, so I would expect better results with PBXT. I also should check with 나는 다른 엔진에서도 이보다 더 좋은 결과를 보일 수 있는지 궁금했다. Falcon 을 사용한 row cache 가 더 좋은 결과를 낼 것이다, 그래서 나는 PBXT 에서 더 좋은 결과를 보일 것으로 예상한다. 나는 또한 Percona
Server 환경에서 보다 작은 Page 사이즈에서 체크해봐야 할 것이다. 내 예상으로는 4K 페이지 사이즈에서 4배의 distinct rows 를 캐쉬에 적재할 수 있다. |
B.
InnoDB
Caching (part 2)
|
Few weeks ago I wrote about Innodb Caching with main idea you might need more
cache when you think you are because Innodb caches data in pages, not rows,
and so the whole page needs to be in memory even if you need only one row
from it. I have created the simple benchmark which shows a worse case scenario
by picking the random set of primary key values from sysbench table and
reading them over and over again. 몇 주전
InnoDB Caching 에 있어 당신이 생각한 메모리보다 더 많은 메모리가
Caching 에 필요할 거라 이야기 했다. 그 이유는
InnoDB 가 로우가 아닌 페이지 안의 데이터를 캐싱하며, 단순히 하나의 Row 가 필요하다 하더라도 모든 페이지가 메모리에 있어야 한다. 나는
sysbench table 의 Primary key values 로 구성된 랜덤set 으로부터 몇 번이고 읽어들이는 작업을 통해 나쁜 케이스를 만들어 간단히 확인하였다. This time I decided to “zoom in” on the time when result drop
happens – 2x increase in number of rows per step hides a lot of details, so
I’m starting with some number of rows when everything was still in cache for
all runs and increasing number of rows being tested 20% per step. I’m trying
standard Innodb page size, 4KB page size as 16K page size compressed to 4.
The data in this case compresses perfectly (all pages could be compressed to
desired 4K) value so it is testing a best case for compression. Here is the
graph: 이번에는
result 가 줄어들었을 때의 상황을 좀더 자세히 보겠다. 각 스텝에 있어 rows
가 2배 증가했을 때 많은 상세정보를 숨긴다. 그래서 몇 개의 rows
를 이용해 모든 것이 여전히 캐시되어 있고 각 스텝마다 로우수가 20% 증가하도록 증가시켰다.
Standard InnoDB page size 로 4KB 를 사용하였고 16KB
사이즈를 4로 압축하였다. 이 케이스의 데이터는 완벽하게 압축되었다. (모든 페이지는 4K 로 압축가능할 것이다. ) 그래서 이는 테스팅하기 위한 가장 좋은 케이스이다. 여기에 그래프를 보겠다. |
|
The results are quite interesting from a lot of angles.
First we can see how quickly performance can drop in worse case scenario when
data is not in cache any more. For 16K pages we see over 10x drop from 7630
qps to 580 qps as number of keys accessed increases only 20% from 9216 to
11059. 다각적으로 재미있는 결과가 나왔다. 우선 나쁜 케이스 (데이터가 캐쉬되어 있지 않는) 시나리오에 대해 퍼포먼스가 얼마나 빨리 떨어질 수 있는가에 대해 알 수 있다. 16K pages 에 대해 우리는 엑세스 되는 key 가 9216 에서 11059 로 단순히 20% 증가했을 때 7630 qps 에서 580 qps 로 10배가 넘는 drop 을 볼 수 있다. The results for 4K results start dropping earlier. This
is because the database actually takes more space with 4K pages – 2.7GB
instead of 2.2GB because of larger overhead. They also drop in a lot more gradual
fashion compared to 16K results. They still retain almost half of performance
at 27.5K even though drops starts at about 9.2K keys, which is less than 3x
performance loss with 3 times increase in number of keys, which is way
different to 10x performance drop for 16K pages. 4K 에 대한 결과는 성능이 더 빨리 떨어진다. 그 이유는 데이터베이스가 실제로는 4K 보다 더 많은 공간을 차지하기 때문이다 - 2.2GB 가 아닌 2.7GB 를 차지 하는 부하가 있기 때문이다. 이는 16K 랑 비교해서도 더 많이 떨어지는 것을 알 수 있다. 이는 27.5K 에서 퍼포먼스의 50% 정도를 유지하고 있다. 이는 3배의 퍼포먼스 증가에대한 3배의 퍼포먼스 손실보다 작다. 이는 16K 에서의 10배의 퍼포먼스 다운과는 다르다. I do not have a
very good explanation why this is happening. Compression results come as a huge disappointment. The
compressed .idb file was only 620MB so if Innodb would chose to keep only
compressed pages in memory it should be able to keep about 1/5 of pages
cached in 128M buffer pool. It could be compared to 4K pages case just with
1/4 of data (and the overhead needed for page decompression) if this is the
policy innodb would have chosen. In reality however results are a lot more close
to 16K page results with rather quick drop happening. About same number of
qps (530) is reached at 15925 compared to 11049 which is about 40% more keys. 이 현상에 대해 설명하기는 어렵다. 종합된 결과에서 큰 실망을 했다. 압축된 .idb 파일은 겨우 620MB 이다. 만약 InnoDB 가 압축된 페이지를 메모리에 keep 한다면 1/5 수준의 페이지가 128M buffer
pool 에 캐시되어야 한다. 이는 1/4 데이터 (페이지 압축 해제에 추가 부하가 발생) 4K 페이지의 경우와 비교될 수 있다. 만약 이게 InnoDB 가 선택한 정책이라면 실제로는 16K 페이지 결과와 더 비슷해져야 할 것이다. 같은 넘버의 qps (530) 은 15925 에 다다르며 11049 와 비교했을 때 40 % 가 더 많다. Where Compression results were good though is with very
low number of keys, when everything could be kept uncompressed in buffer pool
as well as in case of complete disk IO bound workload. It is hard to see from
the graph but with large number of keys compressed results were best of all,
probably because the data size was smallest. 압축 결과는 모든것이 압축해제된 상태로 buffer pool 에 존재하며 complete disk
IO 바운드 워크로드로 매우 적은 키에 대해서는 좋은 결과를 보여준다. 그래프 상에서는 이를 보기는 힘들지만 많은 수의 압축된 키에 대한 결과는 가장 좋은 결과를 보여준다, 아마도 데이터 사이즈가 가장 작기 때문으로 보인다. Lets introduce one more metric. Lets say “acceptable”
results for our application is 2000 qps, which is about 25% of the
performance when data fits in memory. I just pick this number for simplicity,
though I think it is quite reasonable as the target. With such definitions
16K provides acceptable performance with 9216 keys touched, 4K with 27518 and
16K compressed with 11516. This gives us 3x more keys we can fit in memory
with 4K pages, which is pretty good even though not quite 4 times increase
which we could hope for in theory. This is explained by the fact data size is
almost 30% larger with 4K pages. 통계지표 하나를 더 소개하겠다. 우리의 어플리케이션에 수용할만한 결과는 2000 qps 이다. 이는 데이터가 메모리에 맞을 때 25% 의 퍼포먼스를 낸다. 나는 이 숫자를 단순화하여 뽑았고, 타겟으로는 상당히 타당하다고 생각한다. 9216개의 키를 터치하는 성능으로는 16K 는 허용할 만하다. 4K 의 27518 과 16K 의 압축된 11516 . 이것은 4K의 페이지를 메모리에 적재하는데 3배의 더 많은 키를 주며 정확하게 4배는 아니더라도 이 이론으로는 희망을 가질 만 하다. 이는 사실에 근거한 데이터 사이즈로 설명되는데 4K 페이지에서 30% 더 크다. . In this case Percona Server 5.5 was tested, which
allows changing page size without recompiling the server, though I expect
results for 16K and 16K Compressed to be very similar on MySQL 5.5 이 케이스에는 Percona
Server 5.5 가 테스트되었다. 이는 서버의 recompiling 없이 page size 변경을 허용하며 그렇기에 16K 와 압축된 16K 에 대한 결과는 MySQL 5.5 와 비슷할 것으로 추측한다. As a summary: If you have very random access pattern
with small rows consider using 4K pages, compression may not give you much
gains from cache fit efficiency. Next I should look more about performance of different
storage engines in this regard. I’m very curious how PBXT and TokuDB would
perform in this kind of benchmark. I also should modify benchmark to be able
to do writes the fixed number of keys to see if it makes any difference.
Finally I should post my benchmark script so everyone interested can repeat
my results. 요약 : 당신이 적은 로우를 랜덤으로 엑세스하는 패턴을 가지고 있다면 4K 페이지 사용을 고려한다. 하지만 압축은 생각보다 좋은 성능을 주진 못한다. 다음에는 서로 다른 스토리지 엔진에 대해 성능을 비교하려 한다. 나는 PBXT 와 TokuDB 가 이번 같은 벤치에 어떻게 동작하는지 궁금하다. 그리고 벤치마크를 이것이 만들어내는 차이를 보기위해 특정 키의 수만큼 쓰기가 가능하도록 변경해야 한다. 마지막으로 벤치마크 스크립트를 다른 사람이 보고 테스트 할 수 있게 포스팅하려 한다. |
3.
References
A.
MySQL Performance Blog |
Reality of InnoDB Caching |
http://www.mysqlperformanceblog.com/2011/04/21/reality-of-innodb-caching/
B.
MySQL Performance Blog | InnoDB
Caching
http://www.mysqlperformanceblog.com/2011/05/10/innodb-caching-part-2/
