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 not understand what in the cause of CSStorm. > > Please see this thread: > http://archives.postgresql.org/pgsql-hackers/2005-11/msg01547.php > (actually it's a single message AFAICT) > > This was applied on the 8.2dev code, so I'm surprised that 8.2dev > behaves the same as 8.1. > > Does your problem have any relationship to what's described there? > Probably it is related. There is no telling are a thing with the bad method of a lock and whether it is bad that the number of LRU buffers is simply small. > I also wondered whether the problem may be that the number of SLRU > buffers we use for subtrans is too low. But the number was increased > from the default 8 to 32 in 8.2dev as well. Maybe you could try > increasing that even further; say 128 and see if the problem is still > there. (src/include/access/subtrans.h, NUM_SUBTRANS_BUFFERS). 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. (but the value of WIPS fell about to 320 at intervals of 4 to 6 minutes.) If the number of SLRU buffers is too low, also in PostgreSQL8.1.4, if the number of buffers is increased I think that the same result is brought. (Although the buffer of CLOG or a multi-transaction also increases, I think that effect is small) Now, NUM_SLRU_BUFFERS is changed into 128 in PostgreSQL8.1.4 and is under measurement. regards, -------- Katsuhiko Okano okano katsuhiko _at_ oss ntt co jp ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
