On 3/1/07, Jeff Frost <jeff@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 1 Mar 2007, Alex Deucher wrote: > On 3/1/07, Jeff Frost <jeff@xxxxxxxxxxxxxxxxxxxxxx> wrote: >> On Thu, 1 Mar 2007, Alex Deucher wrote: >> >> >> Vacuum? Analayze? default_statistics_target? How many shared_buffers? >> >> effective_cache_size? work_mem? >> >> >> > >> > I'm running the autovacuum process on the 8.1 server. vacuuming on >> > the old server was done manually. >> > >> > default_statistics_target and effective_cache_size are set to the the >> > defaults on both. >> > >> > postgres 7.4 server: >> > # - Memory - >> > shared_buffers = 82000 # 1000 min 16, at least >> > max_connections*2, 8KB each >> > sort_mem = 8000 # 1024 min 64, size in KB >> > vacuum_mem = 32000 # 8192 min 1024, size in KB >> > # - Free Space Map - >> > #max_fsm_pages = 20000 # min max_fsm_relations*16, 6 bytes each >> > #max_fsm_relations = 1000 # min 100, ~50 bytes each >> > # - Kernel Resource Usage - >> > #max_files_per_process = 1000 # min 25 >> > >> > postgres 8.1 server: >> > # - Memory - >> > shared_buffers = 100000 # min 16 or max_connections*2, >> 8KB >> > each >> > temp_buffers = 2000 #1000 # min 100, 8KB each >> > max_prepared_transactions = 100 #5 # can be 0 or more >> > # note: increasing max_prepared_transactions costs ~600 bytes of shared >> > memory >> > # per transaction slot, plus lock space (see max_locks_per_transaction). >> > work_mem = 10000 #1024 # min 64, size in KB >> > maintenance_work_mem = 524288 #16384 # min 1024, size in KB >> > #max_stack_depth = 2048 # min 100, size in KB >> > >> > I've also tried using the same settings from the old server on the new >> > one; same performance issues. >> > >> >> If this is a linux system, could you give us the output of the 'free' >> command? > > total used free shared buffers cached > Mem: 8059852 8042868 16984 0 228 7888648 > -/+ buffers/cache: 153992 7905860 > Swap: 15631224 2164 15629060 So, I would set effective_cache_size = 988232 (7905860/8). > >> Postgresql might be choosing a bad plan because your effective_cache_size >> is >> way off (it's the default now right?). Also, what was the block read/write > > yes it's set to the default. > >> speed of the SAN from your bonnie tests? Probably want to tune >> random_page_cost as well if it's also at the default. >> > > ------Sequential Output------ --Sequential Input- > --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec > %CP > luna12-san 16000M 58896 91 62931 9 35870 5 54869 82 145504 13 397.7 > 0 > So, you're getting 62MB/s writes and 145MB/s reads. Just FYI, that write speed is about the same as my single SATA drive write speed on my workstation, so not that great. The read speed is decent, though and with that sort of read performance, you might want to lower random_page_cost to something like 2.5 or 2 so the planner will tend to prefer index scans.
Right, but the old box was getting ~45MBps on both reads and writes, so it's an improvement for me :) Thanks for the advice, I'll let you know how it goes. Alex
