<div dir="ltr"><div>Could it be a patrol read, possibly hitting a marginal disk? We've run into this on some of our Dell systems, and exporting the RAID HBA logs reveals what's going on. You can see those with "omconfig storage controller controller=n action=exportlog" (exports logs in /var/log/lsi_mmdd.log) or an equivalent MegaCLI command that I can't remember right now. We had a rash of these problems, along with uncaught media errors (probably a combination disk/firmware bug), so we ended up sending these logs to Splunk, but if it's a one-off thing it's pretty easy to spot visually too.<br><br></div>Skylar<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 19, 2018 at 1:58 PM, David Mathog <span dir="ltr"><<a href="mailto:mathog@caltech.edu" target="_blank">mathog@caltech.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On one of our Centos 6.9 systems with a PERC H370 controller I just noticed<br>
that file system reads are quite slow.  Like 30Mb/s slow.  Anybody care to hazard a guess what might be causing this situation?  We have another quite similar machine which is fast (A), compared to this (B) which is slow:<br>
           A      B<br>
RAM        512    512     GB<br>
CPUs       48     56      (via /proc/cpuinfo, actually this is threads)<br>
Adapter    H710P  H730<br>
RAID Level *      *       Primary-5, Secondary-0, RAID Level Qualifier-3<br>
Size       7.275  9.093   TB<br>
state      *      *       Optimal<br>
Drives     5      6<br>
read rate  540    30     Mb/s (dd if=largefile bs=8192 of=/dev/null& ; iotop)<br>
sata disk   ST2000NM0033<br>
sas disk          ST2000NM0023<br>
patrol     No    No       (megacli shows patrol read not going now)<br>
<br>
ulimit -a on both is:<br>
core file size          (blocks, -c) 0<br>
data seg size           (kbytes, -d) unlimited<br>
scheduling priority             (-e) 0<br>
file size               (blocks, -f) unlimited<br>
pending signals                 (-i) 2067196<br>
max locked memory       (kbytes, -l) 64<br>
max memory size         (kbytes, -m) unlimited<br>
open files                      (-n) 60000<br>
pipe size            (512 bytes, -p) 8<br>
POSIX message queues     (bytes, -q) 819200<br>
real-time priority              (-r) 0<br>
stack size              (kbytes, -s) 10240<br>
cpu time               (seconds, -t) unlimited<br>
max user processes              (-u) 4096<br>
virtual memory          (kbytes, -v) unlimited<br>
file locks                      (-x) unlimited<br>
<br>
Nothing in the SMART values indicating a read problem, although on "B"<br>
one disk is slowly accumulating events in the write x rereads/rewrites<br>
measurement (it has 2346, accumulated at about 10 per week).  The value is 0 there for reads x rereads/rewrites.  For "B" the smartctl output columns are:<br>
<br>
 Errors Corrected by         Total   Correction     Gigabytes    Total<br>
       ECC        rereads/  errors    algorithm      processed   uncorrected<br>
   fast | delayed rewrites corrected invocations   [10^9 bytes]  errors<br>
<br>
read: 934353848  0 0 934353848  0 48544.026 0<br>
read: <a href="tel:2017672022" value="+12017672022" target="_blank">2017672022</a> 0 0 <a href="tel:2017672022" value="+12017672022" target="_blank">2017672022</a> 0 48574.489 0<br>
read: <a href="tel:2605398517" value="+12605398517" target="_blank">2605398517</a> 3 0 <a href="tel:2605398520" value="+12605398520" target="_blank">2605398520</a> 3 48516.951 0<br>
read: <a href="tel:3237457411" value="+13237457411" target="_blank">3237457411</a> 1 0 <a href="tel:3237457412" value="+13237457412" target="_blank">3237457412</a> 1 48501.302 0<br>
read: <a href="tel:2028103953" value="+12028103953" target="_blank">2028103953</a> 0 0 <a href="tel:2028103953" value="+12028103953" target="_blank">2028103953</a> 0 14438.132 0<br>
read: 197018276  0 0 197018276  0 48640.023 0<br>
<br>
write: 0 0 0 0 0 26394.472 0<br>
write: 0 0 2346 2346 2346 26541.534 0<br>
write: 0 0 0 0 0 27549.205 0<br>
write: 0 0 0 0 0 25779.557 0<br>
write: 0 0 0 0 0 11266.293 0<br>
write: 0 0 0 0 0 26465.227 0<br>
<br>
verify: 341863005  0 0 341863005  0 241374.368 0<br>
verify: 866033815  0 0 866033815  0 223849.660 0<br>
verify: 2925377128 0 0 2925377128 0 221697.809 0<br>
verify: 1911833396 6 0 1911833402 6 228054.383 0<br>
verify: 192670736  0 0 192670736  0 66322.573 0<br>
verify: 1181681503 0 0 1181681503 0 222556.693 0<br>
<br>
If the process doing the IO is root it doesn't go any faster.<br>
<br>
Oddly if on "B" a second dd process is started on another file it ALSO reads at 30Mb/s.  So the disk system then does a total of 60Gb/s, but only 30Gb/s per process.  Added a 3rd and a 4th process doing the same.  At the 4th it seemed to hit some sort of limit, with each process now consistently less than 30Gb/s and the total at maybe 80Gb/s total.  Hard to say what the exact total was as it was jumping around like crazy.  On "A" 2 processes each got 270Mb/s,<br>
and 3 180Mb/s.  Didn't try 4.<br>
<br>
The only oddness of late on "B" is that a few days ago it loaded too many memory hungry processes so the OS killed some.  I have had that happen before on other systems without them doing anything odd afterwards.<br>
<br>
Any ideas what this slowdown might be?<br>
<br>
Thanks,<br>
<br>
David Mathog<br>
<a href="mailto:mathog@caltech.edu" target="_blank">mathog@caltech.edu</a><br>
Manager, Sequence Analysis Facility, Biology Division, Caltech<br>
______________________________<wbr>_________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman<wbr>/listinfo/beowulf</a><br>
</blockquote></div><br></div>