Re: SLRU statistics
От | Alvaro Herrera |
---|---|
Тема | Re: SLRU statistics |
Дата | |
Msg-id | 20200120180136.GA28405@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: SLRU statistics (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: SLRU statistics
|
Список | pgsql-hackers |
On 2020-Jan-20, Tomas Vondra wrote: > On Mon, Jan 20, 2020 at 01:04:33AM +0000, tsunakawa.takay@fujitsu.com wrote: > > From: Tomas Vondra <tomas.vondra@2ndquadrant.com> > > > One of the stats I occasionally wanted to know are stats for the SLRU > > > stats (we have couple of those - clog, subtrans, ...). So here is a WIP > > > version of a patch adding that. > > > > How can users take advantage of this information? I think we also need > > the ability to set the size of SLRU buffers. (I want to be freed from > > the concern about the buffer shortage by setting the buffer size to its > > maximum. For example, CLOG would be only 1 GB.) > > You're right the users can't really take advantage of this - my primary > motivation was providing a feedback for devs, benchmarking etc. That > might have been done with DEBUG messages or something, but this seems > more convenient. I think the stats are definitely needed if we keep the current code. I've researched some specific problems in this code, such as the need for more subtrans SLRU buffers; IIRC it was pretty painful to figure out what the problem was without counters, and it'd have been trivial with them. > I think it's unclear how desirable / necessary it is to allow users to > tweak those caches. I don't think we should have a GUC for everything, > but maybe there's some sort of heuristics to determine the size. The > assumption is we actually find practical workloads where the size of > these SLRUs is a performance issue. I expect we'll eventually realize the need for changes in this area. Either configurability in the buffer pool sizes, or moving them to be part of shared_buffers (IIRC Thomas Munro had a patch for this.) Example: SLRUs like pg_commit and pg_subtrans have higher buffer consumption as the range of open transactions increases; for many users this is not a concern and they can live with the default values. (I think when pg_commit (née pg_clog) buffers were increased, we should have increased pg_subtrans buffers to match.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: