On Mar 20, 2010, at 11:14 PM, <ananda.mudar_at_[hidden]> <ananda.mudar_at_[hidden]
> I am observing a very strange performance issue with my openmpi
> I have compute intensive openmpi based application that keeps the
> data in memory, process the data and then dumps it to GPFS parallel
> file system. GPFS parallel file system server is connected to a QDR
> infiniband switch from Voltaire.
> If my cluster is connected to a DDR infiniband switch which in turn
> connects to file system server on QDR switch, I see that I can run
> my application under checkpoint/restart control (with am ft-enable-
> cr) and I can checkpoint (ompi-checkpoint) successfully and the
> application gets completed after few additional seconds.
> If my cluster is connected to the same QDR switch which connects to
> file system server, I see that my application takes close to 10x
> time to complete if I run it under checkpoint/restart control (with
> am ft-enable-cr). If I run the same application using a plain mpirun
> command (ie; without -am ft_enable_cr), it finishes within a minute.
The 10x slowdown is without taking a checkpoint, correct? If the
checkpoint is taking up part of the bandwidth through the same switch
you are communicating with, then you will see diminished performance
until the checkpoint is fully established on the storage device(s).
Many installations separate the communication and storage networks (or
limiting the bandwidth of one of them) to prevent one from
unexpectedly demising the performance of the other, even outside of
the C/R context.
However for a non-checkpointing run to be 10x slower is certainly not
normal. Try playing with the C/R thread parameters (mentioned in a
previous email) and see if that helps. If not, we might be able to try
> I am using open mpi 1.3.4 and BLCR 0.8.2 for checkpointing
> Are there any specific MCA parameters that I should tune to address
> this problem? Any other pointers will be really helpful.
> Please do not print this email unless it is absolutely necessary.
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of
> the addressee(s) and may contain proprietary, confidential or
> privileged information. If you are not the intended recipient, you
> should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately and destroy all copies of this message
> and any attachments.
> WARNING: Computer viruses can be transmitted via email. The
> recipient should check this email and any attachments for the
> presence of viruses. The company accepts no liability for any damage
> caused by any virus transmitted by this email.
> users mailing list