گزینه‌های مقداردهی اولیه (Initialization Options)

pgbench آرگومان‌های خط فرمان مقداردهی اولیه زیر را می‌پذیرد:

[-d] dbname
[--dbname=]dbname

-i
--initialize

-I init_steps
--init-steps=init_steps

-F fillfactor
--fillfactor=fillfactor

-n
--no-vacuum

-q
--quiet

-s scale_factor
--scale=scale_factor

--foreign-keys

--index-tablespace=index_tablespace

--partition-method=NAME

--partitions=NUM

--tablespace=tablespace

--unlogged-tables

گزینه‌های بنچ‌مارک (Benchmarking Options)

pgbench آرگومان‌های خط فرمانی زیر را برای بنچ‌مارک می‌پذیرد:

-b scriptname[@weight]
--builtin=scriptname[@weight]

-c clients
--client=clients

-C
--connect

-D varname=value
--define=varname=value

-f filename[@weight]
--file=filename[@weight]

-j threads
--jobs=threads

-l
--log

-L limit
--latency-limit=limit

-M querymode
--protocol=querymode

-n
--no-vacuum

-N
--skip-some-updates

-P sec
--progress=sec

-r
--report-per-command

-R rate
--rate=rate

-s scale_factor
--scale=scale_factor

-S
--select-only

-t transactions
--transactions=transactions

-T seconds
--time=seconds

-v
--vacuum-all

--aggregate-interval=seconds

--exit-on-abort

--failures-detailed

--log-prefix=prefix

--max-tries=number_of_tries

--progress-timestamp

--random-seed=seed

--sampling-rate=rate

--show-script=scriptname

--verbose-errors

گزینه‌های عمومی (Common Options)

دستور pgbench همچنین آرگومان‌های معمول خط فرمان زیر را برای پارامترهای اتصال و سایر تنظیمات عمومی می‌پذیرد:

--debug

-h hostname
--host=hostname

-p port
--port=port

-U login
--username=login

-V
--version

-?
--help

«تراکنش» اجرا شده در pgbench دقیقاً چیست؟ (What Is the “Transaction” Actually Performed in pgbench?)

pgbench اسکریپت‌های آزمایشی را که به‌صورت تصادفی از یک فهرست مشخص انتخاب شده‌اند، اجرا می‌کند. این اسکریپت‌ها می‌توانند شامل اسکریپت‌های توکار مشخص‌شده با -b و اسکریپت‌های ارائه‌شده توسط کاربر مشخص‌شده با -f باشند. به هر اسکریپت می‌توان یک وزن نسبی اختصاص داد که پس از علامت @ مشخص می‌شود تا احتمال انتخاب آن تغییر کند. وزن پیش‌فرض 1 است. اسکریپت‌های با وزن 0 نادیده گرفته می‌شوند.

اسکریپت تراکنش توکار پیش‌فرض (که با -b tpcb-like نیز فراخوانی می‌شود) در هر تراکنش هفت دستور را روی مقادیر تصادفی انتخاب‌شده از aid، tid، bid و delta صادر می‌کند. این سناریو از بنچ‌مارک TPC-B الهام گرفته شده است، اما در واقع خود TPC-B نیست، و نام‌گذاری آن نیز به همین دلیل است.

اگر اسکریپت توکار simple-update را انتخاب کنید (همچنین با -N)، مراحل 4 و 5 در تراکنش گنجانده نمی‌شوند. این کار از رقابت به‌روزرسانی بر روی این جدول‌ها جلوگیری می‌کند، اما مورد آزمایشی را حتی کمتر از قبل شبیه TPC-B می‌سازد.

اگر اسکریپت توکار select-only را انتخاب کنید (همچنین با -S)، تنها دستور SELECT صادر می‌شود.

اسکریپت‌های سفارشی (Custom Scripts)

ابزار pgbench از اجرای سناریوهای محک (benchmark) سفارشی از طریق جایگزین کردن اسکریپت تراکنش پیش‌فرض (توصیف‌شده در بالا) با یک اسکریپت تراکنش خوانده‌شده از فایل (گزینه -f) پشتیبانی می‌کند. در این حالت یک “تراکنش” معادل یک بار اجرای فایل اسکریپت در نظر گرفته می‌شود.

یک فایل اسکریپت شامل یک یا چند دستور SQL است که با نقطه-ویرگول خاتمه می‌یابند. خطوط خالی و خطوطی که با -- شروع می‌شوند نادیده گرفته می‌شوند. همچنین فایل‌های اسکریپت می‌توانند شامل “دستورهای متا” باشند که همان‌طور که در ادامه شرح داده شده است توسط خود pgbench تفسیر می‌شوند.

یک قابلیت ساده برای جایگزینی متغیرها در فایل‌های اسکریپت وجود دارد. نام متغیرها باید شامل حروف (از جمله حروف غیرلاتین)، ارقام و خط زیر (underscore) باشد، به‌طوری که کاراکتر اول رقم نباشد. متغیرها را می‌توان با گزینه خط فرمان -D که در بالا توضیح داده شد، یا با دستورهای متا که در ادامه شرح داده می‌شوند، مقداردهی کرد. علاوه بر متغیرهایی که از قبل با گزینه‌های خط فرمان -D تنظیم شده‌اند، چند متغیر وجود دارند که به‌طور خودکار مقداردهی اولیه می‌شوند و در Table 301 فهرست شده‌اند. مقداری که با استفاده از -D برای این متغیرها مشخص شود، بر مقادیر خودکار پیش‌فرض تقدم دارد. پس از تنظیم، مقدار یک متغیر را می‌توان با نوشتن :variablename درون یک دستور SQL درج کرد. هنگام اجرای بیش از یک نشست کلاینت، هر نشست مجموعه متغیرهای خاص خود را دارد. pgbench تا ۲۵۵ بار استفاده از متغیر را در یک دستور پشتیبانی می‌کند.

Table 301. pgbench Automatic Variables

دستورهای متای فایل اسکریپت با یک بک‌اسلش (\) آغاز می‌شوند و به‌طور معمول تا انتهای خط امتداد می‌یابند، اگرچه می‌توان با نوشتن بک‌اسلش-اینتر (backslash-return) آن‌ها را در خطوط بعدی نیز ادامه داد. آرگومان‌های یک دستور متا با فاصله (white space) از هم جدا می‌شوند. این دستورهای متا پشتیبانی می‌شوند:

\gset [prefix] \aset [prefix]

UPDATE pgbench_accounts
  SET abalance = abalance + :delta
  WHERE aid = :aid
  RETURNING abalance \gset
-- compound of two queries
SELECT 1 \;
SELECT 2 AS two, 3 AS three \gset p_
SELECT 4 AS four \; SELECT 5 AS five \aset

\if expression
\elif expression
\else
\endif

\set varname expression

\set ntellers 10 * :scale
\set aid (1021 * random(1, 100000 * :scale)) % \
           (100000 * :scale) + 1
\set divx CASE WHEN :x <> 0 THEN :y/:x ELSE NULL END

\sleep number [ us | ms | s ]

\sleep 10 ms

\setshell varname command [ argument ... ]

\setshell variable_to_be_assigned command literal_argument :variable ::literal_starting_with_colon

\shell command [ argument ... ]

\shell command literal_argument :variable ::literal_starting_with_colon

\startpipeline
\syncpipeline
\endpipeline

عملگرهای داخلی (Built-in Operators)

عملگرهای حسابی، بیتی، مقایسه‌ای و منطقی فهرست‌شده در Table 302 به‌صورت توکار در pgbench پیاده‌سازی شده‌اند و می‌توان از آن‌ها در عبارت‌هایی که در \set می‌آیند استفاده کرد. این عملگرها به ترتیب اولویت صعودی فهرست شده‌اند. به‌جز موارد قید شده، عملگرهایی که دو ورودی عددی می‌گیرند، در صورتی که هر یک از ورودی‌ها از نوع اعشاری (double) باشد، مقداری از نوع double تولید می‌کنند؛ در غیر این صورت، نتیجه از نوع عدد صحیح (integer) خواهد بود.

Table 302. pgbench Operators

توابع داخلی (Built-In Functions)

توابع فهرست‌شده در
Table 303 به‌صورت توکار در pgbench پیاده‌سازی شده‌اند و می‌توان از آن‌ها در عبارت‌هایی که در \set می‌آیند استفاده کرد.

Table 303. pgbench Functions

