<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">First, my degree from school is in Physics. So I know something about designing experiments. :)</div><div class="gmail_quote"><br></div><div class="gmail_quote">The benchmark scripts runs "dd" 218 times, against different volumes (of differing sizes), with differing "bs". Measures are collected both from the physical host, and from the within the instance. Linux is told to drop caches before the start. </div><div class="gmail_quote"><br></div><div class="gmail_quote">The benchmark scripts are in:</div><div class="gmail_quote"><br></div><div class="gmail_quote">  <a href="https://github.com/pbannister/openstack-bootstrap">https://github.com/pbannister/openstack-bootstrap</a><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">(Very much a work in progress! Not complete or properly documented.)<br><br><br>Second, went through the exercise of collecting hints from the web as to parameters for tuning iSCSI performance. (I did not expect changing Linux TCP parameters to change the result for iSCSI over loopback, but measured to be certain.) Followed all the hints, with no change in performance (as expected).<br><br>Found that if I repeatedly scanned the same 8GB volume from the physical host (with 1/4TB of memory), the entire volume was cached in (host) memory (very fast scan times).  </div><div class="gmail_quote"><br></div><div class="gmail_quote">Scanning the same volume from within the instance still gets the same ~450MB/s that I saw before. The difference is that "iostat" in the host is ~93% idle. In the host, <b>iscsi_ttx</b> is using ~58% of a CPU (sound high?), and <b>qemu-kvm</b> is using ~30% of a CPU. (The physical host is a fairly new box - with 40(!) CPUs.)</div><div class="gmail_quote"><br></div><div class="gmail_quote">The "iostat" numbers from the instance show ~44 %iowait, and ~50 %idle. (Which to my reading might explain the ~50% loss of performance.) Why so much idle/latency?</div><div class="gmail_quote"><br></div><div class="gmail_quote">The in-instance "dd" CPU use is ~12%. (Not very interesting.)<br><br><br>Not sure from where the (apparent) latency comes. The host iSCSI target? The QEMU iSCSI initiator? Onwards...<br><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Mar 1, 2016 at 5:13 PM, Rick Jones <span dir="ltr"><<a href="mailto:rick.jones2@hpe.com" target="_blank">rick.jones2@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 03/01/2016 04:29 PM, Preston L. Bannister wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Running "dd" in the physical host against the Cinder-allocated volumes<br>
nets ~1.2GB/s (roughly in line with expectations for the striped flash<br>
volume).<br>
<br>
Running "dd" in an instance against the same volume (now attached to the<br>
instance) got ~300MB/s, which was pathetic. (I was expecting 80-90% of<br>
the raw host volume numbers, or better.) Upping read-ahead in the<br>
instance via "hdparm" boosted throughput to ~450MB/s. Much better, but<br>
still sad.<br>
<br>
In the second measure the volume data passes through iSCSI and then the<br>
QEMU hypervisor. I expected to lose some performance, but not more than<br>
half!<br>
<br>
Note that as this is an all-in-one OpenStack node, iSCSI is strictly<br>
local and not crossing a network. (I did not want network latency or<br>
throughput to be a concern with this first measure.)<br>
</blockquote>
<br></span>
Well, not crossing a physical network :)  You will be however likely crossing the loopback network on the node.<br></blockquote><div><br></div><div>Well ... yes. I suspect the latency and bandwidth numbers for loopback are rather better. :)<br><br>For the purposes of this experiment, I wanted to eliminate the physical network limits as a consideration.<br><br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
What sort of per-CPU utilizations do you see when running the test to the instance?  Also, out of curiosity, what block size are you using in dd?  I wonder how well that "maps" to what iSCSI will be doing.<br></blockquote><div><br></div><div>First, this measure was collected via a script that tried a moderately exhaustive number of variations. Yes, I had the same question. Kernel host read-ahead is 6MB (automatically set). Did not see notable gain past "bs=2M". (Was expecting a bigger gain for larger reads, but not what measures showed.)<br><br></div><div><br></div></div></div></div>