rails-pg-extras is to provide powerful insights into the PostgreSQL database for Ruby on Rails apps that are not using the Heroku PostgreSQL plugin.
Included rake tasks and Ruby methods can be used to obtain information about a Postgres instance, that may be useful when analyzing performance issues. This includes information about locks, index usage, buffer cache hit ratios and vacuum statistics. Ruby API enables developers to easily integrate the tool into e.g. automatic monitoring tasks.
Installation
You can install it as a gem:
1
$ gem install rails-pg-extras
or add it into a Gemfile (Bundler):
1 2 3 4 5
# Gemfile
# pawurb/rails-pg-extras: Rails PostgreSQL database performance insights. Locks, index usage, buffer cache hit ratios, vacuum stats and more. # https://github.com/pawurb/rails-pg-extras gem 'rails-pg-extras', '2.0.0'
Then, run bundle install.
1
$ bundle install
Configuration
Some of the queries (e.g., calls and outliers) require pg_stat_statements extension enabled.
You can check if it is enabled in your database by running:
1
RailsPGExtras.extensions
You should see the similar line in the output:
1
| pg_stat_statements | 1.7 | 1.7 | track execution statistics of all SQL statements executed |
Usages
Each command can be used as a rake task, or a directly from the Ruby code.
1
rake pg_extras:cache_hit
1 2 3 4 5 6 7 8 9
RailsPGExtras.cache_hit +----------------+------------------------+ | Index and table hit rate | +----------------+------------------------+ | name | ratio | +----------------+------------------------+ | index hit rate | 0.97796610169491525424 | | table hit rate | 0.96724294813466787989 | +----------------+------------------------+
By default the ASCII table is displayed, to change to format you need to specify the in_format parameter ([:display_table, :hash, :array, :raw] options are available):
1 2 3 4 5 6 7 8 9 10 11
RailsPGExtras.cache_hit(in_format::hash) =>
[{"name"=>"index hit rate", "ratio"=>"0.97796610169491525424"}, {"name"=>"table hit rate", "ratio"=>"0.96724294813466787989"}]
RailsPGExtras.cache_hit(in_format::array) =>
[["index hit rate", "0.97796610169491525424"], ["table hit rate", "0.96724294813466787989"]]
name | ratio ----------------+------------------------ index hit rate | 0.99957765013541945832 table hit rate | 1.00 (2 rows)
This command provides information on the efficiency of the buffer cache, for both index reads (index hit rate) as well as table reads (table hit rate). A low buffer cache hit ratio can be a sign that the Postgres instance is too small for the workload.
This method displays values for selected PostgreSQL settings. You can compare them with settings recommended by PGTune and tweak values to improve performance.
This command provides information on the efficiency of indexes, represented as what percentage of total scans were index scans. A low percentage can indicate under indexing, or wrong data being indexed.
This command displays queries that have taken out an exclusive lock on a relation. Exclusive locks typically prevent other operations on that relation from taking place, and can be a cause of “hung” queries that are waiting for a lock to be granted.
all_locks
1
RailsPGExtras.all_locks
1
$ rake pg_extras:all_locks
This command displays all the current locks, regardless of their type.
This command displays statements, obtained from pg_stat_statements, ordered by the amount of time to execute in aggregate. This includes the statement itself, the total execution time for that statement, the proportion of total execution time for all statements that statement has taken up, the number of times that statement has been called, and the amount of time that statement spent on synchronous I/O (reading/writing from the file system).
Typically, an efficient query will have an appropriate ratio of calls to total execution time, with as little time spent on I/O as possible. Queries that have a high total execution time but low call count should be investigated to improve their performance. Queries that have a high proportion of execution time being spent on synchronous I/O should also be investigated.
This command displays statements that are currently holding locks that other statements are waiting to be released. This can be used in conjunction with pg:locks to determine which statements need to be terminated in order to resolve lock contention.
total_index_size
1
RailsPGExtras.total_index_size
1 2 3 4 5 6
$ rake pg_extras:total_index_size
size ------- 28194 MB (1 row)
This command displays the total size of all indexes on the database, in MB. It is calculated by taking the number of pages (reported in relpages) and multiplying it by the page size (8192 bytes).
This command displays the size of each each index in the database, in MB. It is calculated by taking the number of pages (reported in relpages) and multiplying it by the page size (8192 bytes).
table_size
1
RailsPGExtras.table_size
1 2 3 4 5 6 7 8 9 10
$ rake pg_extras:table_size
name | size ---------------------------------------------------------------+--------- learning_coaches | 196 MB states | 145 MB grade_levels | 111 MB charities_customers | 73 MB charities | 66 MB (truncated results for brevity)
This command displays the size of each table and materialized view in the database, in MB. It is calculated by using the system administration function pg_table_size(), which includes the size of the main data fork, free space map, visibility map and TOAST data.
This command displays the total size of indexes for each table and materialized view, in MB. It is calculated by using the system administration function pg_indexes_size().
total_table_size
1
RailsPGExtras.total_table_size
1 2 3 4 5 6 7 8 9 10
$ rake pg_extras:total_table_size
name | size ---------------------------------------------------------------+--------- learning_coaches | 349 MB states | 270 MB charities_customers | 166 MB grade_levels | 122 MB charities | 82 MB (truncated results for brevity)
This command displays the total size of each table and materialized view in the database, in MB. It is calculated by using the system administration function pg_total_relation_size(), which includes table size, total index size and TOAST data.
This command displays indexes that have < 50 scans recorded against them, and are greater than 5 pages in size, ordered by size relative to the number of index scans. This command is generally useful for eliminating indexes that are unused, which can impact write performance, as well as read performance should they occupy space in memory.
This command displays indexes that contain NULL values. A high ratio of NULL values means that using a partial index excluding them will be beneficial in case they are not used for searching.
This command displays the number of sequential scans recorded against all tables, descending by count of sequential scans. Tables that have very high numbers of sequential scans may be under-indexed, and it may be worth investigating queries that read from these tables.
pid | duration | query -------+-----------------+--------------------------------------------------------------------------------------- 19578 | 02:29:11.200129 | EXPLAIN SELECT "students".* FROM "students" WHERE "students"."id" = 1450645 LIMIT 1 19465 | 02:26:05.542653 | EXPLAIN SELECT "students".* FROM "students" WHERE "students"."id" = 1889881 LIMIT 1 19632 | 02:24:46.962818 | EXPLAIN SELECT "students".* FROM "students" WHERE "students"."id" = 1581884 LIMIT 1 (truncated results for brevity)
This command displays currently running queries, that have been running for longer than 5 minutes, descending by duration. Very long running queries can be a source of multiple issues, such as preventing DDL statements completing or vacuum being unable to update relfrozenxid.
This command displays an estimated count of rows per table, descending by estimated count. The estimated count is derived from n_live_tup, which is updated by vacuum operations. Due to the way n_live_tup is populated, sparse vs. dense pages can result in estimations that are significantly out from the real count of rows.
bloat
1
RailsPGExtras.bloat
1 2 3 4 5 6 7 8 9 10
$ rake pg_extras:bloat
type | schemaname | object_name | bloat | waste -------+------------+-------------------------------+-------+---------- table | public | bloated_table | 1.1 | 98 MB table | public | other_bloated_table | 1.1 | 58 MB index | public | bloated_table::bloated_index | 3.7 | 34 MB table | public | clean_table | 0.2 | 3808 kB table | public | other_clean_table | 0.3 | 1576 kB (truncated results for brevity)
This command displays an estimation of table “bloat” – space allocated to a relation that is full of dead tuples, that has yet to be reclaimed. Tables that have a high bloat ratio, typically 10 or greater, should be investigated to see if vacuuming is aggressive enough, and can be a sign of high table churn.
This command displays statistics related to vacuum operations for each table, including an estimation of dead rows, last autovacuum and the current autovacuum threshold. This command can be useful when determining if current vacuum thresholds require adjustments, and to determine when the table was last vacuumed.
kill_all
1
RailsPGExtras.kill_all
This commands kills all the currently active connections to the database. It can be useful as a last resort when your database is stuck in a deadlock.
This command shows the relations buffered in database share buffer, ordered by percentage taken. It also shows that how much of the whole relation is buffered.