> >> [...] I tried to "tune" postgreSQL by modifying some > settings in the > >> postgresql.conf: shared_buffers = 2048 wal_buffers = 64 > >> max_connections = 40 Nevertheless, it doesn't help. :-( > > > > What kind of hardware are you on? 2048 shared buffers is > very low for > > a lot of systems. I'd bump it up a bit (but not too far! > FOr example, > > I use about 25,000 for a system with 2Gb RAM) > > We are using a Dual-Xeon 2.8 GHz with still only 1 GB RAM. > The system uses two SCSI disks (10k rpm) with software RAID1. > It contains the OS, swap and the database. (It seems that was > no good idea.) There are also two disks with RAID0 for > spooling data and six disks with a RAID5 for some backups > (without spooling ;-)). > > I tried to increase the shared_buffers to 8192 but postgres > told me, that the shared memory segment exceeded the kernel's > SHMMAX parameter. > So I temporarily decreased the value again.
Ok. you'll want to change the max value in your kernel so you can get it up a bit. See http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html#SYS VIPC. > > Is your effective_cache_size properly set? This one is important for the planner to pick the correct plan. Don't set it too high, though. For my 2Gb system, I hav eit on 131072. So set it to maybe half ot that. > > Setting of full_page_writes? [that may be a 8.1 setting, can't > > remember, but it makes a huge difference if you have an I/O > system yuo > > acn trust] > > > > work_mem, maintenance_work_mem? checkpoint_segments? > > No changes were made at these settings until now. So postgres > uses the defaults. Any suggestions for these values? I run my 2Gb system with: work_mem = 256000 maintenance_work_mem = 256000 The default is 1024 and 16384, so yeah, those should go up high. Try 128000 for work_mem and 256000 for maintenance_work_mem. Make sure your checkpoint_segments is set to at least 8. It'll cost a bit of disk space, but it'll give better performance for burst insert/updates. > > Most improtantly, what's your I/O system? Writeback cache? WAL on > > separate spindles? Type of disks (IDE/SATA/SCSI?) > > I fear that I have underestimated the requirements. > Until a few minutes ago the disks of the softRAID were > running with write cache disabled. > WAL is still on the same spindles. That's the safe mode, of course. So that's good. Writeback cache should only be enabled if you have battery backup for the controller. If you trust your disks, you can disable full_page_writes. This is still a lot safer than disabling fsync, and cuts down WAL traffic considerably. > > The indexes will generally *hurt* your insert performance, which is > > what Bacula mainly needs during writes. I'll speed up restore > > operations, but there's the cost. > > I mentioned the indexes because I'm also with the read > performance not really happy. That's most likely because your work_mem was far too low. Every large sort operation will spill to disk, and that'll kill your performance. //Magnus ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
