On Thu, Jun 12, 2014 at 07:26:25AM +0100, Justin Clift wrote: > On 12/06/2014, at 6:58 AM, Niels de Vos wrote: > <snip> > > If you capture a vmcore (needs kdump installed and configured), we may > > be able to see the cause more clearly. Oh, these seem to be Xen hosts. I don't think kdump (mainly kexec) works on Xen. You would need to run xen-dump (or something like that) on the Dom0, for that, you'll have to call Rackspace support, and I have no idea how they handle such requests... > That does help, and so will Harsha's suggestion too probably. :) That is indeed a solution that can mostly prevent such memory dead-locks. Those options can be used to configure to push out the outstanding data earlier to the loop-devices, and to the underlying XFS filesystem that hold the backing files for the loop-devices. Cheers, Niels > I'll look into it properly later on today. > > For the moment, I've rebooted the other slaves which seems to put them into > an ok state for a few runs. > > Also just started some rackspace-regression runs on them, using the ones > queued up in the normal regression queue. > > The results are being updated live into Gerrit now (+1/-1/MERGE CONFLICT). > > So, if you see any regression runs pass on the slaves, it's worth removing > the corresponding job from the main regression queue. That'll help keep > the queue shorter for today at least. :) > > Btw - Happy vacation Niels :) > > /me goes to bed > > + Justin > > -- > GlusterFS - http://www.gluster.org > > An open source, distributed file system scaling to several > petabytes, and handling thousands of clients. > > My personal twitter: twitter.com/realjustinclift > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
