Stéphane Schildknecht wrote: > I wonder vacuum verbose would tell me if fsm parameters were not too > badly configured, but I can't get the 4 last lines of the output... Why not? > Whats's more, I wonder what we could monitor to get some explanation of > the recent time increase, and then have a quite-sure way of configuring > the server. sar or iostat output would be a good start, to determine if it's waiting for I/O or what. > I have to say the database is hosted, accessed in production on a 24/7 > basis and then every change in configuration has to be scheduled. > > Some more information you may ask: > chackpoint_segments : 32 > checkpoint_timeout : 180 > checkpoint_warning : 30 > wal_buffers : 64 > maintenance_work_mem : 65536 > max_fsm_pages : 400000 > max_fsm_relations : 1000 > shared_buffers : 50000 > temp_bufers : 1000 > > We also have 4Gb RAM. > > Isn't checkpoint_segments too low as all files in pg_xlogs seem to be > recycled within a few minutes. (In fact among the 60 files, at least 30 > have been modified during the few minutes of that particular vacuum). Increasing checkpoint_segments seems like a good idea then. You should increase checkpoint_timeout as well, 180 is just 3 minutes. How much concurrent activity is there in the database? 30 pg_xlog files equals 512 MB of WAL; that's quite a lot. Have you changed the vacuum cost delay settings from the defaults? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(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