تابع
random مقادیر را با استفاده از توزیع یکنواخت تولید می‌کند؛ به این معنی که تمام مقادیر در محدوده تعیین‌شده با احتمال برابر انتخاب می‌شوند. توابع random_exponential، random_gaussian و random_zipfian نیازمند یک پارامتر اعشاری مضاعف (double) اضافی هستند که شکل دقیق توزیع را تعیین می‌کند.

f(x) = exp(-parameter * (x - min) / (max - min + 1)) / (1 - exp(-parameter))

f(x) = PHI(2.0 * parameter * (x - mu) / (max - min + 1)) /
       (2.0 * PHI(parameter) - 1)

توابع هش hash، hash_murmur2 و hash_fnv1a یک مقدار ورودی و یک پارامتر بذر (seed) اختیاری می‌پذیرند. در صورتی که بذر تعیین نشود، مقدار :default_seed استفاده می‌شود که به‌طور تصادفی مقداردهی اولیه می‌گردد، مگر اینکه با گزینه -D خط فرمان تنظیم شده باشد.

تابع permute یک مقدار ورودی، یک اندازه، و یک پارامتر بذر اختیاری می‌پذیرد. این تابع یک جایگشت شبه‌تصادفی از اعداد صحیح در محدوده [0, size) تولید کرده و نمایه (index) مقدار ورودی را در میان مقادیر جایگشت‌یافته برمی‌گرداند. جایگشت انتخاب‌شده توسط بذر پارامترسازی می‌شود که در صورت عدم تعیین، به‌طور پیش‌فرض :default_seed است. برخلاف توابع هش، permute تضمین می‌کند که هیچ تداخل (collision) یا شکافی در مقادیر خروجی وجود نداشته باشد. مقادیر ورودی خارج از بازه بر مبنای باقی‌مانده تقسیم بر اندازه (modulo size) تفسیر می‌شوند. اگر اندازه مثبت نباشد، تابع یک خطا صادر می‌کند.

permute می‌تواند برای پراکنده ساختن توزیع توابع تصادفی غیریکنواخت مانند random_zipfian یا random_exponential به‌کار رود تا مقادیری که بیشتر انتخاب می‌شوند همبستگی آشکاری با یکدیگر نداشته باشند. برای مثال، اسکریپت pgbench زیر یک بار کاری واقعی احتمالی را شبیه‌سازی می‌کند که برای شبکه‌های اجتماعی و پلتفرم‌های وبلاگ‌نویسی معمول است؛ جایی که تعداد کمی از حساب‌ها بار کاری بسیار زیادی ایجاد می‌کنند:

\set size 1000000
\set r random_zipfian(1, :size, 1.07)
\set k 1 + permute(:r, :size)

در برخی موارد به چند توزیع متمایز نیاز است که با یکدیگر همبستگی نداشته باشند و در اینجاست که پارامتر بذر اختیاری به کار می‌آید:

\set k1 1 + permute(:r, :size, :default_seed + 123)
\set k2 1 + permute(:r, :size, :default_seed + 321)

رفتار مشابهی را می‌توان با hash نیز تقریب زد:

\set size 1000000
\set r random_zipfian(1, 100 * :size, 1.07)
\set k 1 + abs(hash(:r)) % :size

با این حال، از آنجا که hash تداخل (collision) تولید می‌کند، برخی مقادیر در دسترس نخواهند بود و برخی دیگر با بسامدی بیش از آنچه از توزیع اصلی انتظار می‌رود رخ خواهند داد.

به‌عنوان مثال، تعریف کامل تراکنش پیش‌ساخته مشابه TPC-B عبارت است از:

\set aid random(1, 100000 * :scale)
\set bid random(1, 1 * :scale)
\set tid random(1, 10 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECT 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);
END;

این اسکریپت به هر تکرار از تراکنش اجازه می‌دهد به سطرهای متفاوت و به‌صورت تصادفی انتخاب‌شده ارجاع دهد. (این مثال همچنین نشان می‌دهد چرا مهم است هر نشست کلاینت متغیرهای خاص خود را داشته باشد — در غیر این صورت آن‌ها به‌طور مستقل به سطرهای متفاوت دسترسی نخواهند داشت.)

ثبت وقایع بر اساس هر تراکنش (Per-Transaction Logging)

