| From: | Matthew Kelly <mkelly(at)tripadvisor(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Jiří Hlinka <jiri(dot)hlinka(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Monitoring and insight into NOTIFY queue |
| Date: | 2016-06-08 18:05:36 |
| Message-ID: | 1B77A079-857D-46CD-956F-D50257AFFB51@tripadvisor.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
I just ran into monitoring this and came up with the following 1 liner for monitoring this in releases < 9.6 through the SQL layer. Once you are at 9.6 Jeff Janes solution is correct.
It does make the assumption that the queue size is 8GB. It can misjudge the queue usage by up to one file segment size. If you are using this for nagios monitoring, however, that error just disappears as a couple thousandths of a percent of noise.
SELECT sum((pg_stat_file('pg_notify/' || pg_ls_dir)).size)/(8 * pow(1024, 3)) * 100 as notify_queue_usage_percent FROM pg_ls_dir('pg_notify');
| From | Date | Subject | |
|---|---|---|---|
| Next Message | MOLINA BRAVO FELIPE DE JESUS | 2016-06-08 18:38:19 | Re: Slow join over three tables |
| Previous Message | Ben Buckman | 2016-06-08 17:57:11 | Using a VIEW as a temporary mechanism for renaming a table |