Re: Performance under contention
От | Ivan Voras |
---|---|
Тема | Re: Performance under contention |
Дата | |
Msg-id | iclle6$jdq$1@dough.gmane.org обсуждение исходный текст |
Ответ на | Re: Performance under contention ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-performance |
On 11/22/10 18:47, Kevin Grittner wrote: > Ivan Voras<ivoras@freebsd.org> wrote: > >> It looks like a hack > > Not to everyone. In the referenced section, Hellerstein, > Stonebraker and Hamilton say: > > "any good multi-user system has an admission control policy" > > In the case of PostgreSQL I understand the counter-argument, > although I'm inclined to think that it's prudent for a product to > limit resource usage to a level at which it can still function well, > even if there's an external solution which can also work, should > people use it correctly. It seems likely that a mature admission > control policy could do a better job of managing some resources than > an external product could. I didn't think it would be that useful but yesterday I did some (unrelated) testing with MySQL and it looks like its configuration parameter "thread_concurrency" does something to that effect. Initially I thought it is equivalent to PostgreSQL's max_connections but no, connections can grow (MySQL spawns a thread per connection by default) but the actual concurrency is limited in some way by this parameter. The comment for the parameter says "# Try number of CPU's*2 for thread_concurrency" but obviously it would depend a lot on the real-world load.
В списке pgsql-performance по дате отправления: