"Vaughn, Adam (IMS)" <VaughnA@xxxxxxxxxx> wrote: > In the past 2 days we have been experiencing problems on our > production server with very long running commit statements which > seem to cause the entire instance to become blocked and > non-responsive. These are the log messages for the 2 commit > statements (these occurred inside of a 1 hour block) > > duration: 945599.193 ms execute S_2: COMMIT > duration: 967507.896 ms execute S_2: COMMIT > > Can anyone provide some assistance in how we should diagnose this > problem (tools) and some possible solutions for solving it? Look for prior posts by Greg Smith on this topic. (Or better yet, buy his book.) I don't believe anyone has a better handle on this issue than he does. That said, if you want emergency relief before you hear from him, and a safer place from which to start tuning toward your optimal settings based on the process he describes, I would make these changes: > bgwriter_delay 100 > bgwriter_lru_maxpages 100 > bgwriter_lru_multiplier 2.2 > shared_buffers 6GB bgwriter_delay 200 bgwriter_lru_maxpages 1000 bgwriter_lru_multiplier 4 shared_buffers 512MB These settings may not give you quite the same performance between lockups, but the lockups should be less frequent and severe, and may disappear entirely. You may not want to stay here, but it's probably a relatively safe place from which to start the process of incremental adjustments to find your best settings. The overall idea of these settings is to push more of the writes toward the disk soon enough to prevent a debilitating glut at fsync time. We're getting better at dealing with this in each release, so you may want to consider moving forward from 8.3 to help with it, too. -Kevin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