با گزینه -l (اما بدون گزینه --aggregate-interval)، برنامه pgbench اطلاعات مربوط به هر تراکنش را در یک فایل لاگ می‌نویسد. نام فایل لاگ به صورت prefix.nnn خواهد بود، که در آن prefix به طور پیش‌فرض pgbench_log است و nnn شناسه فرایند (PID) پردازش pgbench می‌باشد. پیشوند را می‌توان با استفاده از گزینه --log-prefix تغییر داد. اگر گزینه -j برابر ۲ یا بیشتر باشد، به طوری که چندین رشته کاری (worker threads) وجود داشته باشد، هر کدام فایل لاگ اختصاصی خود را خواهند داشت. اولین worker از همان نامی برای فایل لاگ خود استفاده می‌کند که در حالت استاندارد تک‌worker استفاده می‌شود. فایل‌های لاگ اضافی برای سایر workerها با الگوی prefix.nnn.mmm نام‌گذاری می‌شوند، که در آن mmm یک شماره ترتیبی برای هر worker است که از ۱ آغاز می‌شود.

هر خط در فایل لاگ، یک تراکنش را شرح می‌دهد. این خط شامل فیلدهای زیر است که با فاصله از هم جدا شده‌اند:

client_id

transaction_no

time

script_no

time_epoch

time_us

schedule_lag

retries

هنگامی که هر دو گزینه --rate و --latency-limit استفاده شوند، مقدار time برای یک تراکنش نادیده‌گرفته‌شده به صورت skipped گزارش می‌شود. اگر تراکنش با شکست خاتمه یابد، مقدار time آن به صورت failed گزارش خواهد شد. اگر از گزینه --failures-detailed استفاده کنید، مقدار time تراکنش ناموفق بر اساس نوع خطا به صورت serialization یا deadlock گزارش خواهد شد (برای اطلاعات بیشتر به بخش Failures and Serialization/Deadlock Retries مراجعه فرمایید).

در اینجا نمونه‌ای از فایل لاگ تولیدشده در یک اجرای تک‌کلاینتی آورده شده است:

0 199 2241 0 1175850568 995598
0 200 2465 0 1175850568 998079
0 201 2513 0 1175850569 608
0 202 2038 0 1175850569 2663

مثالی دیگر با --rate=100 و --latency-limit=5 (به ستون اضافی schedule_lag توجه کنید):

0 81 4621 0 1412881037 912698 3005
0 82 6173 0 1412881037 914578 4304
0 83 skipped 0 1412881037 914578 5217
0 83 skipped 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

در این مثال، تراکنش ۸۲ با تاخیر مواجه شد، زیرا زمان تاخیر آن (۶.۱۷۳ میلی‌ثانیه) فراتر از محدودیت ۵ میلی‌ثانیه بود. دو تراکنش بعدی نادیده گرفته شدند (skipped)، زیرا پیش از آنکه حتی آغاز شوند، بیش از حد به تاخیر افتاده بودند.

مثال زیر بخشی از یک فایل لاگ به همراه خطاها و تلاش‌های مجدد را نشان می‌دهد، که در آن حداکثر تعداد تلاش‌ها روی ۱۰ تنظیم شده است (به ستون اضافی retries توجه کنید):

3 0 47423 0 1499414498 34501 3
3 1 8333 0 1499414498 42848 0
3 2 8358 0 1499414498 51219 0
4 0 72345 0 1499414498 59433 6
1 3 41718 0 1499414498 67879 4
1 4 8416 0 1499414498 76311 0
3 3 33235 0 1499414498 84469 3
0 0 failed 0 1499414498 84905 9
2 0 failed 0 1499414498 86248 9
3 4 8307 0 1499414498 92788 0

اگر گزینه --failures-detailed استفاده شود، نوع خطا در ستون time به صورت زیر گزارش می‌شود:

3 0 47423 0 1499414498 34501 3
3 1 8333 0 1499414498 42848 0
3 2 8358 0 1499414498 51219 0
4 0 72345 0 1499414498 59433 6
1 3 41718 0 1499414498 67879 4
1 4 8416 0 1499414498 76311 0
3 3 33235 0 1499414498 84469 3
0 0 serialization 0 1499414498 84905 9
2 0 serialization 0 1499414498 86248 9
3 4 8307 0 1499414498 92788 0

