[gpfsug-discuss] Confusing I/O Behavior

Aaron Knister aaron.s.knister at nasa.gov
Tue Apr 10 17:22:46 BST 2018


I wonder if this is an artifact of pagepool exhaustion which makes me 
ask the question-- how do I see how much of the pagepool is in use and 
by what? I've looked at mmfsadm dump and mmdiag --memory and neither has 
provided me the information I'm looking for (or at least not in a format 
I understand).

-Aaron

On 4/10/18 12:00 PM, Knister, Aaron S. (GSFC-606.2)[COMPUTER SCIENCE 
CORP] wrote:
> I hate admitting this but I’ve found something that’s got me stumped.
> 
> We have a user running an MPI job on the system. Each rank opens up 
> several output files to which it writes ASCII debug information. The net 
> result across several hundred ranks is an absolute smattering of teeny 
> tiny I/o requests to te underlying disks which they don’t appreciate. 
> Performance plummets. The I/o requests are 30 to 80 bytes in size. What 
> I don’t understand is why these write requests aren’t getting batched up 
> into larger write requests to the underlying disks.
> 
> If I do something like “df if=/dev/zero of=foo bs=8k” on a node I see 
> that the nasty unaligned 8k io requests are batched up into nice 1M I/o 
> requests before they hit the NSD.
> 
> As best I can tell the application isn’t doing any fsync’s and isn’t 
> doing direct io to these files.
> 
> Can anyone explain why seemingly very similar io workloads appear to 
> result in well formed NSD I/O in one case and awful I/o in another?
> 
> Thanks!
> 
> -Stumped
> 
> 
> 
> 
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
> 

-- 
Aaron Knister
NASA Center for Climate Simulation (Code 606.2)
Goddard Space Flight Center
(301) 286-2776



More information about the gpfsug-discuss mailing list