On Sun, Apr 19, 2009 at 5:03 PM, Andreas Thienemann wrote:
> On Sun, 19 Apr 2009, John Drescher wrote:
>
>> > But seriously, you're not going to tell me that the bacula-dir process is
>> > going to need 2.6 GB of memory because of a few messages?
>> >
>> When I replied I did think of that. That is
On Sun, 19 Apr 2009, John Drescher wrote:
> > But seriously, you're not going to tell me that the bacula-dir process is
> > going to need 2.6 GB of memory because of a few messages?
> >
> When I replied I did think of that. That is quite excessive, I was
> thinking thousands of messages but enough
>> Well 2 drives are blocked because you have no appendable or usable
>> media. Any idea on how long it has been waiting for you to add tapes?
>> Perhaps the memory problem is that the messages are growing. Have you
>> typed messages in bconsole recently?
>
> Just to clarify. Yes, I know it's block
On Sun, 19 Apr 2009, John Drescher wrote:
> Well 2 drives are blocked because you have no appendable or usable
> media. Any idea on how long it has been waiting for you to add tapes?
> Perhaps the memory problem is that the messages are growing. Have you
> typed messages in bconsole recently?
Jus
On Sun, Apr 19, 2009 at 3:03 PM, Andreas Thienemann wrote:
> On Sat, 18 Apr 2009, Dan Langille wrote:
>
>> I no longer see the original detail, but I suspect there is one job
>> running, and it has spooled attributes waiting to be written. That is y
>> theory.
>
> Running Jobs:
> Writing: Increme
On Sat, 18 Apr 2009, Dan Langille wrote:
> I no longer see the original detail, but I suspect there is one job
> running, and it has spooled attributes waiting to be written. That is y
> theory.
Running Jobs:
Writing: Incremental Backup job analytics.2009-04-11_23 JobId=1229
Volume=""
pool=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Thienemann wrote:
> On Thu, 16 Apr 2009, Dan Langille wrote:
>
>>> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
>>> 1264 root 15 0 2007m 804m 1408 S 0.0 78.6 2:49.23 bacula-dir
>>>
>>> http://filepile.dicp.de
On Thu, 16 Apr 2009, Dan Langille wrote:
> > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> > 1264 root 15 0 2007m 804m 1408 S 0.0 78.6 2:49.23 bacula-dir
> >
> > http://filepile.dicp.de/bacula-dir-memory.png
>
> Could this be the spooled attributes taking up m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Thienemann wrote:
> We have a bacula-dir system which is waiting for manual intervention for
> some days time now. Due to technical problems with the tape drive, the
> problem will be with us for a few more days.
>
> Memory consumption of th
We have a bacula-dir system which is waiting for manual intervention for
some days time now. Due to technical problems with the tape drive, the
problem will be with us for a few more days.
Memory consumption of the bacula-dir process is rather high though
according to top:
PID USER PR
10 matches
Mail list logo
