Re: [PATCHES] default resource limits
От | Andrew Dunstan |
---|---|
Тема | Re: [PATCHES] default resource limits |
Дата | |
Msg-id | 2054.24.211.165.134.1135553745.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] default resource limits (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] default resource limits
Re: [PATCHES] default resource limits |
Список | pgsql-hackers |
Tom Lane said: > Andrew Dunstan <andrew@dunslane.net> writes: >> Maybe we need to split this into two pieces, given Tom's legitimate >> concern about semaphore use. How about we increase the allowed range >> for shared_buffers and max_fsm_pages, as proposed in my patch, and >> leave the max_connections issue on the table? I also wondered if >> instead of first setting max_connections and then >> shared_buffers/max_fsm_pages, we should try to scale them in synch >> somehow. > > The existing initdb code actually does try to scale them in sync to > some extent --- take a closer look at the arguments being passed during > the max-connections test phase. It won't choose a large > max_connections unless it can simultaneously get 5 times that many > shared_buffers. Yes, I know. What I meant was that we could try using one phase rather than two. But that's only one possible approach. > I think this probably needs to be more aggressive > though. In a > situation of limited SHMMAX it's probably more important to keep > shared_buffers as high as we can than to get a high max_connections. We > could think about increasing the 5x multiplier, adding Min and/or Max > limits, or some combination. > Yes. If we were to base it on the current maxima (1000/100), we could use a factor of 10, or if on the maxima I am now proposing (4000/250) a factor of 16. Something in that range is about right I suspect. cheers andrew
В списке pgsql-hackers по дате отправления: