This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-15. For the latest, interactive version please visit https://mariadb.com/kb/.

Le prestazioni della cache delle chiavi segmentata

Metodo di test delle prestazioni della segmentazione della cache degli indici

Abbiamo usato SysBench v0.5 da Launchpad per testare la segmentazione della cache degli indici dello Storage Engine MyISAM di MariaDB 5.2.2-gamma.

Come script wrapper per l'esecuzione automatica di SysBench abbiamo usato la directory sysbench/ da MariaDB Tools.

Per testare che la divisione del mutex globale della cache delle chiavi in diversi mutex sia utile in un carico di lavoro con molti utenti, abbiamo scritto un nuovo test SysBench chiamato select_random_points.lua. Abbiamo usato una grande tabella e selezionato punti casuali con un numero di utenti concorrenti che aumentava man mano.

Principali risultati del test

Abbiamo rilevato un aumento delle performance fino al 250%, a seconda del numero di utenti.

Risultati dettagliati del test

Sulla macchina pitbull

Su pitbull con --random-points=10

pitbull_rp10

In numeri relativi:

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

Su pitbull con --random-points=50

pitbull_rp50

In numeri relativi:

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

Su pitbull con --random-points=100

pitbull_rp100

In numeri relativi:

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

Numeri dettagliati di tutte le esecuzioni su pitbull

Tutti i numeri relativi e assoluti si trovano in un foglio di calcolo OpenOffice.org qui: SysBench v0.5 select_random_points on pitbull

Sulla macchina perro

Su perro con --random-points=10

perro_rp10

In numeri relativi:

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

Su perro con --random-points=50

perro_rp50

In numeri relativi:

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

Su perro con --random-points=100

perro_rp100

In numeri relativi:

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

Numeri dettagliati di tutte le esecuzioni su perro

Tutti i numeri relativi e assoluti si trovano in un foglio di calcolo OpenOffice.org qui: SysBench v0.5 select_random_points on perro

Tabella e query utilizzate

Definizione della tabella:

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 

Query utilizzata:

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

I parametri ? sono stati rimpiazzati con numeri casuali durante l'esecuzione di SysBench. Nei test sono stati utilizzati 10, 50 e 100 punti casuali.

Sono stati inseriti 20 milioni di righe utilizzando dati casuali, e questo porta a un file dei dati e uno degli indici di:

3.6G    sbtest.MYD
313M    sbtest.MYI

Le dimensioni del buffer degli indici erano sufficienti per contenere il file degli indici.

Ambiente di test

Sorgenti MariaDB

E' stata utilizzata MariaDB 5.2.2-gamma con la seguente revisione dal repository Revision #2878 su Launchpad:

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

Compilare MariaDB

MariaDB è stata compilata con questa istruzione:

BUILD/compile-amd64-max

Opzioni di runtime di MariaDB

La configurazione di MariaDB era la seguente:

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"

Opzioni di select_random_points.lua con SysBench v0.5

Il test select_random_points.lua è stato eseguito con SysBench v0.5 con le seguenti opzioni:

# 20 milioni di righe.
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"

E' stato testato con un numero di utenti in aumento, con un tempo di riscaldamento di 8 minuti e un tempo di esecuzione di 20 minuti:

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

Inoltre anche il numero di punti casuali era in aumento:

# 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"

Parametri del Kernel

IO scheduler

Per ottenere le migliori performance dall'IO del database abbiamo utilizzato lo scheduler noop. E' possibile conoscere le sue impostazioni con:

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

L'output dovrebbe assomigliare al seguente:

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

Note dettagliate sugli scheduler di Linux sono qui: Linux schedulers in TPCC like benchmark.

Massimo di file aperti

Avendo molte connessioni aperte si può raggiungere il massimo di file aperti consentiti dal sistema operativo. Sulla maggioranza dei sistemi Linux questo limite è di 1024, che potrebbe non essere sufficiente. Si aumenti questo limite modificando:

$EDITOR /etc/security/limits.conf

e aggiungendovi una riga:

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

# End of file

L'output di ulimit -a dovrebbe assomigliare al seguente:

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

Macchine utilizzate nel testing

perro

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

pitbull

# OS: Ubuntu 10.10
# Piattaforma: x86_64
# CPU: Two-socket x hexa-core Intel Xeon X5660 @ 2.80GHz. Con hyperthreading: 24CPUs
# RAM: 28GB
# Dischi: 1 x ST3500320NS S-ATA
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.