Magnus Hagander wrote: >> [...] 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. > Is your effective_cache_size properly set? > > 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? > 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. > State "uninterruptible sleep" often means it's blocking on I/O. > Unless you have a hardware problem somewhere. Naturally that is conscious to me. > 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. >> I'm afraid to disable fsync for postgresql. (Should this be the >> solution?) > > You can disable it, but if your system crashes (hardware or OS), you > will need to recover your catalog bacukp. Always do that even if it > looks ok - it'll come back to bite you. In general, I would definitly > not recommend running with fsync off, it's very dangerous (but then > I'm a database guy, so what else would you expect..). That is exactly my fear and that's why I don't want to disable fsync. Thanks & best regards, Jens Boettge ------------------------------------------------------- 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&kid=103432&bid=230486&dat=121642 _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