هنگام اجرای یک آزمایش طولانی روی سخت‌افزاری که توانایی پردازش تعداد بالایی از تراکنش‌ها را دارد، حجم فایل‌های لاگ ممکن است بسیار زیاد شود. با استفاده از گزینه --sampling-rate می‌توان تنها یک نمونه‌برداری تصادفی از تراکنش‌ها را ثبت کرد.

ثبت وقایع تجمیعی (Aggregated Logging)

با گزینه --aggregate-interval، قالب متفاوتی برای فایل‌های لاگ به کار گرفته می‌شود. هر خط از فایل لاگ یک بازه تجمیعی را شرح می‌دهد. این خط شامل فیلدهای زیر است که با فاصله از هم جدا شده‌اند:

interval_start

num_transactions

sum_latency

sum_latency_2

min_latency

max_latency

sum_lag

sum_lag_2

min_lag

max_lag

skipped

retried

retries

serialization_failures

deadlock_failures

در اینجا نمونه‌ای از خروجی تولیدشده با این گزینه آورده شده است:

pgbench --aggregate-interval=10 --time=20 --client=10 --log --rate=1000 --latency-limit=10 --failures-detailed --max-tries=10 test
1650260552 5178 26171317 177284491527 1136 44462 2647617 7321113867 0 9866 64 7564 28340 4148 0
1650260562 4808 25573984 220121792172 1171 62083 3037380 9666800914 0 9998 598 7392 26621 4527 0

توجه کنید در حالی که قالب لاگ ساده (غیرتجمیعی) نشان می‌دهد چه اسکریپتی برای هر تراکنش استفاده شده است، قالب تجمیعی این کار را نمی‌کند. بنابراین اگر به داده‌های تفکیک‌شده بر اساس هر اسکریپت نیاز دارید، باید داده‌ها را شخصاً تجمیع کنید.

گزارش به ازای هر دستور (Per-Statement Report)

با استفاده از گزینه -r ، pgbench آمارهای زیر را برای هر دستور جمع‌آوری می‌کند:

این گزارش آمارهای تلاش مجدد را تنها در صورتی نمایش می‌دهد که گزینه --max-tries برابر با ۱ نباشد.

تمام مقادیر برای هر دستور اجراشده توسط هر کلاینت محاسبه شده و پس از پایان آزمون محک گزارش می‌شوند.

برای اسکریپت پیش‌فرض، خروجی مشابه زیر خواهد بود:

starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
maximum number of tries: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
number of failed transactions: 0 (0.000%)
number of transactions above the 50.0 ms latency limit: 1311/10000 (13.110 %)
latency average = 28.488 ms
latency stddev = 21.009 ms
initial connection time = 69.068 ms
tps = 346.224794 (without initial connection time)
statement latencies in milliseconds and failures:
   0.012  0  \set aid random(1, 100000 * :scale)
   0.002  0  \set bid random(1, 1 * :scale)
   0.002  0  \set tid random(1, 10 * :scale)
   0.002  0  \set delta random(-5000, 5000)
   0.319  0  BEGIN;
   0.834  0  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
   0.641  0  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
  11.126  0  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
  12.961  0  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
   0.634  0  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
   1.957  0  END;

مثال دیگری از خروجی برای اسکریپت پیش‌فرض با استفاده از سطح انزوای پیش‌فرض سریال‌پذیر تراکنش (PGOPTIONS='-c default_transaction_isolation=serializable' pgbench ...):

starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
maximum number of tries: 10
number of transactions per client: 1000
number of transactions actually processed: 6317/10000
number of failed transactions: 3683 (36.830%)
number of transactions retried: 7667 (76.670%)
total number of retries: 45339
number of transactions above the 50.0 ms latency limit: 106/6317 (1.678 %)
latency average = 17.016 ms
latency stddev = 13.283 ms
initial connection time = 45.017 ms
tps = 186.792667 (without initial connection time)
statement latencies in milliseconds, failures and retries:
  0.006     0      0  \set aid random(1, 100000 * :scale)
  0.001     0      0  \set bid random(1, 1 * :scale)
  0.001     0      0  \set tid random(1, 10 * :scale)
  0.001     0      0  \set delta random(-5000, 5000)
  0.385     0      0  BEGIN;
  0.773     0      1  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
  0.624     0      0  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
  1.098   320   3762  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
  0.582  3363  41576  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
  0.465     0      0  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
  1.933     0      0  END;

