I used a host with Fedora 19 and Linkbench to determine the ability of memory allocators to avoid fragmentation with MyRocks (MySQL+RocksDB). RocksDB can create pressure on an allocator because allocations for the block cache can have a short lifetime. Memory is allocated on page read and released when a page is evicted from the cache. The allocation is the size of the decompressed page and sometimes the size of the compressed page. RocksDB puts more pressure on the allocator than InnoDB because with InnoDB the buffer pool allocation is done once at process start. After the Linkbench load finished I ran the query test for 24 hours and report the values of VSZ and RSS from ps at the end. From the results below jemalloc & tcmalloc do much better at avoiding fragmentation (value of RSS) compared to glibc 2.1.7. I am still adjusting to larger values of VSZ with jemalloc. It isn't a problem, but it takes time to accept.
VSZ RSS allocator
22246784 10062100 jemalloc
13600032 10545284 tcmalloc
26136152 20313268 glibc
Test details:
- Linkbench with maxid=100M, loaders=10, requesters=20
- MyRocks with 8G block cache for RocksDB
- libc is glibc 2.17, tcmalloc from gperftools 2.1, jemalloc 3.6.0
%20_%20(QPS%20for%208.0.34).png)
No comments:
Post a Comment