Re: [HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-08-04 Thread Katsuhiko Okano
is a difficult point although it is important. Katsuhiko Okano okano katsuhiko _at_ oss ntt co jp ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-07-31 Thread Katsuhiko Okano
Hi,All. Since the cause was found and the provisional patch was made and solved about the CSStorm problem in previous mails, it reports. Subject: [HACKERS] poor performance with Context Switch Storm at TPC-W. Date: Tue, 11 Jul 2006 20:09:24 +0900 From: Katsuhiko Okano [EMAIL PROTECTED

Re: [HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-07-31 Thread Katsuhiko Okano
Katsuhiko Okano wrote: Since the cause was found and the provisional patch was made and solved about the CSStorm problem in previous mails, it reports. (snip) (A) The algorithm which replaces a buffer is bad. A time stamp does not become new until swapout completes the swapout page

Re: CSStorm occurred again by postgreSQL8.2. (Re: [HACKERS] poor

2006-07-20 Thread Katsuhiko Okano
/lab_activities/kernel_testing/osdl_database_test_suite/osdl_dbt-1/ Thank you for the information. I'll try it. Regards, Katsuhiko Okano okano katsuhiko _at_ oss ntt co jp ---(end of broadcast)--- TIP 5: don't forget to increase your free space map

Re: [HACKERS] poor performance with Context Switch Storm at TPC-W.

2006-07-20 Thread Katsuhiko Okano
Jim C. Nasby wrote: If you haven't changed checkpoint timeout, this drop-off every 4-6 minutes indicates that you need to make the bgwriter more aggressive. I'll say to a customer when proposing and explaining. Thank you for the information. Regards, Katsuhiko Okano okano katsuhiko

Re: CSStorm occurred again by postgreSQL8.2. (Re: [HACKERS] poor performance with Context Switch Storm at TPC-W.)

2006-07-19 Thread Katsuhiko Okano
Tom Lane [EMAIL PROTECTED] wrote: Katsuhiko Okano [EMAIL PROTECTED] writes: It does not solve, even if it increases the number of NUM_SUBTRANS_BUFFERS. The problem was only postponed. Can you provide a reproducible test case for this? Seven machines are required in order to perform

CSStorm occurred again by postgreSQL8.2. (Re: [HACKERS] poor performance with Context Switch Storm at TPC-W.)

2006-07-18 Thread Katsuhiko Okano
Katsuhiko Okano wrote: By PostgreSQL8.2, NUM_SUBTRANS_BUFFERS was changed into 128 and recompile and measured again. NOT occurrence of CSStorm. The value of WIPS was about 400. measured again. not occurrence when measured for 30 minutes. but occurrence when measured for 3 hours, and 1 hour

Re: [HACKERS] poor performance with Context Switch Storm at TPC-W.

2006-07-13 Thread Katsuhiko Okano
Hi. Alvaro Herrera wrote: Katsuhiko Okano wrote: I suspected conflict of BufMappingLock. but, collected results are seen, occurrence of CSStorm and the increase of BufMappingLock counts seem not to correspond. Instead, SubtransControlLock and SubTrans were increasing. I do

[HACKERS] poor performance with Context Switch Storm at TPC-W.

2006-07-11 Thread Katsuhiko Okano
. it seems to generate the subtransaction for every transaction. How much is a possibility that the LWLock to a subtransaction cause CSStorm? best regards. Katsuhiko Okano okano katsuhiko _at_ oss ntt co jp ---(end of broadcast)--- TIP 5: don't

Re: [HACKERS] poor performance with Context Switch Storm at TPC-W.

2006-07-11 Thread Katsuhiko Okano
is a value smaller than the case where H/T is ON. I think that it is because the performance of CPU fell.) Regards Katsuhiko Okano okano katsuhiko _at_ oss ntt co jp ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send