> On Fri, 26 Jun 2009 11:53:26 -0700, mehma sarja said:
>
> Thanks Martin,
>
> You have put a good closure on the quest for knowledge. If I upgrade Bacula,
> will I have to upgrade the database? Meaning do I have to run those update
> table scripts. I am on postgresql version 8.29.
Sorry, I
Thanks Martin,
You have put a good closure on the quest for knowledge. If I upgrade Bacula,
will I have to upgrade the database? Meaning do I have to run those update
table scripts. I am on postgresql version 8.29.
Yudhvir
OK, this shows why it is slow. The algorithm in add_findex is only
> eff
> On Wed, 24 Jun 2009 13:59:26 -0700, mehma sarja said:
>
> Thanks for all your help you guys. I am impressed with the level of
> expertise here!
>
> > Error accessing memory address 0x7fbff000: Bad address.
> > > #0 0x0040c043 in add_findex ()
> >
> > The function add_findex is
Thanks for all your help you guys. I am impressed with the level of
expertise here!
> Error accessing memory address 0x7fbff000: Bad address.
> > #0 0x0040c043 in add_findex ()
>
> The function add_findex is interesting, but I think like your bacula-dir
> was
>
> Try the following gdb
> On Wed, 24 Jun 2009 10:41:03 -0700, mehma sarja said:
>
> (gdb) thread apply all bt
>
> Thread 4 (Thread 0x801902180 (LWP 100350)):
> #0 0x0008016f98cc in nanosleep () from /lib/libc.so.7
> #1 0x0008009078c5 in nanosleep () from /lib/libthr.so.3
> #2 0x0044e21e in bmicros
(gdb) thread apply all bt
Thread 4 (Thread 0x801902180 (LWP 100350)):
#0 0x0008016f98cc in nanosleep () from /lib/libc.so.7
#1 0x0008009078c5 in nanosleep () from /lib/libthr.so.3
#2 0x0044e21e in bmicrosleep ()
#3 0x0042408d in wait_for_next_job ()
#4 0x00408a
I got into gdb but know very little how to move around in there. I tried:
[r...@lucifer ~]# gdb /usr/local/sbin/bacula-dir 27410
GNU gdb 6.1.1 [FreeBSD]
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols
found)...
Attaching to program: /usr/local/sbin/bacula-dir, process 274
> On Tue, 23 Jun 2009 16:09:57 -0700, mehma sarja said:
>
> >
> > Did you wait till the cpu went back to low cpu usage?
>
> No, it stays high overnight and my patience runs out before cpu pegging
> does.
I suggest attaching gdb to the bacula-dir process to see what it is doing,
e.g.
thread
I'm pretty sure that a postgresql server running with so low memory
27484 pgsql 1 40 54668K 37488K sbwait 0 1:20 0.00% postgres
could give a suffisant throughput.
54MB tend to indicate a default deb/rpm installation value which are very low.
During the process you can get the query
>
> Did you wait till the cpu went back to low cpu usage?
No, it stays high overnight and my patience runs out before cpu pegging
does.
> Depending on
> your configuration and optimization of your database this could take
> anywhere from a few minutes to a few hours to finish.
>
> I assume the d
Although the cpu is pinged at 100%
Yudhvir
>
> The dir and database are on the same machine and memory is not a problem.
>
>
--
___
Bacula-users mailing list
Bacula-users@lists.
John,
The dir and database are on the same machine and memory is not a problem. I
tried a partial restore - it restores files but not recursively. Meaning no
subdirectories. Then I tried restoring the subdirectory. It get that too but
no sub-sub directories.
Yudhvir
--
2009/6/23 mehma sarja :
> Trying to restore files using bconsole: * restore client=client1-fd
> fileset=Client1-Fileset select current all done. It does the 'select',
> 'current', and 'all' but sits there on the 'done' part. I have left it like
> this overnight with no change in status. My setup i
Trying to restore files using bconsole: * restore client=client1-fd
fileset=Client1-Fileset select current all done. It does the 'select',
'current', and 'all' but sits there on the 'done' part. I have left it like
this overnight with no change in status. My setup is Bacula 2.4.4 DIR and SD
on a F
14 matches
Mail list logo
