The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"MySQL и аллокаторы памяти"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Др. сетевые сервисы / Linux)
Изначальное сообщение [ Отслеживать ]

"MySQL и аллокаторы памяти"  +/
Сообщение от ALex_hha (ok) on 26-Мрт-15, 12:53 
После прочтения статьи - http://www.percona.com/blog/2013/03/08/mysql-performance-imp.../

решил таки проверить есть ли отличия или нет, как раз планируем переход на 16ти ядерный сервер.

CentOS 6.6, 30 ГБ RAM, это EC2 инстанс на AWS, если это имеет значение.

CPU: Intel Xeon CPU E5-2680 v2 @ 2.80GHz, 16 ядер


# rpm -qa | grep Percona-Server-server
Percona-Server-server-55-5.5.42-rel37.1.el6.x86_64

# rpm -qa | grep jemalloc
jemalloc-3.6.0-1.el6.x86_64

# rpm -qa | grep gperftools
gperftools-libs-2.0-11.el6.3.x86_64

Настройки mysql


# cat my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
character-set-server=utf8
init-connect='SET NAMES utf8'

thread_cache_size = 4

innodb_buffer_pool_size = 12G
innodb_log_file_size = 512M
innodb_log_buffer_size = 64M
innodb_thread_concurrency = 0

innodb_flush_log_at_trx_commit=2
innodb_doublewrite=0
innodb_flush_method=O_DIRECT

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
character-set-server=utf8

Подготавливаю базу


# sysbench --test=oltp --oltp-table-size=50000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=7654321 --db-driver=mysql prepare

В случае jemalloc/tcmalloc добавляю в секцию [mysqld_safe] строки

malloc-lib=/usr/lib64/libjemalloc.so.1

и

malloc-lib=/usr/lib64/libtcmalloc_minimal.so.4

Через pmap и /proc/mysql_pid/environ проверяю, что соответствующий алокатор подгрузился


# pmap 2891 | grep malloc
00007f2e57854000    196K r-x--  /usr/lib64/libjemalloc.so.1
00007f2e57885000   2048K -----  /usr/lib64/libjemalloc.so.1
00007f2e57a85000      8K rw---  /usr/lib64/libjemalloc.so.1

# cat /proc/2891/environ
LD_PRELOAD=/usr/lib64/libjemalloc.so.1TERM=xtermPATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/binPWD=/usrSHLVL=3MYSQL_HOME=/usr_=/usr/bin/nohup

И запускаю тесты. После каждого теста БД пересоздается, а сервер перегружается, чтобы исключить влияение кеширования.

MALLOC (glibc)


# sysbench --num-threads=16 --test=oltp --oltp-table-size=50000000 --oltp-test-mode=complex --mysql-db=sysbench --mysql-user=sysbench --mysql-password=7654321 --db-driver=mysql --max-requests=0 --max-time=3600 run    sysbench 0.4.12:  multi-threaded system evaluation benchmark

transactions: 10008748 (2780.20 per sec.)


JEMALLOC


# sysbench --num-threads=16 --test=oltp --oltp-table-size=50000000 --oltp-test-mode=complex --mysql-db=sysbench --mysql-user=sysbench --mysql-password=7654321 --db-driver=mysql --max-requests=0 --max-time=3600 run    sysbench 0.4.12:  multi-threaded system evaluation benchmark

transactions: 9787562 (2718.76 per sec.)


TCMALLOC


# sysbench --num-threads=16 --test=oltp --oltp-table-size=50000000 --oltp-test-mode=complex --mysql-db=sysbench --mysql-user=sysbench --mysql-password=7654321 --db-driver=mysql --max-requests=0 --max-time=3600 run    sysbench 0.4.12:  multi-threaded system evaluation benchmark

transactions: 10448024 (2902.23 per sec.)

http://i.piccy.info/i9/ef4c86131616fbc59a19bef4caa4ac65/1427...

три пика это соответственно тест с malloc/jemalloc/tcmalloc. Но как я вижу по графику разницы практически нет. Может я что то не так делаю?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "MySQL и аллокаторы памяти"  +/
Сообщение от me (??) on 27-Мрт-15, 15:38 
> три пика это соответственно тест с malloc/jemalloc/tcmalloc. Но как я вижу по
> графику разницы практически нет. Может я что то не так делаю?

круто, но у Строганова машинка до 5k разгоняется glibc, а у вас больше 3k не идет. Я-б сказал, что лимитирующий фактор ни разу не маллок а.... ну бог его знает, диск возможно. если так: я-б попробовал на tmpfs-е сделать, например.


Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "MySQL и аллокаторы памяти"  +/
Сообщение от ALex_hha (ok) on 27-Мрт-15, 23:42 
>> три пика это соответственно тест с malloc/jemalloc/tcmalloc. Но как я вижу по
>> графику разницы практически нет. Может я что то не так делаю?
> круто, но у Строганова машинка до 5k разгоняется glibc, а у вас
> больше 3k не идет. Я-б сказал, что лимитирующий фактор ни разу
> не маллок а.... ну бог его знает, диск возможно. если так:
> я-б попробовал на tmpfs-е сделать, например.

