[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Xen-users] unexpected Out Of Memory (OOM)




Le mercredi 07 aoÃt 2013 Ã 14:36 +0100, Ian Campbell a Ãcrit :
> On Wed, 2013-08-07 at 13:17 +0200, Olivier Bonvalet wrote:
> 
> > name                = 'reto'
> > vcpus               = 1
> > maxvcpus    = 8
> > memory              = 8192
> > vif         = [ 'mac=0e:00:00:00:8e:70,bridge=vlan' ]
> > disk                = [ 
> >                   '/dev/rbd/sas3copies/reto-root,,xvda,w',
> >                   '/dev/rbd/sas3copies/reto-home,,xvdb,w',
> >                   '/dev/rbd/sas3copies/reto-var,,xvdc,w',
> >                   '/dev/rbd/sas3copies/reto-mysql,,xvdd,w',
> >                   '/dev/rbd/sas3copies/reto-exim,,xvde,w',
> > 
> >               '/dev/loop1,raw,xvdy,r',
> >               '/dev/loop2,raw,xvdz,r' ]
> > kernel              = '/etc/xen/kernels/reto/vmlinuz'
> > ramdisk             = '/etc/xen/kernels/reto/initrd.img'
> > root                = '/dev/xvda ro rootfstype=ext4'
> > extra               = 'panic=60'
> 
> All looks pretty normal.
> 
> > Then the console :
> > 
> > Parsing config from /etc/xen/reto.cfg
> > Daemon running with PID 20283
> > [    0.000000] Initializing cgroup subsys cpu
> > [    0.000000] Linux version 2.6.50-dae-xen (root@yiu) (gcc version 4.8.1 
> > (Debian 4.8.1-8) ) #2 SMP Sun Aug 4 22:42:05 CEST 2013
> > [    0.000000] Command line: root=/dev/xvda ro rootfstype=ext4 panic=60
> > [    0.000000] KERNEL supported cpus:
> > [    0.000000]   Intel GenuineIntel
> > [    0.000000] ACPI in unprivileged domain disabled
> > [    0.000000] e820: BIOS-provided physical RAM map:
> > [    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
> > [    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
> > [    0.000000] Xen: [mem 0x0000000000100000-0x00000001ffffffff] usable
> 
> This all looks good.
> 
> > [    1.776382] blkfront: xvdb: barrier or flush: disabled using persistent 
> > grants
> > [    1.797557]  xvdb: unknown partition table
> > [    1.798526] blkfront: xvdc: barrier or flush: disabled using persistent 
> > grants
> > [    1.820815]  xvdc: unknown partition table
> > [    1.822259] blkfront: xvdd: barrier or flush: disabled using persistent 
> > grants
> > [    1.853766]  xvdd: unknown partition table
> > [    1.854749] blkfront: xvde: barrier or flush: disabled using persistent 
> > grants
> > [    1.857572]  xvde: unknown partition table
> > [    1.858010] Setting capacity to 2097152
> > [    1.858018] xvda: detected capacity change from 0 to 1073741824
> > [    1.858760] blkfront: xvdy: flush diskcache: enabled using persistent 
> > grants
> > [    1.860885]  xvdy: unknown partition table
> > [    1.861913] blkfront: xvdz: flush diskcache: enabled using persistent 
> > grants
> > [    1.863770]  xvdz: unknown partition table
> 
> I know persistent grants have a fixed memory overhead, not sure if that
> is on the back or frontend though. Roger?
> 
> is there any way to disable persistent grants manually for testing
> purposes?
> 
> > [    8.595343] zram: module is from the staging directory, the quality is 
> > unknown, you have been warned.
> > [    8.596003] zram: Created 1 device(s) ...
> 
> My first thought was that there was a memory leak in the kernel
> somewhere, but staging drivers doing "magic" things with memory make me
> nervous. Can you try without zram to rule it out please?
> 
> Ian.
> 
> 

You're right, I disabled zram on this Domu (others didn't have zram).
The problem is still present.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.