Hi all hackers again!
Since i had got this topic there many test was done by our team and many papers was seen. And then I noticed that os_page_replacement_algorithm with CLOCK and others features
might * interfere / overlap * with/on postgres_shared_buffers.
I also think there are positive correlation between the write load and the pressure on file cache in case with large shared buffers.
I assumed if i would set smaller size of buffers that cache could work more effective because files pages has more probability to be placed in the right place in memory.
After all we set shared buffers down to 16GB ( instead of 64GB ) and we got new pictures. Now we have alive raid! 16GB shared buffers => and we won 80 GB of server memory! It is good result. But upto 70GB of memory are still unused // instead of 150. In future I think we can set shared buffers more close to zero or to 100% of all available memory.
Many thanks Oleg Bartunov and Fedor Sigaev for their tests and some interesting assumptions.
--
Mikhail
>Hi all
>There is something wrong and ugly.
>
>1)
>Intel 32 core = 2*8 *2threads
>
>Linux avi-sql09 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
>
>PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit
>shared_buffers 64GB / constant hit rate - 99,18
>max_connections 160 / with pgbouncer pools there could not be more than 120 connections at all
>work_mem 32M
>checkpoint 1h 1.0
>swap off
>numa off, interleaving on
>
>24*128GB HDD (RAID10) with 2GB bbu (1,5w+0,5r)
>
>2)
>free -g
> total used free shared buffers cached
>Mem: 378 250 128 0 0 229
>-/+ buffers/cache: 20 357
>
>and
>! disks usage 100% (free 128GB! WHY?)
>
>disk throughput - up-to 30MB/s (24r+6w)
>io - up-to 2,5-3K/s (0,5w + 2-2,5r)
>
>
>typical work load - pk-index-scans
>