Re: High update activity, PostgreSQL vs BigDBMS
| От | Guy Rouillier |
|---|---|
| Тема | Re: High update activity, PostgreSQL vs BigDBMS |
| Дата | |
| Msg-id | 45A077FB.3010802@burntmail.com обсуждение исходный текст |
| Ответ на | Re: High update activity, PostgreSQL vs BigDBMS (Dave Cramer <pg@fastcrypt.com>) |
| Ответы |
Re: High update activity, PostgreSQL vs BigDBMS
Re: High update activity, PostgreSQL vs BigDBMS |
| Список | pgsql-performance |
Dave Cramer wrote: >> >> The box has 3 GB of memory. I would think that BigDBMS would be hurt >> by this more than PG. Here are the settings I've modified in >> postgresql.conf: > > As I said you need to set shared_buffers to at least 750MB this is the > starting point, it can actually go higher. Additionally effective cache > should be set to 2.25 G turning fsync is not a real world situation. > Additional tuning of file systems can provide some gain, however as > Craig pointed out some queries may need to be tweaked. Dave, thanks for the hard numbers, I'll try them. I agree turning fsync off is not a production option. In another reply to my original posting, Alex mentioned that BigDBMS gets an advantage from its async IO. So simply as a test, I turned fsync off in an attempt to open wide all the pipes. Regarding shared_buffers=750MB, the last discussions I remember on this subject said that anything over 10,000 (8K buffers = 80 MB) had unproven benefits. So I'm surprised to see such a large value suggested. I'll certainly give it a try and see what happens. >> >> autovacuum=on >> stats_row_level = on >> max_connections = 10 >> listen_addresses = 'db01,localhost' >> shared_buffers = 128MB >> work_mem = 16MB >> maintenance_work_mem = 64MB >> temp_buffers = 32MB >> max_fsm_pages = 204800 >> checkpoint_segments = 30 >> redirect_stderr = on >> log_line_prefix = '%t %d' -- Guy Rouillier
В списке pgsql-performance по дате отправления: