2014-12-19 9 views
0

HPC 벤치 마크 (IOR-http://sourceforge.net/projects/ior-sio/)를 실행 중입니다. IOR의 소스를 컴파일하고 openmpi 1.5.3으로 실행했습니다.openmpi : 특정 프로세스 수에 대해 MPI_recv가 응답하지 않습니다.

프로세스의 수 (-np)가 6보다 작 으면 홀수라는 문제가 있습니다. 나는 주위와는 다른 모든 것들을 제거, 내가 도망 실제 명령이 내려 온다 :

#0 0x00007f3ac49e95fe in mlx4_poll_cq() from /usr/lib64/libmlx4-m-rdmav2.so 
#1 0x00007f3ac6ce0918 in ??() from /usr/lib64/openmpi/lib/openmpi/mca_btl_openib.so 
#2 0x000000385a6f0d5a in opal_progress() from /usr/lib64/openmpi/lib/libmpi.so.1 
#3 0x00007f3ac7511e05 in ??() from /usr/lib64/openmpi/lib/openmpi/mca_pml_ob1.so 
#4 0x000000385a666cac in PMPI_Recv() from /usr/lib64/openmpi/lib/libmpi.so.1 
#5 0x0000000000404bd7 in CountTasksPerNode (numTasks=16, comm=0x628a80) at IOR.c:526 
#6 0x0000000000407d53 in SetupTests (argc=11, argv=0x7fffe61fa2a8) at IOR.c:1402 
#7 0x0000000000402e96 in main (argc=11, argv=0x7fffe61fa2a8) at IOR.c:134 

이 문제는 발생합니다 GDB의 과정을 부착

/usr/lib64/openmpi/bin/mpirun --machinefile mpi_hosts --bynode -np 16 /path/to/IOR -F -u -t 1m -b 16g -i 1 -o /my/file/system/out_file 

프로세스가 MPI_recv에 달려 있음을 보여줍니다 -np이 2/3/4/5 인 경우. 그것은 1/6/7/8/16 등에서 작동합니다.

date 또는 ls과 같은 간단한 명령을 사용하면이 문제를 재현 할 수 없습니다. 그래서 이것이 내가 컴파일 한 환경이나 IOR 바이너리에 문제가 있는지 확신 할 수 없다. (매우 오래된/안정된 IOR 바이너리에서도 마찬가지다.

또한 openmpi1.5.3 대신 openmpi1.4.3을 사용할 때 정확한 동작이 관찰됩니다.

여러 호스트 (--machinefile 인수)를 사용하여 시도한 결과 위에서 언급 한 -np 값에 대해 동일한 동작이 관찰되었습니다.

MPI_Recv(hostname, MAX_STR, MPI_CHAR, MPI_ANY_SOURCE, MPI_ANY_TAG, comm, &status); 

은 기본적으로 내가 -np가 2/3/4/5 때 MPI_recv()가 중단 될 수 있습니다 이유에 대한 단서를 찾고 : 이 중단 소스 라인이있다. 다른 정보가 필요한지 알려주십시오. 감사.

+0

InfiniBand 관련 문제인 것 같습니다. 'mlx4_poll_cq '는 IB HCA의 완성 대기열을 폴링하기 위해 호출되며, 수신 오퍼레이션에서 정지하기 때문에 다른 쪽 (예 : 다른 랭크)이 전송을 완료하지 못했다는 것을 의미합니다. InfiniBand 장비 및 커널 매개 변수를 확인하십시오. 또는 더 나은 질문을 [Open MPI Users] (http://www.open-mpi.org/community/lists/ompi.php) 메일 링리스트에 게시하십시오. –

+0

나는 그것도 의심했다. 나는 로컬에 HCA를 확인하고 그들은 괜찮은 것 같았다. 저는 IB 전문가가 아니며 엔지니어와 엔지니어의 도움을 요청할 것입니다. 나는 또 다른 시도를 월요일에하고 거기에서 가져다 줄 것이다. 시간과 도움이되는 제안에 감사드립니다. –

+0

IOR은 오랫동안 오랫동안 사용되어 왔습니다. 나는 IOR이나 어떤 파일 시스템 벤치 마크가 하드웨어 결함을 밝히기에는 꽤 좋지만 IOR에 결함이 있는지 의심 스럽다. github의 IOR이 좀 더 나은보고 기능을 제공합니다. https://github.com/chaos/ior –

답변

1

염두에 두어야 할 첫 번째 점은 : MPI_Recv은 차단 수신이며 일치하는 MPI_Send이 호출 될 때까지 대기합니다. 그러나 전송하는 패킷이 너무 작 으면 (즉, MPI가 이러한 작업을 위해 별도로 지정하는 버퍼에 맞음) 함수는 실제로 기다리지 않고 대신 코드를 통해 수행합니다. 더 높은 코어 수의 경우 각 MPI_Send/MPI_Recv 명령을 보내면 버퍼에 데이터가 들어가기 때문에 모든 것이 계속 진행됩니다. 코어 수가 낮 으면 버퍼에 들어갈 데이터가 너무 많아 정보를 얻기 위해 MPI_Send을 적절하게 호출하지 않았으므로 MPI_Recv이 중단됩니다. 이 가설을 빠르고 쉽게 테스트 할 수 있습니다. 문제의 크기를 크게 줄입니다. 그것들은 여전히 ​​그 모든 핵심 카운트에 걸려 있니? 그렇지 않다면 그것은 나의 가설에 대한 증거이며, 우리는 문제가 무엇인지 알 수 있도록 더 많은 코드를 제공해야 할 것입니다.

+0

hmmm ...하지만이 제안과 모순되는 1 개의 프로세스가 중단되지 않는 경우 전송하는 데이터가 상당히 많습니다 (GB 단위).아주 작은 값을 포함하여 다양한 크기로 시도해 보겠습니다. 소스는 문제의 링크에서 볼 수 있습니다. 코드가 너무 많아서 실제로 SO 적합성 문제 재현 가능 코드를 생성하는 데 익숙하지 않습니다. 감사. –

+0

@BlueMoon : 하나의 프로세서 만 (아무 것도 보내지 않을 때) 아무 것도 전송하지 않아야하므로 1 개의 프로세스에서 멈추지 않으므로 문제 크기에 관계없이 반환해야합니다. – wolfPack88

+0

오른쪽. 여러 프로세스를 사용하여 다양한 크기로 시도해 보겠습니다. –