Am 27.04.2012 17:26, schrieb Efraín Déctor:
> Thank you all.
>
> I found out that a Java process was using all this space. I restarted
> it and voilá problem solved.
Did you write this Java program?
If so, you probably need a finally block:
File f = ...
InputStream in = null;
try {
in = new F
> Daniel Braniss wrote:
> > > Daniel Braniss wrote:
> > > > > Daniel Braniss wrote:
> > > > > > > Security_Multipart(Fri_Apr_27_13_35_56_2012_748)--
> > > > > > > Content-Type: Text/Plain; charset=us-ascii
> > > > > > > Content-Transfer-Encoding: 7bit
> > > > > > >
> > > > > > > Rick Macklem w
Le 28/04/2012 ? 09:55:41+0300, Alexander Motin a écrit
> >>>
> >>> last pid: 61010; load averages: 0.00, 0.00, 0.00 up 2+11:02:42
> >>> 22:29:08
> >>> 126 processes: 1 running, 125 sleeping
> >>> CPU: % user, % nice, % system, % interrupt, % idle
> >>> Mem: 803M Active, 287
Is it possible to get the backtrace for a LoR from any of the system
logs or anything like that, after the fact? Especially after
rebooting into a non-debug kernel?
I compiled a custom kernel for our ZFS boxes that have been locking up
on me lately, adding INVARIANTS and WITNESS. But, to be safe
I've been deploying FreeBSD 9 without issue on a number of
near-identical servers for a client, but have run into an interesting
annoyance when I hit the two DB servers.
These DB servers have an LSI 3ware 9750-8i (running a 6 disk RAID 10 in
a single 3TB virtual volume) which puts them apart f
