PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Come eseguire il benchmark delle prestazioni di PostgreSQL utilizzando Sysbench

Il benchmarking è un modo per scoprire le prestazioni della tua infrastruttura. Sysbench è un ottimo strumento per confrontare i server PostgreSQL. In questo post del blog, ti mostreremo come generare carichi di prova usando sysbench. Utilizzeremo una configurazione di replica di streaming master-slave a due nodi da ClusterControl. Questo ci aiuterà anche a generare alcune attività sul cluster e a verificare che la replica funzioni come previsto.

Installeremo l'ultima versione di sysbench, attualmente mantenuta qui. Utilizzeremo il pacchetto più aggiornato fornito nella pagina ufficiale di Github per installare sysbench. Utilizzeremo anche i binari standard di PostgreSQL 9.6 dalla pagina di download di PostgreSQL. Tieni presente che il percorso utilizzato in questo post del blog potrebbe essere diverso a seconda della versione di PostgreSQL e del fornitore che hai installato.

Come nota a margine, abbiamo trattato un post sul blog simile sull'analisi comparativa di PostgreSQL utilizzando pgbench in questo post del blog, Come confrontare le prestazioni di PostgreSQL.

Installazione di Sysbench

Installare sysbench è facile. Per Debian/Ubuntu:

$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
$ sudo apt -y install sysbench

E per RHEL/CentOS:

$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
$ sudo yum -y install sysbench

Installa il pacchetto sysbench:

$ yum install sysbench

Verifica la versione:

$ sysbench --version
sysbench 1.0.15

Ora abbiamo installato sysbench.

Inizializzazione dei dati di test

Se hai familiarità con sysbench, utilizza le seguenti impostazioni predefinite per i parametri PostgreSQL:

  • pgsql-host=host locale
  • porta-pgsql=5432
  • pgsql-user=sbtest
  • pgsql-password=password
  • pgsql-db=sbtest

Innanzitutto, crea il database e l'utente all'interno di PostgreSQL:

$ su - postgres
$ psql
> CREATE USER sbtest WITH PASSWORD 'password';
> CREATE DATABASE sbtest;
> GRANT ALL PRIVILEGES ON DATABASE sbtest TO sbtest;

Quindi modifica il file di accesso basato sull'host, pg_hba.conf :

$ vim /var/lib/pgsql/9.6/data/pg_hba.conf

E aggiungi la seguente riga per consentire le connessioni per l'utente sbtest, al database sbtest da tutti gli host sotto la rete 192.168.55.0:

host    sbtest          sbtest          192.168.55.0/24         md5

Ricarica il server per applicare le modifiche:

$ /usr/pgsql-9.6/bin/pg_ctl --reload

Verifica dal client della riga di comando psql se l'autenticazione dell'utente funziona correttamente:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -d sbtest -W

Dovresti essere in grado di accedere al server sotto il database sbtest:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -W
Password for user sbtest:
Type "help" for help.

sbtest=>

Esegui "\q" per uscire dal terminale. Ora possiamo inizializzare il database usando sysbench con il seguente comando:

$ sysbench \
--db-driver=pgsql \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=1 \
--pgsql-host=192.168.55.61 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua \
run

Il comando precedente genera 100.000 righe per tabella per 24 tabelle (da sbtest1 a sbtest24) all'interno del database 'sbtest'. Il nome dello schema è "pubblico", che è l'impostazione predefinita. I dati vengono preparati da uno script chiamato parallel_prepare.lua disponibile in /usr/share/sysbench/tests/include/oltp_legacy.

Verifica le tabelle generate con il seguente comando:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -W -c '\dt+\'
Password for user sbtest:
                    List of relations
 Schema |   Name   | Type  | Owner  | Size  | Description
