Re: Wierd context-switching issue on Xeon

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: Wierd context-switching issue on Xeon
Дата
Msg-id 1083437446.25697.109.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Wierd context-switching issue on Xeon  (Robert Creager <Robert_Creager@LogicalChaos.org>)
Ответы Re: Wierd context-switching issue on Xeon  (Robert Creager <Robert_Creager@LogicalChaos.org>)
Список pgsql-performance
No, don't go away and be quiet. Keep testing, it may be that under
normal operation the context switching goes up but under the conditions
that you were seeing the high CS it may not be as bad.

As others have mentioned the real solution to this is to rewrite the
buffer management so that the lock isn't quite as coarse grained.

Dave
On Sat, 2004-05-01 at 00:03, Robert Creager wrote:
> When grilled further on (Thu, 29 Apr 2004 11:21:51 -0700),
> Josh Berkus <josh@agliodbs.com> confessed:
>
> > spins_per_delay was not beneficial.   Instead, try increasing them, one step
> > at a time:
> >
> > (take baseline measurement at 100)
> > 250
> > 500
> > 1000
> > 1500
> > 2000
> > 3000
> > 5000
> >
> > ... until you find an optimal level.   Then report the results to us!
> >
>
> Some results.  The patch mentioned is what Dave Cramer posted to the Performance
> list on 4/21.
>
> A Perl script monitored <vmstat 1> for 120 seconds and generated max and average
> values.  Unfortunately, I am not present on site, so I cannot physically change
> the device under test to increase the db load to where it hit about 10 days ago.
>  That will have to wait till the 'real' work week on Monday.
>
> Context switches -          avg    max
>
> Default 7.4.1 code :       10665  69470
> Default patch - 10 :       17297  21929
> patch at 100       :       26825  87073
> patch at 1000      :       37580 110849
>
> Now granted, the db isn't showing the CS swap problem in a bad way (at all), but
> should the numbers be trending the way they are with the patched code?  Or will
> these numbers potentially change dramatically when I can load up the db?
>
> And, presuming I can re-produce what I was seeing previously (200K CS/s), you
> folks want me to carry on with more testing of the patch and report the results?
>  Or just go away and be quiet...
>
> The information is provided from a HP Proliant DL380 G3 with 2x 2.4 GHZ Xenon's
> (with HT enabled) 2 GB ram, running 2.4.22-26mdkenterprise kernel, RAID
> controller w/128 Mb battery backed cache RAID 1 on 2x 15K RPM drives for WAL
> drive, RAID 0+1 on 4x 10K RPM drives for data.  The only job this box has is
> running this db.
>
> Cheers,
> Rob
--
Dave Cramer
519 939 0336
ICQ # 14675561


В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: planner/optimizer question
Следующее
От: Manfred Koizar
Дата:
Сообщение: Re: planner/optimizer question