Hello, If I get you right: Latest checkpoint's NextMultiXactId: 2075246000 Latest checkpoint's oldestMultiXid: 2019511697 Number of members files: 10820 Size pg_multixact/members/ (bytes) (2.7Gb): 2887696384 Pages in file: 32 Members on page: 2045 Number of members (32*2045*10820): 708060800 Members per multixact (2075246000 - 2019511697)/708060800: 12,70421916 Multixact size (bytes) (2887696384/708060800): 4,078316981 - It's a lot? Kind regards, Vladimir Pavlov -----Original Message----- From: Alvaro Herrera [mailto:alvherre@xxxxxxxxxxxxxxx] Sent: Thursday, March 31, 2016 12:17 AM To: Pavlov Vladimir Cc: 'Adrian Klaver'; 'pgsql-general@xxxxxxxxxxxxxx' Subject: Re: Multixacts wraparound monitoring Pavlov, Vladimir wrote: > Yes, VACUUM helps to solve the problem and the WARNING gone away. > But, the problem is that the VACUUM for the entire database (2.4T) takes over 7 hours, and it has to run every 15-20 hours (about 300 millions transactions), otherwise: > ERROR: multixact "members" limit exceeded - and server stops working. > The question is how to start the VACUUM at least once in three days. You should have *started* the thread with this information. My bet is that your multixacts are overly large and that's causing excessive vacuuming work; this is likely due to bug #8470 (which is fixed in 9.5 and master but not 9.3 and 9.4) and my bet is that you would very much benefit from the patch I posted in https://www.postgresql.org/message-id/20150620043650.GX133018%40postgresql.org I didn't actually verify this; you could with some arithmetic on the deltas in multixact counters in pg_controldata output that you could take periodically. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