اگر چندین فایل اسکریپت مشخص شده باشد، تمامی آمارها برای هر فایل اسکریپت به‌طور جداگانه گزارش می‌شوند.

توجه داشته باشید که جمع‌آوری اطلاعات زمان‌بندی اضافی مورد نیاز برای محاسبه تاخیر به ازای هر دستور، مقداری بار اضافی (overhead) تحمیل می‌کند. این امر سرعت میانگین اجرا را کاهش داده و TPS محاسبه‌شده را پایین می‌آورد. میزان این افت سرعت بسته به پلتفرم و سخت‌افزار تفاوت چشمگیری دارد. مقایسه مقادیر میانگین TPS در دو حالت فعال بودن و غیرفعال بودن گزارش تاخیر، روش مناسبی برای ارزیابی قابل‌توجه بودن بار اضافی زمان‌بندی است.

شکست‌ها و تلاش‌های مجدد در خطاهای سریال‌سازی/بن‌بست (Failures and Serialization/Deadlock Retries)

هنگام اجرای pgbench ، سه نوع اصلی از خطاها وجود دارند:

اجرای یک کلاینت در صورت بروز یک خطای جدی لغو می‌شود؛ به عنوان مثال، اتصال با سرور پایگاه داده قطع شود یا پایان اسکریپت بدون تکمیل آخرین تراکنش فرا برسد. علاوه بر این، اگر اجرای یک دستور SQL یا یک متادستور به دلایلی غیر از خطاهای سریال‌سازی یا بن‌بست با شکست مواجه شود، کلاینت لغو می‌گردد. در غیر این صورت، چنانچه یک دستور SQL با خطاهای سریال‌سازی یا بن‌بست مواجه شود، کلاینت لغو نخواهد شد. در چنین حالت‌هایی، تراکنش جاری به عقب بازگردانده می‌شود (rollback)، که شامل بازگرداندن متغیرهای کلاینت به وضعیت پیش از اجرای این تراکنش نیز می‌گردد (فرض بر این است که یک اسکریپت تراکنش تنها شامل یک تراکنش است؛ برای اطلاعات بیشتر به «تراکنش» اجرا شده در pgbench دقیقاً چیست؟ (What Is the "Transaction" Actually Performed in pgbench?) مراجعه کنید). تراکنش‌های دارای خطای سریال‌سازی یا بن‌بست پس از rollback تکرار می‌شوند تا زمانی که با موفقیت به پایان برسند یا به حداکثر تعداد تلاش‌ها (مشخص‌شده با گزینه --max-tries ) / حداکثر زمان تلاش‌های مجدد (مشخص‌شده با گزینه --latency-limit ) / پایان آزمون محک (مشخص‌شده با گزینه --time ) برسند. اگر آخرین تلاش برای اجرا شکست بخورد، این تراکنش به عنوان ناموفق گزارش می‌شود اما کلاینت لغو نخواهد شد و به کار خود ادامه می‌دهد.

تاخیر یک تراکنش موفق شامل کل مدت زمان اجرای تراکنش همراه با بازگردانی‌ها (rollbacks) و تلاش‌های مجدد است. تاخیر فقط برای تراکنش‌ها و دستورات موفق اندازه‌گیری می‌شود، نه برای تراکنش‌ها یا دستورات ناموفق.

گزارش اصلی شامل تعداد تراکنش‌های ناموفق است. اگر گزینه --max-tries مخالف ۱ باشد، گزارش اصلی همچنین شامل آمار مربوط به تلاش‌های مجدد خواهد بود: تعداد کل تراکنش‌های بازآزموده‌شده و تعداد کل تلاش‌های مجدد. گزارش به ازای هر اسکریپت تمام این فیلدها را از گزارش اصلی به ارث می‌برد. گزارش به ازای هر دستور آمار تلاش مجدد را تنها در صورتی نمایش می‌دهد که گزینه --max-tries مخالف ۱ باشد.

اگر می‌خواهید شکست‌ها را بر اساس انواع پایه در لاگ‌های به ازای تراکنش و تجمیعی، و همچنین در گزارش‌های اصلی و به ازای اسکریپت دسته‌بندی کنید، از گزینه --failures-detailed استفاده کنید. اگر می‌خواهید همه خطاها و شکست‌ها (خطاهای بدون تلاش مجدد) را بر اساس نوع تفکیک کنید، شامل این‌که کدام حد مجاز برای تلاش‌های مجدد رد شده است و برای شکست‌های سریال‌سازی/بن‌بست چقدر از آن حد فراتر رفته است، از گزینه --verbose-errors استفاده نمایید.

