As I wrote, the situation was improved by moving the client to one of the machines where the OSS are running under a virtual instance.

But what could be the reason for this? Seems to me there has to be some kind of competition of resources. But what resources?

Would the situation be improved by more memory? Faster CPU or disk? While creating the virtual machine number of cores, and amount of memory in the virtual machine are specified, should I increase or decrease these resources? Are there some kernel settings that could help improve the situation? Or maybe some BIOS settings related to the virtual machines?

Just curious here.

Thanks,

/jon

On 02/16/2017 04:55 PM, Mohr Jr, Richard Frank (Rick Mohr) wrote:
On Feb 16, 2017, at 9:56 AM, Jon Tegner <[email protected]> wrote:

I have three (physical) machines, and each one have a virtual machine on them 
(KVM). On one of the virtual machines there is an MDS and on two of them there 
are OSS:es installed.

All system use CentOS-7.3 and Lustre 2.9.0, and I mount the file system on one 
of the physical machines.

Which machine of you mount the file system on?  Is it an OSS node or the MDS 
node?

Anyway, when evaluating the performance (using FIO) I expected to see an increased 
transfer rate when going from one to two simultaneous files in the tests, and I do see 
this, but only for very small file sizes (around 0.2 GB). On the "non virtual" 
file systems I have tested the effect of increased transfer rate as the number of files 
are increased is on the other hand easily verified.
Have you tried mounting the file system on different nodes?  This could help 
determine if the problem is always the same or if it might be affected by the 
type of node (MDS vs OSS) that is being used for the client.

--
Rick Mohr
Senior HPC System Administrator
National Institute for Computational Sciences
http://www.nics.tennessee.edu



_______________________________________________
lustre-discuss mailing list
[email protected]
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Reply via email to