Re: Simulating WAL on separate disks
От | Tom Lane |
---|---|
Тема | Re: Simulating WAL on separate disks |
Дата | |
Msg-id | 10388.1105403393@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Simulating WAL on separate disks ("Guy Rouillier" <guyr@masergy.com>) |
Список | pgsql-general |
"Guy Rouillier" <guyr@masergy.com> writes: > Thanks, Tom. This app has very high insert activity. What's the best > way to minimize the effect of WAL given that we don't have separate > disks to put it on in our test environment? There's not a lot you can do about it :-(. You can take some amount of comfort in the idea that the numbers you get should be a lower bound on the performance with WAL on a separate disk, though. To some extent you are looking at this backwards. In a high-update situation it is WAL that is the bottleneck, by design (ie that is the way it should be). Rather than "minimizing the effect of WAL" what you want to minimize is the effects of having to move the disk arms away from the WAL file to write data files. Thinking along that line, you want to try to avoid doing data file writes except at checkpoints, and spread out checkpoints as far as possible. So bump up the checkpoint spacing parameters, and maybe increase shared_buffers more than you normally would, and if you are using 8.0 then disable the bgwriter. This will result in bigger and uglier spikes at checkpoints than the real environment, but perhaps you can discount those in your testing. Obviously this is just a crude approximation but it's about the best you are going to do, given that the disk setup is fundamentally different from what you intend to do in production. regards, tom lane
В списке pgsql-general по дате отправления: