odin-pg-bench

odin-pg-bench tool can be used to quickly ensure the database connection and hardware is ok. The tool can be executed on MN or Billing application node. The test includes two simple queries that are executed in a loop in a keep-alive connection in a single thread:

SELECT 1 – this test mostly benchmarks the network (or local) connection between the application and database and CPU responsiveness.
BEGIN; INSERT ... ; COMMIT – this test mostly benchmarks the DB storage WRITE and FDATASYNC (data flush on disk) operations but also depends on network and CPU.

The test does not modify the existing data in the database so it is safe to run it on the production installation.

To view the detailed information about the tool options, run the following command:

# odin-pg-bench --help
odin-pg-bench version 1.0
Usage: odin-pg-bench [options]
Options:
	-h, --help			show this help message and exit
	-v, --verbose			enable verbose mode
	Database credentials:
		--db-host=DB_HOST	hostname/IP (or '/tmp/' for local socket connection)
		--db-port=DB_PORT	database port (default 5432)
		--db-name=DB_NAME	database name
		--db-user=DB_USER	database username
		--db-pass=DB_PASS	database password
		--db-target=DB_TARGET	database target: ['oa', 'ba', 'oaci'], default is auto

How to interpret the results of odin-pg-bench tests:

The "SELECT 1" test score is less than 4000. It means that every SQL request from the application to the database will have some overhead and for some load patterns with heavy rate of SQL requests (like resource usage calculation, significant data migration/provisioning, daily billing) it can result in the increased processing time.
The "BEGIN; INSERT ...; COMMIT" test score is less than 1000. This test depends on two factors: slow network or "disk cache flush" rate on the storage under the database. The slow network case can be checked by the "SELECT 1" test but if "SELECT 1" score is more than 4000 selects/sec – the problem is most probably on the storage side. The "disk cache flush" storage characteristic is very important for databases which do COMMIT in the end of every transaction to guarantee complete data persistence. If the test score in less than 1000, it means that all the workloads with a high transaction rate (like resource usage calculation, significant data migration/provisioning, daily billing) can be slow.