روش‌های دسترسی به جدول (Table Access Methods)

شما می‌توانید روش دسترسی به جدول (Table Access Method) را برای جداول pgbench مشخص کنید. متغیر محیطی PGOPTIONS گزینه‌های پیکربندی پایگاه داده را که از طریق خط فرمان به PostgreSQL ارسال می‌شوند، تعیین می‌کند (بخش Section 19.1.4 را ببینید). برای نمونه، یک روش فرضی دسترسی به جدول پیش‌فرض برای جداولی که pgbench ایجاد می‌کند به نام wuzza را می‌توان با دستور زیر مشخص کرد:

PGOPTIONS='-c default_table_access_method=wuzza'

روش‌های بهینه و توصیه‌ها (Good Practices)

تولید اعداد و ارقام کاملاً بی‌معنی با استفاده از pgbench بسیار آسان است. در اینجا چند دستورالعمل برای کمک به دریافت نتایج مفید آورده شده است.

در وهله نخست، هرگز به آزمونی که تنها چند ثانیه اجرا می‌شود اعتماد نکنید. از گزینه -t یا -T استفاده کنید تا اجرای آزمون حداقل چند دقیقه طول بکشد و نوسانات و نویزها به صورت میانگین تعدیل شوند. در برخی موارد ممکن است برای دستیابی به اعدادی که تکرارپذیر باشند، به ساعت‌ها زمان نیاز داشته باشید. ایده خوبی است که اجرای آزمون را چند بار امتحان کنید تا مشخص شود که آیا اعداد به‌دست‌آمده تکرارپذیر هستند یا خیر.

برای سناریوی آزمایشی پیش‌فرض مشابه TPC-B، ضریب مقیاس مقداردهی اولیه (-s) باید حداقل به بزرگی بیشترین تعداد کلاینت‌هایی باشد که قصد آزمایش آن‌ها را دارید (-c)؛ در غیر این صورت، عمدتاً در حال اندازه‌گیری رقابت بر سر به‌روزرسانی (update contention) خواهید بود. در جدول pgbench_branches تنها به تعداد -s ردیف وجود دارد، و هر تراکنش می‌خواهد یکی از آن‌ها را به‌روزرسانی کند، بنابراین مقادیر -c بیشتر از -s بدون شک منجر به مسدود شدن بسیاری از تراکنش‌ها در انتظار سایر تراکنش‌ها خواهد شد.

سناریوی آزمون پیش‌فرض همچنین نسبت به مدت‌زمانی که از مقداردهی اولیه جدول‌ها گذشته بسیار حساس است: انباشت ردیف‌های مرده (dead rows) و فضای خالی در جدول‌ها نتایج را تغییر می‌دهد. برای درک درست نتایج، باید تعداد کل به‌روزرسانی‌ها و زمان انجام عملیات پاکسازی (vacuuming) را زیر نظر داشته باشید. در صورت فعال بودن autovacuum، ممکن است تغییرات غیرقابل پیش‌بینی در کارایی اندازه‌گیری‌شده رخ دهد.

یکی از محدودیت‌های pgbench این است که هنگام آزمایش تعداد زیادی از نشست‌های کلاینت، خودش می‌تواند به یک گلوگاه (bottleneck) تبدیل شود. این مشکل را می‌توان با اجرای pgbench روی ماشینی مجزا از سرور پایگاه داده کاهش داد، هرچند تاخیر پایین شبکه (low network latency) در این حالت ضروری خواهد بود. حتی ممکن است اجرای همزمان چندین نمونه از pgbench روی چندین ماشین کلاینت علیه یک سرور پایگاه داده مفید باشد.

امنیت (Security)

اگر کاربران غیرقابل‌اعتماد به پایگاه داده‌ای دسترسی دارند که از الگوی استفاده از شمای امن (secure schema usage pattern) پیروی نکرده است، pgbench را در آن پایگاه داده اجرا نکنید. pgbench از نام‌های واجد شرایط نشده (unqualified names) استفاده می‌کند و مسیر جستجو (search path) را دستکاری نمی‌کند.