Re: Impact of checkpoint_segments under continual load conditions
От | Christopher Petrilli |
---|---|
Тема | Re: Impact of checkpoint_segments under continual load conditions |
Дата | |
Msg-id | 59d991c405071811457ccdd3f1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Impact of checkpoint_segments under continual load conditions (Vivek Khera <vivek@khera.org>) |
Ответы |
Re: Impact of checkpoint_segments under continual load conditions
|
Список | pgsql-performance |
On 7/18/05, Vivek Khera <vivek@khera.org> wrote: > > On Jul 17, 2005, at 1:08 PM, Christopher Petrilli wrote: > > > Normally, checkpoint_segments can help absorb some of that, but my > > experience is that if I crank the number up, it simply delays the > > impact, and when it occurs, it takes a VERY long time (minutes) to > > clear. > > There comes a point where your only recourse is to throw hardware at > the problem. I would suspect that getting faster disks and splitting > the checkpoint log to its own RAID partition would help you here. > Adding more RAM while you're at it always does wonders for me :-) My concern is less with absolute performance, than with the nosedive it goes into. I published some of my earlier findings and comparisons on my blog, but there's a graph here: http://blog.amber.org/diagrams/comparison_mysql_pgsql.png Notice the VERY steep drop off. I'm still trying to get rid of it, but honestly, am not smart enough to know where it's originating. I have no desire to ever use MySQL, but it is a reference point, and since I don't particularly need transactional integrity, a valid comparison. Chris -- | Christopher Petrilli | petrilli@gmail.com
В списке pgsql-performance по дате отправления: