Mysql

Programmez : Mysql-proxy

Posted on

Et voilà, une parution concernant l’outil Mysql-proxy dans le magazine Programmez !!
Bonne lecture. -> ICI

 

Advertisements

Mysql Cluster 7.1.8

Posted on

La version 7.1.8 de Mysql Cluster est sortie !!!

TPCC sous Mysql

Posted on

Voici un how-to sur comment faire des benchmark TPC-C ( Transaction Processing Performance Council- Benchmark C) et avoir un référentiel standard pour vos moteur.
L’outil utilisé sera celui de Percona. En l’occurence tpcc-mysql.

1/ Installer les outils
# yum install bzr
$ bzr branch lp:~percona-dev/perconatools/tpcc-mysql
$ cd tpcc-mysql/src
$ make all

Cela créera 2 outils tpcc_load et tpcc_start.

2 / Création de la table
Importez les données .sql afin d’avoir la structure nécessaire au benchmark.

mysql> grant all privileges on tpcc.* to tpcc@’%’ identified by ‘test’;
mysql> create database tpcc;

$ mysql -u tpcc -p -h localhost tpcc < create_table.sql
$ mysql -u tpcc -p -h localhost tpcc < add_fkey_idx.sql

3 / TPCC LOAD

Lancer le script et renseignant les paramètres adéquats
$ ./tpcc_load
*************************************
*** ###easy### TPC-C Data Loader ***
*************************************

usage: tpcc_load [server] [DB] [user] [pass] [warehouse]
OR
tpcc_load [server] [DB] [user] [pass] [warehouse] [part] [min_wh] [max_wh]

* [part]: 1=ITEMS 2=WAREHOUSE 3=CUSTOMER 4=ORDERS

$ ./tpcc_load localhost tpcc tpcc test 1
*************************************
*** ###easy### TPC-C Data Loader ***
*************************************
<Parameters>
[server]: localhost
[DBname]: tpcc
[user]: tpcc
[pass]: test
[warehouse]: 1
TPCC Data Load Started…
Loading Item
………………………………………….. 5000
Loading Orders for D=10, W= 1
………. 1000
………. 2000
………. 3000
Orders Done.

…DATA LOADING COMPLETED SUCCESSFULLY.

4 / TPCC START

Une fois les données charger il est tant de tester en lancer le script ./tpcc_start.
Lançons un test qui dure 180 secondes qui affiche un résultat tout les 60 secondes avec 4 connections et 1 datawarehouse.
./tpcc_start localhost tpcc tpcc test 1 4 60 180

***************************************
*** ###easy### TPC-C Load Generator ***
***************************************
<Parameters>
[server]: localhost
[DBname]: tpcc
[user]: tpcc
[pass]: test
[warehouse]: 1
[connection]: 4
[rampup]: 60 (sec.)
[measure]: 180 (sec.)

RAMP-UP TIME.(60 sec.)

MEASURING START.

10, 61(0):0.8, 58(0):0.4, 5(0):1.0, 6(0):1.2, 5(0):3.8
20, 66(0):0.8, 70(0):0.4, 7(0):1.0, 7(0):1.2, 7(0):2.0

<RT Histogram>

1.New-Order

0.20, 536
0.40, 484
0.60, 166
0.80, 113
1.00, 66

<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.54% (>=43.0%) [OK]
Order-Status: 4.33% (>= 4.0%) [OK]
Delivery: 4.33% (>= 4.0%) [OK]
Stock-Level: 4.37% (>= 4.0%) [OK]

<TpmC>
371.000 TpmC

Les résultats à prendre en compte sont les ” MEASURING STATS” qui une fois mis au format excel vous permettent
d’afficher les courbes de performances de votre machine.
Une petite explication sur les STATS:
A, B(C):D, E(F):G, H(I):J, K(L):M, N(O):P
A = Temps écoulé en second
B = Nouvel ordre éffectué
C = Nouvel ordre éffectué avec retard
D = 90ème percentile pour les Nouveux Ordres ( en sec)
etc…
Ainsi que le TpmC (Transation per minute) vous donne un chiffre global en vues de comparaison

Mysql-Proxy : RW-SPLITTING et REWRITING

Posted on

La méthode consiste à ré-écrire les requêtes CREATE TEMPORARY TABLE, car non supportés en tant que CREATE TABLE. Notons qu’il vous faudra gérer les suppréssions de table. Voyons comment l’intégrer dans le script rw-splitting.lua:

Dans la fonction read_query(packet), commenté ces lignes dans le bloc if is_debug:
–if cmd.type == proxy.COM_QUERY then
        —    print(”  query            = ”        .. cmd.query)

puis ajouter après le bloc if is_debug:
 if string.byte(packet) == proxy.COM_QUERY then
          local query = string.sub(packet, 2)
         print(“marequete: “..query)
        
          local replacing = false
        
          if string.match(string.upper(query), ‘^%s*CREATE TEMPORARY TABLE’)then
              query = string.gsub(query,’^%s*%w+%s*%w+%s*%w+’,’CREATE TABLE’)
             replacing = true
           end
         if (replacing) then
              print(“replaced with ” .. query )
              proxy.queries:append(1, string.char(proxy.COM_QUERY) .. query, { resultset_is_needed = true } )
              return proxy.PROXY_SEND_QUERY
         end

 
Et commentez cette ligne:
–proxy.queries:append(1, packet, { resultset_is_needed = true })

Et voilà .

Mysql-Proxy RW-SPLITTING et BLOCKING QUERIES

Posted on

Etant assez jeune mysql-proxy pose quelque petits problèmes dans une architecture RW/SPLITTING tel que :

  • SET NAMES utf8
  • CREATE TEMPORARY TABLE …
  • SET @a = 1; SELECT @a;
  • Stored Procedures
  • SHOW SESSION STATUS

Pour contrer le problème du jeton CREATE TEMPORARY TABLE, qui provoque certaines erreur, l’astuce consistera à parser les commandes Temporary en les interdisant dans notre script.  Maintenant voyons comment intégrer notre code dans le fichier “rw-splitting.lua”.

Définissons dans un premier temps ce que nous voulons bloquer :

–config block à déclarer après les variables local

function make_regexp_from_command(cmd)
    local regexp= ‘^%s*’;
    for ch in cmd:gmatch(‘(.)’) do
        regexp = regexp .. ‘[‘ .. ch:upper() .. ch:lower() .. ‘]’
    end
    return regexp
end

local CREATE_REGEXP       = make_regexp_from_command(‘create’)

queries_to_filter = {
    {
        prefix = CREATE_REGEXP,
        keywords = { ‘CREATE’,’TEMPORARY’,’TABLE’} ,
    }
}
function error_result (msg)
    proxy.response = {
        type        = proxy.MYSQLD_PACKET_ERR,
        errmsg      = msg,
        errcode     = 7777,
        sqlstate    = ‘X7777’,
    }
    return proxy.PROXY_SEND_RESULT
end
–config block

Puis dans la fonction ” function read_query( packet )”  après le ” if is_debug then end ” ajouter ceci :

–config block
local query = packet:sub(2)
    for i,query_to_filter in pairs(queries_to_filter)
    do
        if query:match(query_to_filter.prefix) then
            local full_tokens = tokenizer.tokenize(query)
            local tokens = tokenizer.bare_tokens(full_tokens, true)
            local found = 0
            local requested = #query_to_filter.keywords
            for j,keyword in pairs(query_to_filter.keywords) do
                for k, token in pairs(tokens) do
                    if token:upper() == keyword then
                        found = found + 1
                        break
                    end
                end
            end
            if found == requested then — to be filtered off
                return error_result(‘command <‘ ..
                    table.concat(query_to_filter.keywords,’ ‘) ..
                    ‘> is  not allowed’ )          
            end
        end
    end

–config block

Et voila maintenant quand vous exécuterez vos requêtes un message sera afficher interdisant les requêtes CREATE TEMPORARY TABLE.

Toku DB Benchmark

Posted on

TokuDB arrivent en force avec une nouvelle version ( 4.4.1) fournissant un MySQL 5.1.46 et 5.5.4 m3
nouvelles fonctionnalités :

– Création de tables 4 x plus rapides
– Multi-thread
– suppor SAVEPOINT 
– Indexation 20x plus rapide, Compréssion des données 5x

Petit récapitulatif des tests pour vérifier les dires:

LOAD :

Fichier Source.sql = 22 GO
Remontée des données avec la commande ” time mysql  test < Source.sql”
Cela nous donne 91 minutes .
Pourquoi ? Car il compresse en temps réel les données ce qui fait que nous passons de 22 Go de données à 7 GO en production.

SYSBENCH :

 Time:180 
 Type :Read Only 
 Cpu:10 

Threads Transaction per seconds Requêtes /sec
4 549 24737
8 525 11813
16 518 5838
32 511 2877
64 503 1416

Pas de très grosse performance en Read-only.

TPCC:

test : ./tpcc_start localhost tpcc root “” 100 16 10 3600

 TOKUDB.cnf :
 

max_connections=3000
innodb_data_home_dir = /usr/local/mysql/data
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /usr/local/mysql/data
innodb_buffer_pool_size = 15G
innodb_additional_mem_pool_size = 32M
innodb_log_file_size = 768M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_max_dirty_pages_pct = 90
innodb_flush_method= O_DIRECT
skip-name-resolve
table_cache=10000
innodb_file_per_table
sync_binlog=0
transaction-isolation=REPEATABLE-READ

 Résultat très surprenant, car TOKUDB utilise bien les 10 CPU avec une charge de 80 % pour chacun.Néanmoins les chutes de performances sont dû à une variable inéxistante innodb_io_capacity, qui nécessite de patché pour l’avoir.
TokuDB fonctionne comme INNODB en créant son tablespace. Mais le résultat de d’une remonté de données est moins rapide que si nous étions en MYISAM.

TPCC MySQL 5.5 VS Xtradb

Posted on

La version MySQL 5.6 arrivant pour bien en tant que Release Candidate, j’ai testé la version MySQL 5.5 contre Xtradb sur le plan des TPCC. Et Il semblerait que Mysql nous offre un produit vraiment à la hauteur des espérances en termes de performances.

Configuration de la machine:

  • CPU(s) 12 x Six-Core AMD Opteron(tm) Processor 2423 HE
  • 24 GB RAM
  • 4 x SSD INTEL-RAID 0
test : tpcc_start localhost tpcc root “” 100 16 10 3600
MySQL5.cnf :
innodb_buffer_pool_size=17G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_file_per_table=ON
innodb_additional_mem_pool-size=32M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=8M
innodb_max_dirty_pages_pct=90
innodb_log_files_in_group=2
innodb_log_file_size=1024M
innodb_lock_wait_timeout=50
innodb_thread_concurrency=0
innodb_flush_method = O_DIRECT
innodb_write_io_threads=8
innodb_read_io_threads=8
innodb_io_capacity=2000
innodb_purge_thread=1
max_connections=3500
query_cache_size=0
sync_binlog=0
skip-name-resolvetable_cache=10000
XTRADB.cnf :  
transaction-isolation=REPEATABLE-READ
innodb_buffer_pool_size=15G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_file_per_table=1
innodb_additional_mem_pool-size=32M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=8M
innodb_log_files_in_group=2
innodb_log_file_size=1024M
innodb_fast_checksum=1
innodb_lock_wait_timeout=50
innodb_thread_concurrency=0
innodb_flush_method             = O_DIRECT
innodb_write_io_threads=8
innodb_read_io_threads=8
innodb_io_capacity=2000
innodb_ibuf_accel_rate=20000
innodb_max_dirty_pages_pct=90
max_connections=3500
query_cache_size=0
skip-name-resolve
table_cache=10000
sync_binlog=0

Résultats assez intéressant l’INNODB de MySQL 5.5 est vraiment
plus performant et il semblerait que Percona ait du souci à ce faire sur ce point de vue.