--------+----------+-------+--------+-------+-------------
 public | sbtest1  | table | sbtest | 21 MB |
 public | sbtest10 | table | sbtest | 21 MB |
 public | sbtest11 | table | sbtest | 21 MB |
 public | sbtest12 | table | sbtest | 21 MB |
 public | sbtest13 | table | sbtest | 21 MB |
 public | sbtest14 | table | sbtest | 21 MB |
 public | sbtest15 | table | sbtest | 21 MB |
 public | sbtest16 | table | sbtest | 21 MB |
 public | sbtest17 | table | sbtest | 21 MB |
 public | sbtest18 | table | sbtest | 21 MB |
 public | sbtest19 | table | sbtest | 21 MB |
 public | sbtest2  | table | sbtest | 21 MB |
 public | sbtest20 | table | sbtest | 21 MB |
 public | sbtest21 | table | sbtest | 21 MB |
 public | sbtest22 | table | sbtest | 21 MB |
 public | sbtest23 | table | sbtest | 21 MB |
 public | sbtest24 | table | sbtest | 21 MB |
 public | sbtest3  | table | sbtest | 21 MB |
 public | sbtest4  | table | sbtest | 21 MB |
 public | sbtest5  | table | sbtest | 21 MB |
 public | sbtest6  | table | sbtest | 21 MB |
 public | sbtest7  | table | sbtest | 21 MB |
 public | sbtest8  | table | sbtest | 21 MB |
 public | sbtest9  | table | sbtest | 21 MB |
(24 rows)

I dati del test sono ora caricati.

Scarica il whitepaper oggi Gestione e automazione di PostgreSQL con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare PostgreSQLScarica il whitepaper

Genera carichi di prova

Esistono diversi tipi di carico di lavoro del database che puoi eseguire con sysbench, come mostrato nelle sezioni seguenti.

Carico di lettura/scrittura

Il comando è simile alla versione di MySQL di sysbench. È possibile utilizzare parametri simili ad eccezione dei parametri relativi a PostgreSQL:

$ sysbench \
--db-driver=pgsql \
--report-interval=2 \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=64 \
--time=60 \
--pgsql-host=192.168.55.61 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
run

Il comando precedente genererà il carico di lavoro OLTP dallo script LUA chiamato /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua, contro 100.000 righe di 24 tabelle con 64 thread di lavoro per 60 secondi sull'host 192.168.55.61 (master ). Ogni 2 secondi, sysbench riporterà le statistiche intermedie (--report-interval=2 ).

Una volta eseguito, otterresti qualcosa come di seguito:

sysbench 1.0.15 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 16
Report intermediate results every 2 second(s)
Initializing random number generator from current time

Initializing worker threads...

Threads started!

[ 2s ] thds: 64 tps: 0.00 qps: 466.69 (r/w/o: 406.55/28.33/31.81) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 4s ] thds: 64 tps: 30.55 qps: 525.38 (r/w/o: 335.56/128.72/61.10) lat (ms,95%): 3639.94 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 64 tps: 39.55 qps: 718.41 (r/w/o: 496.13/142.68/79.60) lat (ms,95%): 4128.91 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 64 tps: 35.98 qps: 840.95 (r/w/o: 604.11/163.89/72.95) lat (ms,95%): 2198.52 err/s: 0.50 reconn/s: 0.00
[ 10s ] thds: 64 tps: 65.57 qps: 1314.94 (r/w/o: 912.00/271.80/131.14) lat (ms,95%): 3040.14 err/s: 0.00 reconn/s: 0.00
...

Quando il test era in corso, possiamo monitorare l'attività di PostgreSQL usando pg_activity o pg_top , per confermare la statistica intermedia riportata da sysbench. In un altro terminale, fai:

$ su - postgres
$ pg_activity
 PostgreSQL 9.6.9 - postgres1.local - [email protected]:5432/postgres - Ref.: 2s
  Size:  654.62M -     7.67K/s        | TPS:          74
  Mem.:   39.10% -   382.72M/979.68M  | IO Max:     3395/s
  Swap:    0.20% -     3.57M/2.00G    | Read :      8.36M/s -   2141/s
  Load:    20.20 6.02 2.44            | Write:      2.54M/s -    650/s
                                                                   RUNNING QUERIES
