On Thu, 2010-05-20 at 16:27 +0200, Olivier Hargoaa wrote: > > On Lustre we get poor read performances > and good write performances so we decide to modify Lustre network in > order to see if problems comes from network layer.
Without having any other information other than your statement that "performance is good in one direction but not the other" I wonder why you consider the network as being the most likely candidate as a culprit for this problem. I haven't come across very many networks that (weren't designed to be and yet) are fast in one direction and slow in the other. > Therefore, we'll perform the following steps: we will umount the > filesystem, reformat the mgs, change lnet options in modprobe file, > start new mgs server, and finally modify our ost and mdt with > tunefs.lustre with failover and mgs new nids using "--erase-params" and > "--writeconf" options. Sounds like a lot of rigmarole to test something that I would consider to be of low probability (given the brief amount of information you have provided). But even if I did suspect the network were slow in only one direction, before I started mucking with reconfiguring Lustre for different networks, I would do some basic network throughput testing to verify my hypothesis and adjust the probability of the network being the problem accordingly. Did you do any hardware profiling (i.e. using the lustre-iokit) before deploying Lustre on this hardware? We always recommend profiling the hardware for exactly this reason: explaining performance problems. Unfortunately, now that you have data on the hardware, it's much more difficult to profile the hardware because to do it properly, you need to be able to write to the disks. b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss