I came across the performance problem with SPARC Sun280R machines, at first,
because they have a slower processor then modern AMD or x86 machines.
On sparc machines large backups cannot be managed, because the transfer rate of
the LTO is slowed down up to 1Mb/s or lower, because of the slow performance of
Postgres on the same machine.
Moving the DB on another x86 / amd machine solve the problem, but I anyway can
reach a maximum rate of 8-10Mb/sec, that is not the maximum transfer rate I may
have on those LTO drives (that may run from 15 to 60 to 120 Mb/s depending on
the version).
On x86/amd machines, the transfer is higher and acceptable, but yet not using
the full potential of the scsi library or tape drive, that is anyway lower than
it may be, always because postgres is slowing down the bacula process.
I am happy to know that we're gonna have a release with transactions, and see
what happens.
Thanx a lot,
Gabriele.
Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com
----------------------------------------------------------------------------------
Da: Bill Moran <[EMAIL PROTECTED]>
A: Gabriele Bulfon <[EMAIL PROTECTED]>
Cc: bacula-users@lists.sourceforge.net
Data: 13 dicembre 2006 15.09.50 CET
Oggetto: Re: [Bacula-users] Postgres slow because of autocommit
In response to Gabriele Bulfon <[EMAIL PROTECTED]>:
> Hello,
> I stumbled upon some pages that confirm a suspect I had about using
> postgres with bacula:
> - Postgres has autocommit by default, slowing down a lot any Bacula
> operation because Bacula does not use any transaction during write.
> If this is true....do I have any way to set up just the Bacula database
> (not the other ones I have) to have no autocommit?
> Is there any "pre-script" to set the bacula connection without auto commit?
There is no way (that I'm aware of) to disable "autocommit".
By definition, any database that's not being fed transactions is in
"autocommit" mode (PostgreSQL actually calls this "unchained" mode).
It makes sense: without an explicit transaction, how would the DB
server know when to commit the data? I don't know of any DB that
does it any differently.
That being said, the Bacula team has been working hard at adding
transaction support and other performance improvements -- if you
search the list archives, you'll see lots of discussions. I think
some of the improvements are slated to appear in the next version.
That being said, PostgreSQL runs just fine even without the transactions.
Everything I run uses PostgreSQL (I manage 4 directors). Two of them
manage large data sets using beefy hardware (of 25 servers, 1 of them
has 1,500,000 files/12G compressed) Another one is my laptop, and the
fourth is a medium-grade machine backing up about 20G of servers and
desktops. None of them are experiencing any performance problems.
--
Bill Moran
Collaborative Fusion Inc.
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users