Aceasta este comanda pgbench care poate fi rulată în furnizorul de găzduire gratuit OnWorks folosind una dintre multiplele noastre stații de lucru online gratuite, cum ar fi Ubuntu Online, Fedora Online, emulator online Windows sau emulator online MAC OS
PROGRAM:
NUME
pgbench - rulați un test de referință pe PostgreSQL
REZUMAT
pgbench -i [opțiune...] [dbname]
pgbench [opțiune...] [dbname]
DESCRIERE
pgbench este un program simplu pentru rularea testelor benchmark pe PostgreSQL. Merge la fel
secvență de comenzi SQL din nou și din nou, posibil în mai multe sesiuni de baze de date concurente,
și apoi calculează rata medie a tranzacțiilor (tranzacții pe secundă). În mod implicit,
pgbench testează un scenariu care se bazează vag pe TPC-B, implicând cinci SELECT, UPDATE,
si INSERT comenzi pe tranzacție. Cu toate acestea, este ușor să testați alte cazuri prin scriere
propriile fișiere de script de tranzacție.
Ieșirea tipică de la pgbench arată astfel:
tip tranzacție: TPC-B (un fel de)
factor de scalare: 10
modul de interogare: simplu
Numar de clienti: 10
numărul de fire: 1
numărul de tranzacții per client: 1000
numărul de tranzacții efectiv procesate: 10000/10000
tps = 85.184871 (inclusiv stabilirea conexiunilor)
tps = 85.296346 (excluzând stabilirea conexiunilor)
Primele șase linii raportează unele dintre cele mai importante setări ale parametrilor. Următoarea linie
raportează numărul de tranzacții finalizate și intenționate (acestea din urmă fiind doar
produsul numărului de clienți și numărului de tranzacții per client); acestea vor fi egale
cu excepția cazului în care rularea a eșuat înainte de finalizare. (În -T modul, doar numărul real de
tranzacțiile este tipărită.) Ultimele două rânduri raportează numărul de tranzacții pe secundă,
calculat cu și fără a număra timpul pentru a începe sesiunile de baze de date.
Testul implicit de tranzacție de tip TPC-B necesită configurarea în prealabil a unor tabele specifice.
pgbench ar trebui să fie invocat cu -i (inițializare) opțiune pentru a crea și a popula acestea
Mese. (Când testați un script personalizat, nu aveți nevoie de acest pas, ci în schimb o va face
trebuie să faceți orice configurație de care are nevoie testul dvs.) Inițializarea arată astfel:
pgbench -i [ alte optiuni ] dbname
Unde dbname este numele bazei de date deja create pentru a testa. (De asemenea, este posibil să aveți nevoie de
-h, -p, și / sau -U opțiuni pentru a specifica modul de conectare la serverul bazei de date.)
Prudență
pgbench -i creează patru tabele pgbench_accounts, pgbench_branches, pgbench_history,
și pgbench_tellers, distrugând toate tabelele existente cu aceste nume. Fii foarte atent la
utilizați o altă bază de date dacă aveți tabele care au aceste nume!
La „factorul de scară” implicit de 1, tabelele conțin inițial atât de multe rânduri:
tabelul # de rânduri
---------------------------------
pgbench_branches 1
pgbench_tellers 10
pgbench_accounts 100000
pgbench_history 0
Puteți (și, în majoritatea scopurilor, probabil ar trebui) să creșteți numărul de rânduri utilizând
-s opțiunea (factor de scară). The -F Opțiunea (factor de umplere) ar putea fi, de asemenea, utilizată în acest moment.
După ce ați făcut configurarea necesară, puteți rula benchmark-ul cu o comandă care
nu include -i, acesta este
pgbench [ Opțiuni ] dbname
În aproape toate cazurile, veți avea nevoie de câteva opțiuni pentru a face un test util. Cel mai important
opțiunile sunt -c (numar de clienti), -t (numar de tranzactii), -T (limită de timp) și -f
(specificați un fișier script personalizat). Vedeți mai jos pentru o listă completă.
OPŢIUNI
Următoarele sunt împărțite în trei subsecțiuni: Sunt utilizate diferite opțiuni în timpul
inițializarea bazei de date și în timpul executării benchmark-urilor, unele opțiuni sunt utile în ambele
cazuri.
Inițializarea Opţiuni
pgbench acceptă următoarele argumente de inițializare a liniei de comandă:
-i
--inițializați
Necesar pentru a invoca modul de inițializare.
-F factor de umplere
--fillfactor=factor de umplere
Creați tabelele pgbench_accounts, pgbench_tellers și pgbench_branches cu
dat factor de umplere. Implicit este 100.
-n
--fara-vacuum
Nu efectuați aspirarea după inițializare.
-q
--Liniște
Comutați înregistrarea în modul silențios, producând un singur mesaj de progres la 5 secunde. The
jurnalizarea implicită imprimă un mesaj la fiecare 100000 de rânduri, care deseori scoate multe linii
pe secundă (mai ales pe hardware bun).
-s factor_de_scalare
--scale=factor_de_scalare
Înmulțiți numărul de rânduri generate cu factorul de scară. De exemplu, -s 100 va
creați 10,000,000 de rânduri în tabelul pgbench_accounts. Implicit este 1. Când scala este
20,000 sau mai mare, coloanele utilizate pentru a păstra identificatorii de cont (coloanele de ajutor) vor
treceți la utilizarea numerelor întregi mai mari (bigint), pentru a fi suficient de mari pentru a menține intervalul
a identificatorilor de cont.
--chei-străine
Creați constrângeri de cheie străină între tabelele standard.
--index-tablespace=index_tablespace
Creați indecși în spațiul tabel specificat, mai degrabă decât în spațiul tabel implicit.
--tablespace=tablespace
Creați tabele în spațiul tabel specificat, mai degrabă decât în spațiul tabel implicit.
--unlogged-tables
Creați toate tabelele ca tabele neînregistrate, mai degrabă decât tabele permanente.
Benchmarking Opţiuni
pgbench acceptă următoarele argumente de evaluare comparativă a liniei de comandă:
-c clientii
--client=clientii
Numărul de clienți simulați, adică numărul de sesiuni concurente ale bazei de date. Mod implicit
este 1.
-C
--conectați
Stabiliți o nouă conexiune pentru fiecare tranzacție, în loc să o faceți o singură dată
sesiune client. Acest lucru este util pentru a măsura supraîncărcarea conexiunii.
-d
--depanare
Ieșire de depanare tipărită.
-D varname=valoare
--define=varname=valoare
Definiți o variabilă pentru utilizare de către un script personalizat (vezi mai jos). Multiplu -D opțiunile sunt
permis.
-f nume de fișier
--file=nume de fișier
Citiți scriptul tranzacției de la nume de fișier. Vezi mai jos pentru detalii. -N, -S și -f sunt
se exclud reciproc.
-j fire
--locuri de muncă=fire
Numărul de fire de lucru din pgbench. Utilizarea mai multor fire poate fi utilă
aparate cu mai multe CPU. Numărul de clienți trebuie să fie un multiplu al numărului de fire,
deoarece fiecărui thread i se oferă același număr de sesiuni client de gestionat. Implicit este 1.
-l
--Buturuga
Scrieți timpul necesar fiecărei tranzacții într-un fișier jurnal. Vezi mai jos pentru detalii.
-L limita
--latency-limit=limita
Tranzacție care durează mai mult de limita milisecundele sunt numărate și raportate
separat, ca târziu.
Când se utilizează throttling (--rata=...), tranzacții care rămân cu mai mult în urmă programului
decât limita ms, și, prin urmare, nu au nicio speranță de a atinge limita de latență, nu sunt trimise către
server la toate. Acestea sunt numărate și raportate separat ca fiind ignorate.
-M modul de interogare
--protocol=modul de interogare
Protocol de utilizat pentru trimiterea interogărilor către server:
· simplu: utilizați un protocol simplu de interogare.
· extins: utilizați protocolul de interogare extins.
· pregătit: utilizați protocolul de interogare extins cu instrucțiuni pregătite.
Implicit este protocolul de interogare simplu. (A se vedea capitolul 50, Protocolul Frontend/Backend, în
documentația pentru mai multe informații.)
-n
--fara-vacuum
Nu efectuați aspirarea înainte de a efectua testul. Această opțiune este necesar daca esti
rularea unui scenariu de testare personalizat care nu include tabelele standard
pgbench_accounts, pgbench_branches, pgbench_history și pgbench_tellers.
-N
--săriți unele actualizări
Nu actualizați pgbench_tellers și pgbench_branches. Acest lucru va evita disputa de actualizare
pe aceste tabele, dar face ca cazul de testare să fie și mai puțin ca TPC-B.
-P sec
--progres=sec
Afișați raportul de progres la fiecare secundă în secundă. Raportul include timpul de la
începutul rulării, tps-ul de la ultimul raport și latența tranzacției
medie și abatere standard de la ultimul raport. Sub accelerare (-R),
latența este calculată în funcție de ora de începere programată a tranzacției, nu de
ora reală de începere a tranzacției, deci include și decalajul mediu de planificare
timp.
-r
--raport-latente
Raportați latența medie per declarație (timpul de execuție din perspectiva
client) a fiecărei comenzi după terminarea benchmark-ului. Vezi mai jos pentru detalii.
-R rată
--rata=rată
Efectuați tranzacții care vizează rata specificată în loc să rulați la fel de repede ca
posibil (prestabilit). Rata este dată în tranzacții pe secundă. Dacă cel vizat
rata este peste rata maximă posibilă, limita ratei nu va afecta rezultatele.
Rata este vizată prin începerea tranzacțiilor de-a lungul unui program distribuit de Poisson
linie temporală. Orarul estimat de începere avansează în funcție de momentul în care clientul
a început prima dată, nu când s-a încheiat tranzacția anterioară. Această abordare înseamnă că atunci când
tranzacțiile depășesc ora de încheiere programată inițială, este posibil pentru cele ulterioare
pentru a ajunge din nou din urmă.
Când throttling-ul este activ, latența tranzacției raportată la sfârșitul rulării este
calculat din orele de începere programate, deci include ora fiecărei tranzacții
a trebuit să aștepte finalizarea tranzacției anterioare. Timpul de așteptare se numește
timpul de întârziere al programului, precum și media și maximul acestuia sunt, de asemenea, raportate separat. The
latența tranzacției în raport cu ora reală de începere a tranzacției, adică timpul
cheltuită executând tranzacția în baza de date, poate fi calculată scăzând valoarea
programați timpul de întârziere de la latența raportată.
If --limita-latentei se utilizează împreună cu --rată, o tranzacție poate rămâne în urmă atât de mult
că este deja peste limita de latență când tranzacția anterioară se încheie, deoarece
latența se calculează din ora de începere programată. Astfel de tranzacții nu sunt
trimise la server, dar sunt omise cu totul și sunt numărate separat.
Un timp mare de întârziere a programului este un indiciu că sistemul nu poate procesa tranzacțiile
la rata specificată, cu numărul de clienți și fire alese. Când media
timpul de execuție a tranzacției este mai lung decât intervalul programat dintre fiecare
tranzacție, fiecare tranzacție succesivă va rămâne mai în urmă, iar programul
timpul de întârziere va continua să crească cu cât durata testului este mai lungă. Când se va întâmpla asta, o vei face
trebuie să reducă rata de tranzacție specificată.
-s factor_de_scalare
--scale=factor_de_scalare
Raportați factorul de scară specificat în rezultatul pgbench. Cu testele încorporate, asta
nu este necesar; factorul de scară corect va fi detectat prin numărarea numărului de
rânduri din tabelul pgbench_branches. Cu toate acestea, atunci când se testează benchmark-uri personalizate (-f
opțiunea), factorul de scară va fi raportat ca 1 dacă nu se utilizează această opțiune.
-S
--select-only
Efectuați tranzacții doar selectate în loc de testul de tip TPC-B.
-t tranzacții
--tranzacții=tranzacții
Numărul de tranzacții efectuate de fiecare client. Implicit este 10.
-T secunde
--timp=secunde
Rulați testul pentru atâtea secunde, mai degrabă decât un număr fix de tranzacții pe
de client. -t si -T se exclud reciproc.
-v
--aspirați-toate
Aspirați toate cele patru mese standard înainte de a rula testul. Cu nici unul -n nici -v,
pgbench va aspira tabelele pgbench_tellers și pgbench_branches și va trunchia
pgbench_history.
--interval-agregat=secunde
Lungimea intervalului de agregare (în secunde). Poate fi folosit numai împreună cu -l - cu
această opțiune, jurnalul conține un rezumat pe interval (număr de tranzacții, min/max
latență și două câmpuri suplimentare utile pentru estimarea varianței).
Această opțiune nu este acceptată în prezent pe Windows.
--rata-de-esantionare=rată
Rata de eșantionare, utilizată la scrierea datelor în jurnal, pentru a reduce cantitatea de jurnal
generate. Dacă această opțiune este dată, doar fracțiunea specificată a tranzacțiilor sunt
logat. 1.0 înseamnă că toate tranzacțiile vor fi înregistrate, 0.05 înseamnă doar 5% din
tranzacțiile vor fi înregistrate.
Nu uitați să țineți cont de rata de eșantionare atunci când procesați fișierul jurnal. Pentru
de exemplu, atunci când calculați valorile tps, trebuie să înmulțiți numerele în consecință (de ex
cu o rată de eșantionare de 0.01, veți obține doar 1/100 din tps-ul real).
Comun Opţiuni
pgbench acceptă următoarele argumente comune de linie de comandă:
-h nume de gazdă
--gazdă=nume de gazdă
Numele de gazdă al serverului de bază de date
-p port
--port=port
Numărul portului serverului de bază de date
-U Logare
--nume utilizator=Logare
Numele de utilizator cu care se va conecta
-V
--versiune
Imprimați versiunea pgbench și ieșiți.
-?
--Ajutor
Afișați ajutor despre argumentele liniei de comandă pgbench și ieșiți.
NOTE
Ce is il "Tranzacţie" De fapt Efectuat in pgbench?
Scriptul de tranzacție implicit emite șapte comenzi per tranzacție:
1. ÎNCEPE;
2. UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
3. SELECTAȚI abalance FROM pgbench_accounts WHERE aid = :aid;
4. UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
5. UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
6. INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALORI (:tid, :bid, :aid,
:delta, CURRENT_TIMESTAMP);
7. SFÂRȘIT;
Dacă specificați -N, pașii 4 și 5 nu sunt incluși în tranzacție. Daca specificati -S,
numai SELECT este emis.
pachet personalizat Script-uri
pgbench are suport pentru rularea scenariilor de benchmark personalizate prin înlocuirea implicită
script de tranzacție (descris mai sus) cu un script de tranzacție citit dintr-un fișier (-f
opțiune). În acest caz, o „tranzacție” contează ca o execuție a unui fișier script. Puteți
chiar și specificați mai multe scripturi (mai multe -f opțiuni), caz în care una aleatorie dintre
scripts este ales de fiecare dată când o sesiune client începe o nouă tranzacție.
Formatul unui fișier script este o comandă SQL pe linie; comenzile SQL multilinie nu sunt
sprijinit. Liniile goale și liniile care încep cu -- sunt ignorate. Liniile de fișier script pot, de asemenea
fi „meta comenzi”, care sunt interpretate de pgbench însuși, așa cum este descris mai jos.
Există o facilitate simplă de înlocuire a variabilelor pentru fișierele script. Variabilele pot fi setate de
linia de comandă -D opțiunea, explicată mai sus, sau prin meta comenzile explicate mai jos. În
adăugare la orice variabile presetate de -D opțiuni de linie de comandă, există câteva variabile
care sunt presetate automat, listate în Tabelul 221, „Variabile automate”. O valoare
specificat pentru aceste variabile folosind -D are prioritate fata de presetarile automate. O singura data
setată, valoarea unei variabile poate fi inserată într-o comandă SQL scriind:nume variabilă. Când
rulând mai mult de o sesiune client, fiecare sesiune are propriul set de variabile.
Tabel 221. Automat variabile
┌──────────┬─────────────────────────────└──
│Variabil │ Descriere │
├──────────┼───────────────────────────────────
│scală │ factor de scară curent │
├──────────┼───────────────────────────────────
│client_id │ număr unic care identifică │
│ │ sesiune client (începe de la │
│ │ zero) │
└──────────┴─────────────────────────────────────
Meta-comenzile fișierului script încep cu o bară oblică inversă (\). Argumentele pentru o meta-comandă sunt
separate prin spații albe. Aceste meta-comenzi sunt acceptate:
\a stabilit varname expresie
Setează variabile varname la o valoare întreagă calculată din expresie. Expresia
poate conține constante întregi, cum ar fi 5432, referințe la variabile:nume variabilă și
expresii compuse din operatori unari (-) sau binari (+, -, *, /, %) cu obișnuiți
asociativitatea și parantezele.
Exemple:
\set ntellers 10 * :scale
\set aid (1021 * :aid) % (100000 * :scale) + 1
\setrandom varname minute max [ uniforma | { gaussian | exponențial } parametru ]
Setează variabile varname la o valoare întreagă aleatorie între limite minute si max
inclusiv. Fiecare limită poate fi fie o constantă întreagă, fie o:nume variabilă referință
la o variabilă având o valoare întreagă.
În mod implicit, sau când este specificat uniform, toate valorile din interval sunt desenate cu egal
probabilitate. Specificarea opțiunilor gaussiene sau exponențiale modifică acest comportament; fiecare
necesită un parametru obligatoriu care determină forma precisă a distribuției.
Pentru o distribuție Gaussiană, intervalul este mapat pe o normală standard
distribuția (curba Gaussiană clasică în formă de clopot) trunchiată la -parametru pe
stânga și +parametrul în dreapta. Valorile la mijlocul intervalului sunt mai probabile
a fi desenat. Pentru a fi precis, dacă PHI(x) este funcția de distribuție cumulativă a lui
distribuție normală standard, cu mu mediu definit ca (max + min) / 2.0, cu
f(x) = PHI(2.0 * parametru * (x - mu) / (max - min + 1)) /
(2.0 * PHI(parametru) - 1.0)
apoi valoarea i între minute si max inclusiv se trage cu probabilitate: f(i + 0.5) - f(i
- 0.5). Intuitiv, cu atât mai mare parametru, cu cât mai frecvent valorile apropiate de
mijlocul intervalului sunt trasate, iar valorile mai rar apropiate de minute si
max limite. Aproximativ 67% din valori sunt extrase din mijlocul 1.0 / parametru, adică a
relativ 0.5 / parametru în jurul mediei și 95% în mijloc 2.0 / parametru, care
este un parametru relativ de 1.0 / în jurul mediei; de exemplu, dacă parametru este 4.0, 67%
de valori sunt extrase din sfertul mijlociu (1.0 / 4.0) al intervalului (adică din 3.0
/ 8.0 la 5.0 / 8.0) și 95% din jumătatea mijlocie (2.0 / 4.0) a intervalului (a doua
și a treia quartile). Minimul parametru este 2.0 pentru performanța Box-Muller
transforma.
Pentru o distribuție exponențială, parametru controlează distribuția prin trunchierea a
distribuție exponențială în scădere rapidă la parametru, și apoi proiectând pe
numere întregi între limite. Mai exact, cu
f(x) = exp(-parametru * (x - min) / (max - min + 1)) / (1.0 - exp(-parametru))
Apoi valoare i între minute si max inclusiv se trage cu probabilitate: f(x) - f(x + 1).
Intuitiv, cu atât mai mare parametru, cu atât mai frecvent valorile apropiate de minute sunt
accesat, iar valorile mai rar apropiate max sunt accesate. Cu cât este mai aproape de 0
parametru, cu atât este mai plată (mai uniformă) distribuția accesului. O aproximare grosolană
a distribuției este că cele mai frecvente valori de 1% din interval, aproape de minute,
sunt desenate parametru% din timp. parametru valoarea trebuie să fie strict pozitivă.
Exemplu:
\setrandom aid 1 :naaccounts gaussian 5.0
\dormi număr [ noi | ms | s]
Face ca execuția scriptului să intre în somn pentru durata specificată în microsecunde (us),
milisecunde (ms) sau secunde (s). Dacă unitatea este omisă, secundele sunt implicite.
număr poate fi fie o constantă întreagă, fie o:nume variabilă referire la o variabilă
având o valoare întreagă.
Exemplu:
\sleep 10 ms
\setshell varname comandă [ argument ... ]
Setează variabile varname la rezultatul comenzii shell comandă. Comanda trebuie
returnează o valoare întreagă prin rezultatul standard.
argument poate fi fie o constantă text, fie o:nume variabilă referire la o variabilă a
orice fel. Dacă doriți să utilizați argument începând cu două puncte, trebuie să adăugați un
colon suplimentar la începutul argument.
Exemplu:
\setshell variable_to_be_assigned command literal_argument :variable ::literal_starting_with_colon
\coajă comandă [ argument ... ]
La fel ca \setshell, dar rezultatul este ignorat.
Exemplu:
\shell command literal_argument :variable ::literal_starting_with_colon
De exemplu, definiția completă a tranzacției încorporate de tip TPC-B este:
\set nbranches :scale
\set ntellers 10 * :scale
\set naccounts 100000 * :scale
\setrandom aid 1 :naaccounts
\setrandom bid 1 :nbranches
\setrandom tid 1 :ntellers
\setrandom delta -5000 5000
ÎNCEPE;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECTAȚI abalance FROM pgbench_accounts WHERE aid = :aid;
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
SFÂRŞIT;
Acest script permite fiecărei iterații a tranzacției să facă referire diferită,
rânduri alese aleatoriu. (Acest exemplu arată, de asemenea, de ce este important pentru fiecare sesiune client
să aibă propriile variabile — altfel nu s-ar atinge independent de diferite
rânduri.)
Per-tranzacție Exploatari forestiere
Cu -l opțiune dar fără --interval-agregat, pgbench scrie timpul luat de
fiecare tranzacție într-un fișier jurnal. Fișierul jurnal va fi numit pgbench_log.NNN, În cazul în care NNN is
PID-ul procesului pgbench. Dacă -j opțiunea este 2 sau mai mare, creând mai mulți lucrători
fire, fiecare va avea propriul său fișier jurnal. Primul lucrător va folosi același nume pentru el
fișier jurnal ca în cazul standard al unui singur lucrător. Fișierele jurnal suplimentare pentru celălalt
lucrătorii vor fi numiți pgbench_log.NNN.mmm, În cazul în care mmm este un număr secvenţial pentru fiecare
muncitor incepand cu 1.
Formatul jurnalului este:
client_id tranzacție_nr timp număr fișier epoca_timp time_us [program_lag]
Unde timp este timpul total de tranzacție scurs în microsecunde, număr fișier identifică care
a fost folosit fișierul script (util când au fost specificate mai multe scripturi cu -f), Şi
epoca_timp/time_us sunt un marcaj de timp în format de epocă Unix și un offset în microsecunde
(potrivit pentru crearea unui marcaj de timp ISO 8601 cu fracțiuni de secunde) care arată când
tranzacție finalizată. Camp program_lag este diferența dintre cele ale tranzacției
ora de începere programată și ora la care a început efectiv, în microsecunde. Este doar
prezent atunci când --rată este folosită opțiunea. Ultimul câmp skipped_transactions raportează
numărul de tranzacții a fost omisă deoarece au fost prea întârziate. Este doar
prezente atunci când ambele opțiuni --rată si --limita-latentei sunt folosite.
Iată un fragment din fișierul jurnal generat:
0 199 2241 0 1175850568 995598
0 200 2465 0 1175850568 998079
0 201 2513 0 1175850569 608
0 202 2038 0 1175850569 2663
Un alt exemplu cu --rate=100 și --latency-limit=5 (rețineți codul suplimentar program_lag
coloană):
0 81 4621 0 1412881037 912698 3005
0 82 6173 0 1412881037 914578 4304
0 83 omis 0 1412881037 914578 5217
0 83 omis 0 1412881037 914578 5099
0 83 4722 0 1412881037 916203 3108
0 84 4142 0 1412881037 918023 2333
0 85 2465 0 1412881037 919759 740
În acest exemplu, tranzacția 82 a întârziat, deoarece latența sa (6.173 ms) a fost peste 5
limita ms. Următoarele două tranzacții au fost sărite, pentru că au întârziat deja înainte
chiar au fost începute.
Când rulați un test lung pe hardware care poate gestiona o mulțime de tranzacții, fișierele jurnal
poate deveni foarte mare. The --rata de eșantionare opțiunea poate fi folosită pentru a înregistra doar un eșantion aleatoriu
a tranzactiilor.
cumulate Exploatari forestiere
Cu --interval-agregat opțiunea, jurnalele folosesc un format puțin diferit:
interval_start număr_de_tranzacții suma_latenței latency_2_sum min_latency max_latency [lag_sum lag_2_sum min_lag max_lag [skipped_transactions]]
Unde interval_start este începutul intervalului (marca temporală în format Unix epoch),
număr_de_tranzacții este numărul de tranzacții din interval, suma_latenței este
suma latențelor (astfel încât să puteți calcula cu ușurință latența medie). Următoarele două câmpuri sunt
util pentru estimarea varianței - suma_latenței este o sumă de latenţe şi latency_2_sum este
suma puterilor a 2-a de latențe. Ultimele două câmpuri sunt min_latency - o latență minimă
în interval, și max_latency - latența maximă în interval. O tranzacție
este contorizat în intervalul în care a fost comis. Câmpurile în cele din urmă, lag_sum,
lag_2_sum, min_lag și max_lag, sunt prezente numai dacă --rată este folosită opțiunea. Foarte
ultimul, skipped_transactions, este prezent numai dacă opțiunea --limita-latentei este prezent,
de asemenea. Acestea sunt calculate din momentul în care fiecare tranzacție a trebuit să aștepte cea anterioară
pentru a termina, adică diferența dintre ora de începere programată a fiecărei tranzacții și
momentul în care a început de fapt.
Iată exemple de ieșiri:
1345828501 5601 1542744 483552416 61 2573
1345828503 7884 1979812 565806736 60 1479
1345828505 7208 1979422 567277552 59 1391
1345828507 7685 1980268 569784714 60 1398
1345828509 7073 1979779 573489941 236 1411
Observați că, în timp ce fișierul jurnal simplu (neagregat) conține indexul scriptului personalizat
fișiere, jurnalul agregat nu. Prin urmare, dacă aveți nevoie de date per script, trebuie
agregați datele pe cont propriu.
Per-Declarație latențe
Cu -r opțiunea, pgbench colectează timpul de tranzacție scurs pentru fiecare extras
executate de fiecare client. Apoi raportează o medie a acestor valori, denumită
latența pentru fiecare declarație, după terminarea benchmark-ului.
Pentru scriptul implicit, rezultatul va arăta similar cu acesta:
incepand vidul...sfarsit.
tip tranzacție: TPC-B (un fel de)
factor de scalare: 1
modul de interogare: simplu
Numar de clienti: 10
numărul de fire: 1
numărul de tranzacții per client: 1000
numărul de tranzacții efectiv procesate: 10000/10000
tps = 618.764555 (inclusiv stabilirea conexiunilor)
tps = 622.977698 (excluzând stabilirea conexiunilor)
latențe declarației în milisecunde:
0.004386 \set nbranches 1 * :scale
0.001343 \set ntellers 10 * :scale
0.001212 \set naccounts 100000 * :scale
0.001310 \setrandom aid 1 :naccounts
0.001073 \setrandom bid 1 :nbranches
0.001005 \setrandom tid 1 :ntellers
0.001078 \setrandom delta -5000 5000
0.326152 ÎNCEPE;
0.603376 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
0.454643 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
5.528491 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
7.335435 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
0.371851 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
1.212976 END;
Dacă sunt specificate mai multe fișiere script, mediile sunt raportate separat pentru fiecare
fișier script.
Rețineți că colectarea informațiilor suplimentare de sincronizare necesare pentru latența per declarație
calculul adaugă o suprasarcină. Acest lucru va încetini viteza medie de execuție și va reduce
TPS calculat. Gradul de încetinire variază semnificativ în funcție de platformă și
hardware. Compararea valorilor medii TPS cu și fără raportarea latenței activată este a
o modalitate bună de a măsura dacă timpul general este semnificativ.
Bun Practici
Este foarte ușor să utilizați pgbench pentru a produce numere complet lipsite de sens. Aici sunt câteva
ghiduri pentru a vă ajuta să obțineți rezultate utile.
In primul loc, nu credeți în orice test care rulează doar câteva secunde. Folosește -t or
-T opțiunea de a face alergarea să dureze cel puțin câteva minute, astfel încât să se facă o medie a zgomotului. În unele
cazuri, ați putea avea nevoie de ore pentru a obține numere care sunt reproductibile. Este o idee bună să încerci
testul rulează de câteva ori, pentru a afla dacă numerele tale sunt reproductibile sau nu.
Pentru scenariul de testare implicit TPC-B, factorul de scară de inițializare (-s) ar trebui să fie
cel puțin la fel de mare ca cel mai mare număr de clienți pe care intenționați să-i testați (-c); altfel vei
mai ales să măsoare disputa de actualizare. Sunt doar -s rânduri în pgbench_branches
tabel, iar fiecare tranzacție dorește să actualizeze una dintre ele, deci -c valori peste -s
va avea ca rezultat, fără îndoială, o mulțime de tranzacții blocate în așteptarea altor tranzacții.
Scenariul de testare implicit este, de asemenea, destul de sensibil la cât timp a trecut de la tabelele
au fost inițializate: acumularea de rânduri moarte și spațiu mort în tabele modifică
rezultate. Pentru a înțelege rezultatele trebuie să urmăriți numărul total de actualizări și
când are loc aspirarea. Dacă autovacuum este activat, poate duce la schimbări imprevizibile în
performanta masurata.
O limitare a pgbench este că poate deveni în sine un blocaj atunci când se încearcă testarea a
număr mare de sesiuni client. Acest lucru poate fi atenuat rulând pgbench pe un alt
mașină de pe serverul bazei de date, deși latența redusă a rețelei va fi esențială. S-ar putea
chiar să fie util pentru a rula mai multe instanțe pgbench simultan, pe mai multe mașini client,
împotriva aceluiași server de baze de date.
Utilizați pgbench online folosind serviciile onworks.net