Re: rapid degradation after postmaster restart
От | Joe Conway |
---|---|
Тема | Re: rapid degradation after postmaster restart |
Дата | |
Msg-id | 405330CD.4050304@joeconway.com обсуждение исходный текст |
Ответ на | Re: rapid degradation after postmaster restart (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: rapid degradation after postmaster restart
Re: rapid degradation after postmaster restart |
Список | pgsql-performance |
Tom Lane wrote: > Just to be clear on this: you have to restart the postmaster to bring > the time back down? Simply starting a fresh backend session doesn't do > it? Yes, a full postmaster restart is needed. It is a command line script that does the insert, so each one is a new backend. > Are you using particularly large values for shared_buffers or any of the > other resource parameters? I'll have to look at this again (I have to vpn in to the company lan which kills all my current connections) -- the server and application belong to another department at my employer. IIRC, shared buffers was reasonable, maybe 128MB. One thing that is worthy of note is that they are using pg_autovacuum and a very low vacuum_mem setting (1024). But I also believe that max_fsm_relations and max_fsm_pages have been bumped up from default (something like 10000 & 200000). I'll post the non-default postgresql.conf settings shortly. The extended tests discussed in the nearby post will take a bit more time to get. Thanks, Joe
В списке pgsql-performance по дате отправления: