Date: Fri, 29 Oct 2004 13:10:49 +0200
From: mmokrejs@ribosome.natur.cuni.cz
To: linux-kernel@vger.kernel.org
Cc: nathans@sgi.com
Subject: Re: Filesystem performance on 2.4.28-pre3 on hardware RAID5.
Message-ID: <20041029111049.GA554@ribosome.natur.cuni.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1314
Lines: 37

Hi Nathan, Marcello and others,
  the collested meminfo, slabinfo, vmstat output are at
http://www.natur.cuni.cz/~mmokrejs/crash/

Those precrash-* files contain output since the machine
was fresh, every second I appended current stats to each
of them. I believe some data were not flushed into the disk
before the problem.

I get on STDERR "fork: Cannot allocate memory"

Using anothe ropen console session and doing df gives me:

start_pipeline: Too many open files in system
fork: Cannot allocate memory

I had fortunately xdm to kill, so I could then do
sync and collect some stats (although some resources
got freed by xdm/X11). Those files are named with
prefix crash-*.

After that, I decided to put continue the suspended job,
and those files collected are precrash2-* prefixed.

There /var/log/messages included.

If you tell what kind of memory/xfs debugging I should turn
on adn *how*, I can do it immediately. I don't have access
to the machine daily, and already had to be in production. :(

Martin
P.S: It is hardware raid5. I use mkfs.xfs version 2.6.13.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/