On Nov 22, 2022, at 13:57, John Bauer
<bau...@iodoctors.com<mailto:bau...@iodoctors.com>> wrote:
Hi all,
I am making a call to llapi_layout_get_by_fd() from each rank of a 16 rank MPI
job. One rank per node.
About 75% of the time, one of the ranks, typically rank 0, takes a very long
time to complete this call. I have placed fprintf() calls with wall clock
timers around the call. If it does take a long time it is generally about 260
seconds. Otherwise it takes only micro-seconds.
How I access llapi_layout_get_by_fd() :
liblustreapi = dlopen("liblustreapi.so", RTLD_LAZY ) ;
LLAPI.layout_get_by_fd = dlsym( liblustreapi, "llapi_layout_get_by_fd" ) ;
How I call llapi_layout_get_by_fd() :
if(dbg)fprintf(stderr,"%s %12.8f %s() before
LLAPI.layout_get_by_fd()\n",host,rtc(),__func__);
struct llapi_layout *layout = (*LLAPI.layout_get_by_fd)( fd, 0);
if(dbg)fprintf(stderr,"%s %12.8f %s() after
LLAPI.layout_get_by_fd()\n",host,rtc(),__func__);
The resulting prints from rank 0 :
r401i2n10 7.22477698 LustreLayout_get_by_fd() before LLAPI.layout_get_by_fd()
r401i2n10 269.52539992 LustreLayout_get_by_fd() after LLAPI.layout_get_by_fd()
Any ideas on what might be triggering this. The layout returned seems to be
correct every time, whether it takes a long time or not. The layout returned
has the correct striping information, but the component has no OSTs as the
component has yet to be instantiated for the new file.
Running under strace/ltrace would show where the slowdown is, and Lustre kernel
debug logs would be needed to isolate this to a specific piece of code. Given
the length of time it is likely that an RPC is timing out (presumably nothing
is printed on the console logs), but you'd need to look at exactly what is
happening.
It's a *bit* strange, because this call is essentially equivalent to
"getxattr", but over the years a bunch of cruft has been added and it is
probably doing a lot more than it should... You could potentially use
(approximately):
fgetxattr(fd, "lustre.lov", buf, buflen);
llapi_layout_get_by_xattr(buf, buflen, 0);
but then we wouldn't know what is making this slow and you couldn't submit a
patch to fix it...
Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Whamcloud
_______________________________________________
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
