using dbt2 postgresql 8.4 - rampup time issue

From: MUHAMMAD ASIF <anaeem(dot)it(at)hotmail(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Cc: <markwkm(at)gmail(dot)com>
Subject: using dbt2 postgresql 8.4 - rampup time issue
Date: 2010-07-02 14:38:51
Message-ID: BAY154-w26697D09A40EB62B604AF6FFCE0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


Hi,

We are using dbt2 to check performance of postgresql 8.4 on Linux64 machine. When we increase "TERMINALS PER WAREHOUSE" TPM value increase rapidly but rampup time increase too , dbt2 estimated rampup time calculation do not work properly that’s why it run the test for wrong duration i.e.

1.
Settings :
DATABASE CONNECTIONS: 50
TERMINALS PER WAREHOUSE: 10
SCALE FACTOR (WAREHOUSES): 200
DURATION OF TEST (in sec): 7200
Result :
Response Time (s)
Transaction % Average : 90th % Total Rollbacks %
------------ ----- --------------------- ----------- --------------- -----
Delivery 3.96 0.285 : 0.023 26883 0 0.00
New Order 45.26 0.360 : 0.010 307335 3082 1.01
Order Status 3.98 0.238 : 0.003 27059 0 0.00
Payment 42.82 0.233 : 0.003 290802 0 0.00
Stock Level 3.97 0.245 : 0.002 26970 0 0.00
------------ ----- --------------------- ----------- --------------- -----

2508.36 new-order transactions per minute (NOTPM)
120.1 minute duration
0 total unknown errors
2000 second(s) ramping up

2.
Settings :
DATABASE CONNECTIONS: 50
TERMINALS PER WAREHOUSE: 40
SCALE FACTOR (WAREHOUSES): 200
DURATION OF TEST (in sec): 7200
Result :
Response Time (s)
Transaction % Average : 90th % Total Rollbacks %
------------ ----- --------------------- ----------- --------------- -----
Delivery 3.95 8.123 : 4.605 43672 0 0.00
New Order 45.19 12.205 : 2.563 499356 4933 1.00
Order Status 4.00 7.385 : 3.314 44175 0 0.00
Payment 42.89 7.221 : 1.920 473912 0 0.00
Stock Level 3.97 7.093 : 1.887 43868 0 0.00
------------ ----- --------------------- ----------- --------------- -----

7009.40 new-order transactions per minute (NOTPM)
69.8 minute duration
0 total unknown errors
8016 second(s) ramping up
3.
Settings :
DATABASE CONNECTIONS: 50
TERMINALS PER WAREHOUSE: 40
SCALE FACTOR (WAREHOUSES): 200
DURATION OF TEST (in sec): 7200
Result :
Response Time (s)
Transaction % Average : 90th % Total Rollbacks %
------------ ----- --------------------- ----------- --------------- -----
Delivery 3.98 9.095 : 16.103 15234 0 0.00
New Order 45.33 7.896 : 14.794 173539 1661 0.97
Order Status 3.96 8.165 : 13.989 15156 0 0.00
Payment 42.76 7.295 : 12.470 163726 0 0.00
Stock Level 3.97 7.198 : 12.520 15198 0 0.00
------------ ----- --------------------- ----------- --------------- -----

10432.09 new-order transactions per minute (NOTPM)
16.3 minute duration
0 total unknown errors
11227 second(s) ramping up

These results show that dbt2 test actually did not run for 2 hours but it start varying with the increase of "TERMINALS PER WAREHOUSE" value i.e. 1st Run ( 120.1 minute duration ), 2nd Run (69.8 minute duration) and 3rd Run (16.3 minute duration).

To fix and sync with the rampup time, I have made a minor change in the dbt2-run-workload script i.e.

--- dbt2-run-workload 2010-07-02 08:18:06.000000000 -0400
+++ dbt2-run-workload 2010-07-02 08:20:11.000000000 -0400
@@ -625,7 +625,11 @@
done

echo -n "estimated rampup time: "
-do_sleep $SLEEP_RAMPUP
+#do_sleep $SLEEP_RAMPUP
+while ! grep START ${DRIVER_OUTPUT_DIR}/*/mix.log ; do
+ sleep 1
+done
+date
echo "estimated rampup time has elapsed"

# Clear the readprofile data after the driver ramps up.

What is rempup time ? And what do you think about the patch?. Can you please guide me?. Thanks.

Best Regards,
Asif Naeem


_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Matthew Wakeling 2010-07-02 14:50:55 Re: Highly Efficient Custom Sorting
Previous Message Eliot Gable 2010-07-02 13:59:44 Re: Highly Efficient Custom Sorting