Re: Checkpoint cost, looks like it is WAL/CRC
От | Tom Lane |
---|---|
Тема | Re: Checkpoint cost, looks like it is WAL/CRC |
Дата | |
Msg-id | 17262.1122073896@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Checkpoint cost, looks like it is WAL/CRC (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Checkpoint cost, looks like it is WAL/CRC
Re: Checkpoint cost, looks like it is WAL/CRC Re: Checkpoint cost, looks like it is WAL/CRC |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: >> Um, where are the test runs underlying this spreadsheet? I don't have a >> whole lot of confidence in looking at full-run average TPM numbers to >> discern whether transient dropoffs in TPM are significant or not. > Web in the form of: > http://khack.osdl.org/stp/#test_number#/ > Where #test_number# is: > Machine0, no patch: > 302904 > 302905 > 302906 > Machine0, patch: > 301901 > 302902 > 302903 > Machine2, no patch: > 302910 > 302911 > 302912 > Machine2, patch: > 301907 > 302908 > 302909 Hmm. Eyeballing the NOTPM trace for cases 302912 and 302909, it sure looks like the post-checkpoint performance recovery is *slower* in the latter. And why is 302902 visibly slower overall than 302905? I thought for a bit that you had gotten "patch" vs "no patch" backwards, but the oprofile results linked to these pages look right: XLogInsert takes significantly more time in the "no patch" cases. There's something awfully weird going on here. I was prepared to see no statistically-significant differences, but not multiple cases that seem to be going the "wrong direction". BTW, I'd like to look at 302906, but its [Details] link is broken. regards, tom lane
В списке pgsql-hackers по дате отправления: