Re: Queries seldomly take >4s while normally take <1ms?
От | Christian Hammers |
---|---|
Тема | Re: Queries seldomly take >4s while normally take <1ms? |
Дата | |
Msg-id | 20130409190712.17409452@sys-251.netcologne.de обсуждение исходный текст |
Ответ на | Re: Queries seldomly take >4s while normally take <1ms? (Kevin Grittner <kgrittn@ymail.com>) |
Список | pgsql-general |
On Tue, 9 Apr 2013 07:25:16 -0700 (PDT) Kevin Grittner <kgrittn@ymail.com> wrote: > Christian Hammers <ch@lathspell.de> wrote: > > > 9.2.3 > > You really need to think about 9.2.4 Real Soon Now; there's a > security fix that you probably should not wait on. Is scheduled (no access from outside to that network segment at least) > > max_connections = 1000 # (change requires restart) > > shared_buffers = 20GB # min 128kB > > Those are both potential causes. For max_connections, see this: > > http://wiki.postgresql.org/wiki/Number_Of_Database_Connections > > Maybe you happened to have enough users hit the enter key at the > same moment to cause a process holding a lock to be starved of > cycles or something similar. The application connects permanently with a fixed number of only 20 connections. > One problem with a large shared_buffers setting is that PostgreSQL > can accumulate a very large number of dirty pages and flush them to > the OS all at once. This can overwhelm the storage system and > cause exactly the kind of symptoms you're seeing. I have pretty big changes during early night hours on the master and then almost only read-only accesses during the day. As checkpoint_timeout is at 5min, there should not be any significant amount of dirty pages during daytime, right? Where would I verity this, with pg_stats_bgwriter.buffers_checkpoint and the Linux I/O graphs? bye, -christian-
В списке pgsql-general по дате отправления: