Производительность кэша сегментированных ключей

Метод тестирования производительности кэша сегментированных ключей

Мы использовали SysBench v0.5 с Launchpad для тестирования производительности кэша сегментированных ключей для движка хранения MyISAM в MariaDB 5.2.2-gamma.

В качестве оберточных скриптов для автоматического запуска SysBench мы использовали каталог sysbench/ из MariaDB Tools.

Для проверки того, что разделение глобального мьютекса кэша ключей на несколько мьютексов помогает под нагрузкой с несколькими пользователями, мы написали новый тест SysBench под названием select_random_points.lua. Мы использовали одну большую таблицу и выбирали случайные точки с возрастающим количеством одновременных пользователей.

Основные результаты тестирования

Мы наблюдаем прирост производительности до 250% в зависимости от количества одновременных пользователей.

Подробные результаты тестирования

На нашем компьютере pitbull

На pitbull с --random-points=10

В относительных числах:

Threads	               1      4      8      16      32      64      128
(32/off)             -3%    53%    122%    155%    226%    269%    237%
(64/off)             -6%    55%    130%    162%    234%    270%    253%

select_random_points.lua --random-points=10

На pitbull с --random-points=50

В относительных числах:

Threads	               1      4      8      16      32      64      128
(32/off)             -3%    53%    113%    154%    232%    254%    231%
(64/off)             -1%    55%    121%    161%    235%    268%    244%

select_random_points.lua --random-points=50

На pitbull с --random-points=100

В относительных числах:

Threads	               1      4      8      16      32      64      128
(32/off)             -3%    54%    121%    160%    209%    246%    219%
(64/off)             -6%    56%    129%    167%    219%    260%    241%

select_random_points.lua --random-points=100

Подробные числа всех запусков на pitbull

Вы можете найти абсолютные и относительные числа в нашей электронной таблице OpenOffice.org здесь: SysBench v0.5 select_random_points на pitbull

На нашем компьютере perro

На perro с --random-points=10

В относительных числах:

Threads	               1      4      8      16      32      64      128
(32/off)              1%     2%     17%     45%     73%     70%     71%
(64/off)             -0.3%   6%     19%     46%     72%     74%     80%

select_random_points.lua --random-points=10

На perro с --random-points=50

В относительных числах:

Threads	               1      4      8      16      32      64      128
(32/off)              1%    10%     26%     69%    105%    122%    114%
(64/off)             -1%     8%     27%     75%    111%    120%    131%

select_random_points.lua --random-points=50

На perro с --random-points=100

В относительных числах:

Threads	               1      4      8      16      32      64      128
(32/off)            -0.2%    1%     22%	    73%    114%    114%    126%
(64/off)            -0.1%    4%     22%     75%    112%    125%    135%

select_random_points.lua --random-points=100

Подробные числа всех запусков на perro

Вы можете найти абсолютные и относительные числа в нашей электронной таблице OpenOffice.org здесь: SysBench v0.5 select_random_points на perro

Используемая таблица и запрос

Определение таблицы:

CREATE TABLE sbtest (
  id  int unsigned NOT NULL AUTO_INCREMENT,
  k   int unsigned NOT NULL DEFAULT '0',
  c   char(120) NOT NULL DEFAULT '',
  pad char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (id),
  KEY k (k)
) ENGINE=MyISAM 

Используемый запрос:

SELECT id, k, c, pad
    FROM sbtest
    WHERE k IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

Параметры ? были заменены случайными числами при запуске теста SysBench. Мы использовали 10, 50 и 100 случайных точек в наших тестах.

Мы вставили 20 миллионов строк с помощью случайных данных, что дало нам размер файла данных и индекса:

3.6G    sbtest.MYD
313M    sbtest.MYI

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

Среда тестирования

Источники MariaDB

Мы использовали MariaDB 5.2.2-gamma с следующей версией из нашего репозитория Launchpad Ревизия #2878

revno: 2878
committer: Sergei Golubchik <sergii@pisem.net>
branch nick: 5.2
timestamp: Tue 2010-10-26 07:37:44 +0200
message:
  fixes for windows

Компиляция MariaDB

Мы скомпилировали MariaDB с помощью этой команды:

BUILD/compile-amd64-max

Параметры MariaDB во время выполнения

Мы использовали следующую конфигурацию для запуска MariaDB

MYSQLD_OPTIONS="--no-defaults \
  --datadir=$DATA_DIR \
  --language=./sql/share/english \
  --log-error \
  --key_buffer_size=512M \
  --max_connections=256 \
  --query_cache_size=0 \
  --query_cache_type=0 \
  --skip-grant-tables \
  --socket=$MY_SOCKET \
  --table_open_cache=512 \
  --thread_cache=512 \
  --key_cache_segments=0 \ # 0 | 32 | 64
  --tmpdir=$TEMP_DIR"

Параметры SysBench v0.5 select_random_points.lua

Мы запустили тест SysBench v0.5 select_random_points.lua со следующими параметрами:

# 20 million rows.
TABLE_SIZE=20000000

SYSBENCH_OPTIONS="--oltp-table-size=$TABLE_SIZE \
  --max-requests=0 \
  --mysql-table-engine=MyISAM \
  --mysql-user=root \
  --mysql-engine-trx=no \
  --myisam-max-rows=50000000 \
  --rand-seed=303"

Мы тестировали с возрастающим количеством одновременных пользователей со временем разогрева 8 минут и временем выполнения 20 минут:

NUM_THREADS="1 4 8 16 32 64 128"
...
  --num-threads=$THREADS

Мы также тестировали возрастающее количество случайных точек:

# Default option is --random-points=10.
SYSBENCH_TESTS[0]="select_random_points.lua"
SYSBENCH_TESTS[1]="select_random_points.lua --random-points=50"
SYSBENCH_TESTS[2]="select_random_points.lua --random-points=100"

Параметры ядра

IO планировщик

Для оптимальной производительности ввода-вывода при работе с базой данных мы используем планировщик noop. Вы можете проверить настройки планировщика с помощью:

cat /sys/block/${DEVICE}/queue/scheduler

Например, вывод должен выглядеть так:

cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

Подробные заметки о планировщиках Linux можно найти здесь: Планировщики Linux в бенчмарке TPCC.

Пределы открытых файлов

Большое количество одновременных подключений может привести к превышению предела открытых файлов на вашей системе. На большинстве систем Linux предел открытых файлов составляет 1024, чего может быть недостаточно. Установите предел открытых файлов выше, отредактировав

$EDITOR /etc/security/limits.conf

и добавив строку, например

#ftp             hard    nproc           0
#@student        -       maxlogins       4
*                -       nofile          16384

# End of file

Ваш ulimit -a вывод после этого должен выглядеть так:

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15975
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) 1744200
open files                      (-n) 16384

Используемые машины для тестирования

perro

# OS: openSUSE 11.1 (x86_64)
# Platform: x86_64
# CPU: Quad-core Intel @ 3.20GHz: 4 CPUs
# RAM: 2GB
# Disk(s): 2 x ST31000528AS S-ATA as software RAID 0

pitbull

# OS: Ubuntu 10.10
# Platform: x86_64
# CPU: Two-socket x hexa-core Intel Xeon X5660 @ 2.80GHz. With hyperthreading: 24CPUs
# RAM: 28GB
# Disk(s): 1 x ST3500320NS S-ATA