WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-users] OOM killer problem

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-users] OOM killer problem
From: "Satoshi Uchida" <s-uchida@xxxxxxxxxxxxx>
Date: Mon, 19 Jun 2006 14:10:14 +0900
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 18 Jun 2006 22:11:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaTXqP3Mj6+opXOTh6r9EuLkr5DRQ==
Hello.

I seem to the oom killer problem which is similler at the case of slower
devices.

My environment is x86, -unstable and using physical partition as VM disk.
Start up Four VM, and take them high I/O load by dd program.
 ex. dd if=/dev/null of=/tmp/filename bs=1M count=4096.

Therefore, some VM kill many deamon by oom-killer, and
return to login console without some deamon.

In the case of less than three VM, this problem are not observed only a few.
And in the case of using image files as VM disk (by loop device), too.
 (In loop device environment, seven VM is processed.)

In my examination, vbd thread became often OO-states.
So, I think that this cause is that I/O request is not processed faster. 
This problem is found in the case file systems is slower by some Web page.

Truth cause of this problem may be not in Xen, but so may be in Linux.
However, I report here.
If Truth cause is in Linux, this situation is not observed in Linux, but is
in VM on Xen.
So, It may be need to resolve at Xen by inproving I/O model

Satoshi UCHIDA

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
<Prev in Thread] Current Thread [Next in Thread>