Ну не знаю, судя по данным, у меня вся база вмещается в innodb_buffer_pool_size, никаких временных таблиц не создается


-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in InnoDB tables: 10G (Tables: 1)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 1

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 13m 45s (210M q [47K qps], 97 conn, TX: 144B, RX: 5B)
[--] Reads / Writes: 73% / 27%
[--] Total buffers: 12.1G global + 2.8M per thread (151 max threads)
[OK] Maximum possible memory usage: 12.5G (42% of installed RAM)
[OK] Slow queries: 0% (0/210M)
[OK] Highest usage of available connections: 11% (18/151)
[OK] Key buffer size / total MyISAM indexes: 8.0M/97.0K
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 20M sorts)
[OK] Temporary tables created on disk: 0% (0 on disk / 10M total)
[OK] Thread cache hit rate: 81% (18 created / 97 connections)
[OK] Table cache hit rate: 85% (42 open / 49 opened)
[OK] Open file limit used: 1% (19/1K)
[OK] Table locks acquired immediately: 100% (190M immediate / 190M locks)
[OK] InnoDB buffer pool / data size: 12.0G/10.5G
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
Variables to adjust:
    query_cache_size (>= 8M)

Да и в выводе речь идет именно о кол-ве ядер - "if your box has more than 8 cores – you should try/evaluate alternative allocators; it can notably boost your MySQL server at no cost."

В тесте конечно ничего не говорится насчет дисковой подсистемы, но у меня используется raid0 на 2х дисках (provisioned ssd по 900 iops каждый), т.е. суммарно где то 1800 iops.

http://i.piccy.info/i9/d88966beb7249d5ab1caf24a2caa394c/1427...

красная - запись, зеленая - чтение

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "MySQL и аллокаторы памяти"  +/
Сообщение от me (??) on 28-Мрт-15, 09:29 
> Ну не знаю, судя по данным, у меня вся база вмещается в
> innodb_buffer_pool_size, никаких временных таблиц не создается

oltp-test-mode=complex: ты-ж пишешь, какая разница куда она там помещается?
с другой стороны: система твоя - тебе виднее :)


Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "MySQL и аллокаторы памяти"  +/
Сообщение от ALex_hha (ok) on 28-Мрт-15, 14:31 
>> Ну не знаю, судя по данным, у меня вся база вмещается в
>> innodb_buffer_pool_size, никаких временных таблиц не создается
> oltp-test-mode=complex: ты-ж пишешь, какая разница куда она там помещается?

разница в том, что диск не столь критичен. Complex лишь означает, что в тесте будет как запись, так и чтение. У них есть read only тесты, например

> с другой стороны: система твоя - тебе виднее :)

меня интересует вообще опыт использования аллокаторов отличных от malloc в контексте mysql. Оно вообще того стоит или только в каких то очень специфичных случаях при очень специфичных условиях

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "MySQL и аллокаторы памяти"  +/
Сообщение от ALex_hha (ok) on 22-Апр-15, 13:38 
В общем, как ни странно, макс tps получил на встроенном аллокаторе, потом уже упирается в CPU. Правда на ядре 3.10.73 из ELRepo, на стоковом 2.6.32 ~ 10% меньше


/etc/my.cnf
query_cache_size = 8M
thread_cache_size = 16
default-storage-engine=InnoDB
innodb_buffer_pool_size = 12G
innodb_log_file_size = 2048M
innodb_log_buffer_size = 64M
innodb_fast_shutdown = 0
innodb_thread_concurrency = 0
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_flush_log_at_trx_commit=0
innodb_doublewrite=1
innodb_flush_method=O_DIRECT

innodb_additional_mem_pool_size = 64M
innodb_use_sys_malloc = 1


OLTP test statistics:
    queries performed:
        read:                            172605426
        write:                           61644795
        other:                           24657918
        total:                           258908139
    transactions:                        12328959 (3424.71 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 234250221 (65069.44 per sec.)
    other operations:                    24657918 (6849.41 per sec.)

Test execution summary:
    total time:                          3600.0035s
    total number of events:              12328959
    total time taken by event execution: 57499.1132
    per-request statistics:
         min:                                  2.54ms
         avg:                                  4.66ms
         max:                              21032.40ms
         approx.  95 percentile:               5.58ms

Threads fairness:
    events (avg/stddev):           770559.9375/1317.18
    execution time (avg/stddev):   3593.6946/0.01

P.S.
Может кто подскажет, почему на результат никак не влияет изменение параметра innodb_io_capacity? Ведь у меня raid 0 на ssd с 1800 IOPS. А дефолтное значение innodb_io_capacity 200, т.е. рассчитан на обычный механический диск.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру