<div dir="ltr">Hi Jan,<div><br></div><div>Just curious after reading valuable inputs from others and you, In what OS are you seeing performance degradation Ubuntu 20.04 LTS or Ubuntu 22.04 LTS? Soon I am going to build some compute nodes using NvME and am looking for the right OS/kernel combo for better performance.  </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 21, 2023 at 9:59 AM <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2023-08-21 at 15:06 +0200, Jan Wasilewski wrote:<br>
> Hi,<br>
> <br>
> Let me add a few points. Lastly, I decided to conduct a couple of tests<br>
> with the newer OpenStack platform - Zed (built by the kolla-ansible<br>
> project). This platform serves Ubuntu 22.04 LTS on top of my compute nodes.<br>
> The results were surprising, particularly because I was able to achieve the<br>
> desired outcomes.<br>
> <br>
> My compute node was equipped with 2 SSDs and 2 NVMe disks. As a preliminary<br>
> step, I used SSD drives for testing. The fio test yielded a result of<br>
> approximately 90k IOPS for the local SSD drive [1], employing<br>
> IvyBridge-IBRS as the cpu_model parameter. When I transitioned to<br>
> Cascadelake-Server, I managed to exceed 100k IOPS [2]. Interestingly, when<br>
> I conducted an identical test with NVMe drives, the performance was only<br>
> slightly above 90k IOPS [3]. This suggests that NVMe drives are marginally<br>
> slower than SSD drives for local storage when used by VMs.<br>
> <br>
> For the final test, I executed the fio test on the NVMe mounting point,<br>
> achieving around 140k IOPS [4].<br>
> <br>
> In summary, it appears that the choice of Ubuntu version as the base for<br>
> compute nodes has a significant impact on performance (Ubuntu 20.04 LTS vs.<br>
> Ubuntu 22.04 LTS). In my opinion, a kernel parameter seems to be<br>
> responsible for constraining the performance within the VM (more precisely,<br>
> the "drive file" serving as local storage for the VM). However, I'm<br>
> uncertain about which specific parameter(s) are at play. I intend to delve<br>
> deeper into this matter, but I'm open to any suggestions you may have.<br>
thanks for reporting your observation.<br>
this may or may not be kernel related if you are using diffent version fo QEMU between<br>
each ubuntu release.<br>
if its the same version then this may indeed be related to kernel change but it may not<br>
be with parmater. rather it could be with change to the filesystem that may have improved<br>
performance for vm workloads. it could also be related to enhancements with some of the<br>
kernel mitigation that are used or a number of other factors. 20.04 to 22.04 is a large<br>
leap and there are alot of changes even if you are deploying the same version of openstack<br>
using package form the cloud archive on 20.04,<br>
<br>
if you want to get the highest possible performance in the guest instead of setting<br>
a virutral cpu model you should set <br>
[libvirt]<br>
cpu_mode=host-passthrough<br>
<br>
instead of <br>
[libvirt]<br>
cpu_mode=custom<br>
cpu_models=Cascadelake-Server<br>
<br>
the down side to using host-passthrough is you will only be able to live migrate to servers<br>
with the exact same model of cpu. if all your cpus are the same or you can sub devied<br>
your cloud into sets of host with the same cpu sku i.e. via host aggrates and filters/traits <br>
then that's not really an issue.<br>
<br>
<br>
if you do find a kernel parmater to acchive the same performacne on 20.04 please let us<br>
know but i suspect its a combination of things that have change between both releases<br>
rhater then a single thing.<br>
<br>
> <br>
> /Jan Wasilewski<br>
> *References:*<br>
> *[1] fio results for IvyBridge and SSDs:<br>
> <a href="https://paste.openstack.org/show/bUCoXBUbImd9JxplPBbv/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bUCoXBUbImd9JxplPBbv/</a><br>
> <<a href="https://paste.openstack.org/show/bUCoXBUbImd9JxplPBbv/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bUCoXBUbImd9JxplPBbv/</a>>*<br>
> *[2] fio results for Cascadelake-Server and SSDs:<br>
> <a href="https://paste.openstack.org/show/bWxDkM5ITcMTlFWe4GiZ/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bWxDkM5ITcMTlFWe4GiZ/</a><br>
> <<a href="https://paste.openstack.org/show/bWxDkM5ITcMTlFWe4GiZ/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bWxDkM5ITcMTlFWe4GiZ/</a>>*<br>
> *[3] fio results for Cascadelake-Server and NVMe:<br>
> <a href="https://paste.openstack.org/show/bbINpvkNZcJcY0KP0vPo/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bbINpvkNZcJcY0KP0vPo/</a><br>
> <<a href="https://paste.openstack.org/show/bbINpvkNZcJcY0KP0vPo/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bbINpvkNZcJcY0KP0vPo/</a>>*<br>
> *[4] fio results for mounting point of NVMe:<br>
> <a href="https://paste.openstack.org/show/bTchYOYY3zNpSLPfOpQl/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bTchYOYY3zNpSLPfOpQl/</a><br>
> <<a href="https://paste.openstack.org/show/bTchYOYY3zNpSLPfOpQl/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bTchYOYY3zNpSLPfOpQl/</a>>*<br>
> <br>
> czw., 17 sie 2023 o 12:16 Jan Wasilewski <<a href="mailto:finarffin@gmail.com" target="_blank">finarffin@gmail.com</a>> napisał(a):<br>
> <br>
> > Hi,<br>
> > <br>
> > First and foremost, I want to express my heartfelt gratitude for all the<br>
> > invaluable insights you've provided. I meticulously studied and conducted<br>
> > numerous tests based on your inputs. While I've managed to implement<br>
> > certain enhancements, I'd like to delve into those improvements in an<br>
> > upcoming section. For now, let me address your queries.<br>
> > <br>
> > Regarding the number of concurrent VMs operating on the OpenStack<br>
> > hypervisor:<br>
> > <br>
> >    - Presently, there is a sole VM running on this compute node,<br>
> >    occasionally there might be two instances. The compute node remains largely<br>
> >    underutilized, primarily earmarked for my performance assessments. It's<br>
> >    equipped with a 24-core Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz,<br>
> >    alongside a MemTotal of 48988528 kB. Thus far, I haven't detected any red<br>
> >    flags. Even during the execution of fio tests within my VMs, there is no<br>
> >    discernible surge in load.<br>
> > <br>
> > To @smooney: In relation to ide and virtio, I undertook a secondary test,<br>
> > meticulously duplicating the attachment methodology, and the outcomes are<br>
> > akin. Please refer to [1] and [2].<br>
> > <br>
> > Nevertheless, as per your recommendation, I explored hw_pmu; however, the<br>
> > outcomes remained consistent. Find the results with hw_pmu disabled in [3],<br>
> > [4], and [5], and contrasting results with hw_pmu enabled in [6], [7], and<br>
> > [8].<br>
> > <br>
> > Nonetheless, I did experience a substantial performance escalation, albeit<br>
> > solely for a manually attached disk—a comprehensive drive, not the disk<br>
> > associated with the VM as a singular file [9]. The solitary alteration<br>
> > involved configuring my cpu_model in nova.conf from IvyBridge to<br>
> > Cascadelake-Server-noTSX. Even though I achieved approximately 110k iOPS<br>
> > for the fully attached disk [10], the file-attached disk retained around<br>
> > 19k iOPS [11], with comparable performance evident for the root disk [12].<br>
> > The latter is also a solitary file, albeit located on a distinct drive of<br>
> > the same model. For your perusal, I've appended all relevant dumpxml data<br>
> > [13]. In summation, it seems that the cpu_model significantly influences<br>
> > performance enhancement, though this effect is not replicated for a "file<br>
> > disk." The query thus stands: how can we elevate performance for a file<br>
> > disk?<br>
> > <br>
> > Might you be willing to share the fio benchmark outcomes from your local<br>
> > storage configuration? I'm curious to ascertain whether our results align,<br>
> > or if there's a concealed optimization path I have yet to uncover. I<br>
> > sincerely appreciate all the assistance you've extended thus far.<br>
> > /Jan Wasilewski<br>
> > <br>
> > *References:*<br>
> > *[1] virtio connected via virsh attach-volume to Openstack instance(<80k<br>
> > iOPS): <a href="https://paste.openstack.org/show/bHqZZWdAwWVYh1rHaIgC/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bHqZZWdAwWVYh1rHaIgC/</a><br>
> > <<a href="https://paste.openstack.org/show/bHqZZWdAwWVYh1rHaIgC/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bHqZZWdAwWVYh1rHaIgC/</a>>*<br>
> > *[2] virtio connected via virsh attach-volume to Openstack instance<br>
> > dumpxml: <a href="https://paste.openstack.org/show/bvEsKiwBd8lL4AUPSOxj/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bvEsKiwBd8lL4AUPSOxj/</a><br>
> > <<a href="https://paste.openstack.org/show/bvEsKiwBd8lL4AUPSOxj/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bvEsKiwBd8lL4AUPSOxj/</a>>*<br>
> > *[3] hw_pmu: False: fio - root disk:<br>
> > <a href="https://paste.openstack.org/show/bAZXQOUrkmVBsJ7yBEql/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bAZXQOUrkmVBsJ7yBEql/</a><br>
> > <<a href="https://paste.openstack.org/show/bAZXQOUrkmVBsJ7yBEql/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bAZXQOUrkmVBsJ7yBEql/</a>>*<br>
> > *[4] hw_pmu: False: fio - attached nvme disk:<br>
> > <a href="https://paste.openstack.org/show/bF1P0qsVG24duuY8F6HV/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bF1P0qsVG24duuY8F6HV/</a><br>
> > <<a href="https://paste.openstack.org/show/bF1P0qsVG24duuY8F6HV/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bF1P0qsVG24duuY8F6HV/</a>>*<br>
> > *[5] hw_pmu: False: dumpxml:<br>
> > <a href="https://paste.openstack.org/show/b8Yxf5DmPmAxxA070DL1/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/b8Yxf5DmPmAxxA070DL1/</a><br>
> > <<a href="https://paste.openstack.org/show/b8Yxf5DmPmAxxA070DL1/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/b8Yxf5DmPmAxxA070DL1/</a>>*<br>
> > *[6] hw_pmu: True: fio - root disk:<br>
> > <a href="https://paste.openstack.org/show/b7jJ7gR2e9VAAXm1e9PP/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/b7jJ7gR2e9VAAXm1e9PP/</a><br>
> > <<a href="https://paste.openstack.org/show/b7jJ7gR2e9VAAXm1e9PP/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/b7jJ7gR2e9VAAXm1e9PP/</a>>*<br>
> > *[7] hw_pmu: True: fio - attached nvme disk(82,5k iOPS) :<br>
> > <a href="https://paste.openstack.org/show/bCrdOnwxrJS6hENxTMK5/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bCrdOnwxrJS6hENxTMK5/</a><br>
> > <<a href="https://paste.openstack.org/show/bCrdOnwxrJS6hENxTMK5/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bCrdOnwxrJS6hENxTMK5/</a>>*<br>
> > *[8] hw_pmu: True: dumpxml:<br>
> > <a href="https://paste.openstack.org/show/b8Yxf5DmPmAxxA070DL1/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/b8Yxf5DmPmAxxA070DL1/</a><br>
> > <<a href="https://paste.openstack.org/show/b8Yxf5DmPmAxxA070DL1/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/b8Yxf5DmPmAxxA070DL1/</a>>*<br>
> > *[9] Instruction how to add a "file disk" to kvm instance:<br>
> > <a href="https://www.cyberciti.biz/faq/how-to-add-disk-image-to-kvm-virtual-machine-with-virsh-command/" rel="noreferrer" target="_blank">https://www.cyberciti.biz/faq/how-to-add-disk-image-to-kvm-virtual-machine-with-virsh-command/</a><br>
> > <<a href="https://www.cyberciti.biz/faq/how-to-add-disk-image-to-kvm-virtual-machine-with-virsh-command/" rel="noreferrer" target="_blank">https://www.cyberciti.biz/faq/how-to-add-disk-image-to-kvm-virtual-machine-with-virsh-command/</a>>*<br>
> > *[10] cpu_model: Cascadelake-Server-noTSX fio - attached nvme disk(almost<br>
> > 110k iOPS): <a href="https://paste.openstack.org/show/bdKQIgNIH0dy8PLhAIKq/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bdKQIgNIH0dy8PLhAIKq/</a><br>
> > <<a href="https://paste.openstack.org/show/bdKQIgNIH0dy8PLhAIKq/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bdKQIgNIH0dy8PLhAIKq/</a>>*<br>
> > *[11] cpu_model: Cascadelake-Server-noTSX fio - "file disk":<br>
> > <a href="https://paste.openstack.org/show/bjBmPBXi35jWdyJ1cjQt/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bjBmPBXi35jWdyJ1cjQt/</a><br>
> > <<a href="https://paste.openstack.org/show/bjBmPBXi35jWdyJ1cjQt/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bjBmPBXi35jWdyJ1cjQt/</a>>*<br>
> > *[12] cpu_model: Cascadelake-Server-noTSX fio - root disk:<br>
> > <a href="https://paste.openstack.org/show/br49T918vNU5NJXfXYGm/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/br49T918vNU5NJXfXYGm/</a><br>
> > <<a href="https://paste.openstack.org/show/br49T918vNU5NJXfXYGm/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/br49T918vNU5NJXfXYGm/</a>>*<br>
> > *[13] cpu_model: Cascadelake-Server-noTSX dumpxml:<br>
> > <a href="https://paste.openstack.org/show/bns2rWIHCHIWbrR9LUD0/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bns2rWIHCHIWbrR9LUD0/</a><br>
> > <<a href="https://paste.openstack.org/show/bns2rWIHCHIWbrR9LUD0/" rel="noreferrer" target="_blank">https://paste.openstack.org/show/bns2rWIHCHIWbrR9LUD0/</a>>*<br>
> > <br>
<br>
<br>
</blockquote></div>