On Fri, Apr 01, 2005 at 01:32:31PM -0500, Robert Buels wrote:
> On a pretty fast server running debian stable and vanilla linux
> 2.4.29, xfsdump is very slow to write media files and produces
> "__alloc_pages: 0-order allocation failed (gfp=0x0/0)" kernel error
> messages when backing up a 1/3 full 915GB partition, and may be
> causing the machine to hard lock.
you ran out of memory
check /proc/meminfo and make sure it looks sane --- it's possible
something is leaking
> I have a new server, dual 2.4GHz xeon, 2GB RAM, with an LSI SATA
> hardware raid 5 ('megaraid' kernel driver), running debian stable,
> with a 2.4.29 vanilla kernel, connected to an exabyte LTO2 tape
> changer through a SCSI card using the sym53c8xx. On the big raid 5
> (appearing to the OS as /dev/sda), there is a large (915GB) XFS
> partition mounted at /data. I am running backups of this large
> partition onto the tape changer using xfsdump.
i wonder if page-cache pressure here is making things worse. i saw
pretty unreasonable behaviour using xfsdump under 2.4.x a while ago
2.6.x is better but the problem can still occur, mostly you fill the
page-cache and things start to swap and get crappy --- but i never got
OOM as you are
maybe xfsdump should use posix_fadvise and see if that helps?
> Now, xfsdump seems to be having some significant difficulties
> backing up this partition. It now seems to take upwards of 3
> minutes to assemble a single media file of about 300MB, while the
> tape drive sits idly, then writes the media file to the tape drive
> at what seems to be near-spec speed.
what does 'vmstat 1' look like during this?
|