<div dir="ltr"><div class="gmail-moz-text-plain" style="font-family:-moz-fixed;font-size:13px" lang="x-western"><pre class="gmail-moz-quote-pre"></pre><blockquote type="cite" style="color:rgb(0,124,255)"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><pre class="gmail-moz-quote-pre">"Miloslav" == Miloslav Hůla <a class="gmail-moz-txt-link-rfc2396E" href="mailto:miloslav.hula@gmail.com"><miloslav.hula@gmail.com></a> writes:
</pre></blockquote></blockquote></blockquote></blockquote></blockquote><pre class="gmail-moz-quote-pre">Miloslav> Dne 09.09.2020 v 17:52 John Stoffel napsal(a):
Miloslav> There is a one PCIe RAID controller in a chasis. AVAGO
Miloslav> MegaRAID SAS 9361-8i. And 16x SAS 15k drives conneced to
Miloslav> it. Because the controller does not support pass-through for
Miloslav> the drives, we use 16x RAID-0 on controller. So, we get
Miloslav> /dev/sda ... /dev/sdp (roughly) in OS. And over that we have
Miloslav> single btrfs RAID-10, composed of 16 devices, mounted as
Miloslav> /data.
</pre><blockquote type="cite" style="color:rgb(0,124,255)"><blockquote type="cite"><pre class="gmail-moz-quote-pre">I will bet that this is one of your bottlenecks as well. Get a secord
or third controller and split your disks across them evenly.
</pre></blockquote></blockquote><pre class="gmail-moz-quote-pre">Miloslav> That's plan for a next step.
Miloslav> We run 'rsync' to remote NAS daily. It takes about 6.5 hours to finish,
Miloslav> 12'265'387 files last night.
</pre><blockquote type="cite" style="color:rgb(0,124,255)"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><pre class="gmail-moz-quote-pre">That's.... sucky. So basically you're hitting the drives hard with
random IOPs and you're probably running out of performance. How much
space are you using on the filesystem?
</pre></blockquote></blockquote><pre class="gmail-moz-quote-pre"></pre></blockquote></blockquote><pre class="gmail-moz-quote-pre">Miloslav> It's not so sucky how it seems. rsync runs during the
Miloslav> night. And even reading is high, server load stays low. We
Miloslav> have problems with writes.
</pre><blockquote type="cite" style="color:rgb(0,124,255)"><blockquote type="cite"><pre class="gmail-moz-quote-pre">Ok. So putting in an SSD pair to cache things should help.
</pre><blockquote type="cite"><blockquote type="cite"><pre class="gmail-moz-quote-pre">And why not use brtfs send to ship off snapshots instead of using
rsync? I'm sure that would be an improvement...
</pre></blockquote></blockquote><pre class="gmail-moz-quote-pre"></pre></blockquote></blockquote><pre class="gmail-moz-quote-pre">Miloslav> We run backup to external NAS (NetApp) for a disaster
Miloslav> recovery scenario. Moreover NAS is spreaded across multiple
Miloslav> locations. Then we create NAS snapshot, tens days
Miloslav> backward. All snapshots easily available via NFS mount. And
Miloslav> NAS capacity is cheaper.
</pre><blockquote type="cite" style="color:rgb(0,124,255)"><blockquote type="cite"><pre class="gmail-moz-quote-pre">So why not run the backend storage on the Netapp, and just keep the
indexes and such local to the system? I've run Netapps for many years
and they work really well. And then you'd get automatic backups using
schedule snapshots.
Keep the index files local on disk/SSDs and put the maildirs out to
NFSv3 volume(s) on the Netapp(s). Should do wonders. And you'll stop
needing to do rsync at night.
</pre></blockquote></blockquote><pre class="gmail-moz-quote-pre">Miloslav> It's the option we have in minds. As you wrote, NetApp is very solid.
Miloslav> The main reason for local storage is, that IMAP server is completely
Miloslav> isolated from network. But maybe one day will use it.
It's not completely isolated, it can rsync data to another host that
has access to the Netapp. <b class="gmail-moz-txt-star"><span class="gmail-moz-txt-tag">*</span>grin<span class="gmail-moz-txt-tag">*</span></b>
Miloslav> Unfortunately, to quickly fix the problem and make server
Miloslav> usable again, we already added SSD and moved indexes on
Miloslav> it. So we have no measurements in old state.
That's ok, if it's better, then its better. How is the load now?
Looking at the output of 'iostat -x 30' might be a good thing.
Miloslav> Situation is better, but I guess, problem still exists. I
Miloslav> takes some time to load be growing. We will see.
Hmm... how did you setup the new indexes volume? Did you just use
btrfs again? Did you mirror your SSDs as well?
Do the indexes fill the SSD, or is there 20-30% free space? When an
SSD gets fragmented, it's performance can drop quite a bit. Did you
put the SSDs onto a seperate controller? Probably not. So now you've
just increased the load on the single controller, when you really
should be spreading it out more to improve things.
Another possible hack would be to move some stuff to a RAM disk,
assuming your server is on a UPS/Generator incase of power loss. But
that's an unsafe hack.
Also, do you have quotas turned on? That's a performance hit for
sure.
Miloslav> Thank you for the fio tip. Definetly I'll try that.
It's a good way to test and measure how the system will react.
Unfortunately, you will need to do your testing outside of normal work
hours so as to not impact your users too much.
Good luck! Please post some numbers if you get them. If you see
only a few disks are 75% or more busy, then <b class="gmail-moz-txt-star"><span class="gmail-moz-txt-tag">*</span>maybe<span class="gmail-moz-txt-tag">*</span></b> you have a bad
disk in the system, and moving off that disk or replacing it might
help. Again, hard to know.
Rebalancing btrfs might also help, especially now that you've moved
the indexes off that volume.
</pre><pre class="gmail-moz-quote-pre">Robert: </pre><pre class="gmail-moz-quote-pre"><font style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal;vertical-align:inherit"><font style="vertical-align:inherit">Fio is an acronym for </font></font><b style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal"><font style="vertical-align:inherit"><font style="vertical-align:inherit">Flexible IO Tester</font></font></b><font style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal;vertical-align:inherit"><font style="vertical-align:inherit"> and describes a tool for measuring IO performance. </font><font style="vertical-align:inherit">With Fio, devices such as hard drives or SSDs can be tested for their speed by </font><font style="vertical-align:inherit">executing </font><font style="vertical-align:inherit">a <b>user-defined </b></font></font><b style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal"><font style="vertical-align:inherit"><font style="vertical-align:inherit">workload</font></font></b><font style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal;vertical-align:inherit"><font style="vertical-align:inherit"> and collecting performance data. Therefore it might be difficult to really simulate the load with that, because You need to define the workload Yourself.<br>But, at least, You might use it to get an idea of maximum transfer rates, random I/O etc.<br></font></font>
<b style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal"><font style="vertical-align:inherit"><font style="vertical-align:inherit">iotop</font></font></b><font style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal;vertical-align:inherit"><font style="vertical-align:inherit"> shows the <b>current I/O transfer </b></font><b><font style="vertical-align:inherit">rates</font></b><font style="vertical-align:inherit"> for the currently running processes / threads. </font><font style="vertical-align:inherit">It uses the I/O usage information of the Linux kernel, so it might be a good tool for You.<br><b>htop </b>might also be Your friend.<br>and of course, as someone else pointed out : </font></font></pre><pre class="gmail-moz-quote-pre"><font style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal;vertical-align:inherit"><font style="vertical-align:inherit">>
Looking at the output of 'iostat -x 30' might be a good thing.
<br><br>my default setup for such diagnosis is to run iotop, htop, ntop to get an idea whats going on and measure ... <br>for the index-SSD (on a different Channel ? NvMe ?) I strongly suggest to compare EXT4 vs BTRFS - some Benchmarks suggest that on fast SSD´s EXT4 is much (factor 4-5) faster then btrfs.<br><br>You might also try ZSTD transparent compression on the remaining (non-SSD) btrfs disks - this can boost the transfer rate (since the data is compressed) if the Server CPU´s have enough juice.<br>But from my guts feeling, its not the transfer rate - its the random I/O (in that case the situation will get worse with compression), but You really need to measure that. <br><br>In general I dont understand that (old fashioned) configuration - using a bunch of 2TB or even 4TB TLC SSD in Raid10 is nowadays really affordable. You can keep the old disks for (local) rsync before You rsync from there to the NAS ... <br><br></font></font></pre><pre class="gmail-moz-quote-pre"><span style="color:rgb(63,64,66);font-family:FSMeWeb,sans-serif;font-size:14.4px;white-space:normal">Robert</span><br></pre><pre class="gmail-moz-quote-pre"><font style="font-family:FSMeWeb,sans-serif;color:rgb(63,64,66);font-size:14.4px;white-space:normal;vertical-align:inherit"><font style="vertical-align:inherit"><br></font></font></pre><pre class="gmail-moz-quote-pre">
</pre><pre class="gmail-moz-quote-pre"><br></pre><pre class="gmail-moz-quote-pre"><br></pre><pre class="gmail-moz-quote-pre"><br></pre></div></div>