Re: High cpu usage after many inserts

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: High cpu usage after many inserts
Дата
Msg-id dcc563d10902230735s3bc01f6fi2a671b4ef71cc620@mail.gmail.com
обсуждение исходный текст
Ответ на Re: High cpu usage after many inserts  (Jordan Tomkinson <jordan@moodle.com>)
Ответы Re: High cpu usage after many inserts  (Jordan Tomkinson <jordan@moodle.com>)
Re: High cpu usage after many inserts  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-general
On Mon, Feb 23, 2009 at 1:29 AM, Jordan Tomkinson <jordan@moodle.com> wrote:
>
> On Mon, Feb 23, 2009 at 5:20 PM, Scott Marlowe <scott.marlowe@gmail.com>
> wrote:
>>
>> On Mon, Feb 23, 2009 at 12:42 AM, Jordan Tomkinson <jordan@moodle.com>
>> wrote:
>> >
>> >
>> > On Mon, Feb 23, 2009 at 4:29 PM, Scott Marlowe <scott.marlowe@gmail.com>
>> > wrote:
>> >>
>> >> Oh yeah, what OS is this?  Version and all that.
>> >
>> > I should probably clarify that the high cpu only exists while the jmeter
>> > tests are running, once the tests are finished the cpu returns to 0%
>> > (this
>> > isnt a production server yet, so no other queries other than my tests)
>> > I have not yet tried other SQL queries to see if they are affected, i
>> > suspect it may only be related to the two forum tables the test focuses
>> > on
>> > but I may be incorrect - the database is filling up with data again now
>> > so I
>> > can test this tomorrow.
>>
>> Sorry, I had gotten the impression the CPU usage continued after the
>> test.  That it's 100% during the test is quite understandable.  So
>> does it start lower than 4x100% Then climb during the tests?  Is the
>> throughput dropping off over time?
>
> As per the spreadsheet
> (http://spreadsheets.google.com/pub?key=pu_k0R6vNvOVP26TRZdtdYw) CPU usage
> is around 50% and starts climbing over 3 hours until we have just under
> 10,000 rows of data then stays at 99% for the duration of all future tests.
> Once the rows are removed the tests start back down at 50% usage again.

Oh, ok. well that's pretty normal as the indexes grow large enough to
not fit in cache, then not fit in memory, etc...  Are you noticing a
sharp dropoff in performance?

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Connection refused (0x0000274D/10061)
Следующее
От: Angelo Astorga
Дата:
Сообщение: Serverlog postgresql 8.1.11