PID    DATABASE              USER           CLIENT   CPU% MEM%   READ/s  WRITE/s     TIME+  W  IOW              state   Query
5130   sbtest              sbtest    192.168.55.61    1.0  2.8  791.57K    3.84K  0.788732  N    N             active   SELECT c FROM sbtest7 WHERE id BETWEEN 33195
 AND 33294
...

Oltre al flusso di replica, esaminando pg_stat_replication tabella sul server principale:

$ su - postgres
$ watch -n1 'psql -xc "select * from pg_stat_replication"'
Every 1.0s: psql -xc "select * from pg_stat_replication"      Tue Jul 31 13:12:08 2018
-[ RECORD 1 ]----+------------------------------
pid              | 3792
usesysid         | 16448
usename          | slave
application_name | walreceiver
client_addr      | 192.168.55.62
client_hostname  |
client_port      | 44654
backend_start    | 2018-07-30 13:41:41.707514+08
backend_xmin     |
state            | streaming
sent_location    | 0/60933D78
write_location   | 0/60933D78
flush_location   | 0/60933D78
replay_location  | 0/60933D78
sync_priority    | 0
sync_state       | async

Il comando "watch" sopra esegue il comando psql ogni 1 secondo. Dovresti vedere che le colonne "*_location" vengono aggiornate di conseguenza quando si verifica la replica.

Alla fine del test, dovresti vedere il riepilogo:

SQL statistics:
    queries performed:
        read:                            67704
        write:                           19322
        other:                           9682
        total:                           96708
    transactions:                        4830   (79.34 per sec.)
    queries:                             96708  (1588.53 per sec.)
    ignored errors:                      6      (0.10 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          60.8723s
    total number of events:              4830

Latency (ms):
         min:                                    4.52
         avg:                                  799.70
         max:                                 8082.70
         95th percentile:                     2279.14
         sum:                              3862532.62

Threads fairness:
    events (avg/stddev):           75.4688/7.39
    execution time (avg/stddev):   60.3521/0.20

Il riepilogo sopra ci dice che il nostro server di database PostgreSQL può gestire in media circa 80 transazioni al secondo e circa 1588 query al secondo con meno di 64 thread di lavoro.

Carico di sola lettura

Per il test di sola lettura, puoi usare lo stesso comando, ma cambiare lo script LUA in select.lua , select_random_points.lua , select_random_ranges.lua o oltp_simple.lua :

$ sysbench \
--db-driver=pgsql \
--report-interval=2 \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=64 \
--time=60 \
--pgsql-host=192.168.55.62 \
--pgsql-port=5432 \
--pgsql-user=sbtest \
--pgsql-password=password \
--pgsql-db=sbtest \
/usr/share/sysbench/tests/include/oltp_legacy/select.lua \
run

Il comando precedente esegue un carico di lavoro di sola lettura chiamato select.lua contro un server slave PostgreSQL (replica in streaming), 192.168.55.62 con 64 thread di lavoro.

Altri carichi

Esistono molti altri carichi di lavoro OLTP che puoi generare con sysbench, elencati in questa directory, /usr/share/sysbench/tests/include/oltp_legacy :

$ ls -1 /usr/share/sysbench/tests/include/oltp_legacy/
bulk_insert.lua
common.lua
delete.lua
insert.lua
oltp.lua
oltp_simple.lua
parallel_prepare.lua
select.lua
select_random_points.lua
select_random_ranges.lua
update_index.lua
update_non_index.lua

Puoi usare il comando simile e cambiare il percorso dello script LUA per caricarlo.

Pensieri finali

Usando sysbench, possiamo generare carichi di prova per il nostro server PostgreSQL (oltre che per MySQL). Nota che il miglior benchmark sarebbe con i tuoi dati e applicazioni reali, ma potrebbe non essere sempre possibile. Potrebbe anche essere una nuova applicazione che si evolverà rapidamente. Nonostante il carico generato da sysbench potrebbe non rappresentare il carico di lavoro OLTP del mondo reale, potrebbe essere abbastanza buono.