<div dir="ltr">Repeated the test with 1000 ports this time. See attached image.<div>For some reason, the sizes grow while deleting the ports (the</div><div>deletion task starts at around x=2500). The weird thing is why</div><div>they keep growing and the online compact doesn&#39;t work as when</div><div>I do it through ovs-appctl tool.</div><div><br></div><div>I suspect this is a bug and eventually it will grow and grow unless</div><div>we manually compact the db.</div><div><br></div><div>NB database:</div><div><div>2018-03-07T13:50:33.671Z|00058|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519121698.545 seconds old, 69 transactions)</div><div>2018-03-07T14:38:35.518Z|00059|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519118104.064 seconds old, 436 transactions)</div><div>2018-03-07T14:48:35.589Z|00060|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115822.254 seconds old, 386 transactions)</div><div>2018-03-07T14:58:37.155Z|00061|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115823.488 seconds old, 353 transactions)</div><div>2018-03-07T15:08:39.030Z|00062|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115823.975 seconds old, 415 transactions)</div><div>2018-03-07T15:18:40.348Z|00063|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115823.413 seconds old, 393 transactions)</div><div>2018-03-07T15:28:45.405Z|00064|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115827.054 seconds old, 141 transactions)</div><div><div>2018-03-07T15:38:52.894Z|00082|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115825.353 seconds old, 134 transactions)</div><div>2018-03-07T15:48:54.079Z|00083|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115823.297 seconds old, 155 transactions)</div><div>2018-03-07T15:58:57.185Z|00084|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115825.234 seconds old, 177 transactions)</div><div>2018-03-07T16:08:58.955Z|00085|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db: compacting database online (1519115823.913 seconds old, 213 transactions)</div></div></div><div><br></div><div>SB database:</div><div><div>2018-03-07T13:32:21.672Z|00022|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db: compacting database online (1519124364.908 seconds old, 951 transactions)</div><div>2018-03-07T14:47:40.293Z|00023|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db: compacting database online (1519119740.823 seconds old, 776 transactions)</div><div>2018-03-07T15:05:10.797Z|00024|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db: compacting database online (1519116272.507 seconds old, 666 transactions)</div><div>2018-03-07T15:33:49.467Z|00025|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db: compacting database online (1519116940.094 seconds old, 748 transactions)</div></div><div><br></div><div>When compacting the DB&#39;s manually they shrink a lot:</div><div><br></div><div><div>[stack@ovn ovs]$ ls -alh ovn*.db</div><div>-rw-r--r--. 1 stack stack 9.5M Mar  7 16:17 ovnnb_db.db</div><div>-rw-r--r--. 1 stack stack  32M Mar  7 16:17 ovnsb_db.db</div><div>[stack@ovn ovs]$ sudo ovs-appctl -t /usr/local/var/run/openvswitch/ovnnb_db.ctl ovsdb-server/compact                                                                                          </div><div>[stack@ovn ovs]$ sudo ovs-appctl -t /usr/local/var/run/openvswitch/ovnsb_db.ctl ovsdb-server/compact</div><div>[stack@ovn ovs]$ ls -alh ovn*.db</div><div>-rw-r--r--. 1 stack stack  39K Mar  7 16:52 ovnnb_db.db</div><div>-rw-r--r--. 1 stack stack 207K Mar  7 16:52 ovnsb_db.db</div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 7, 2018 at 3:42 PM, Daniel Alvarez Sanchez <span dir="ltr">&lt;<a href="mailto:dalvarez@redhat.com" target="_blank">dalvarez@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Right, thanks Mark! Good point about the 4x, I missed that one.<div>I&#39;m repeating the test for 1K ports. Not sure if I&#39;ll be able to reproduce</div><div>the 2.5GB part but it is still weird that while deleting ports (actually</div><div>deleting stuff from the DB) it doesn&#39;t get to compact the DB further</div><div>(last time it shrinked to 9MB) so maybe we have something odd here</div><div>going in the online compact. I&#39;ll post the results after this test.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 7, 2018 at 3:35 PM, Mark Michelson <span dir="ltr">&lt;<a href="mailto:mmichels@redhat.com" target="_blank">mmichels@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-2101733497362657887HOEnZb"><div class="m_-2101733497362657887h5">On 03/07/2018 07:40 AM, Daniel Alvarez Sanchez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks,<br>
<br>
During the performance tests I&#39;ve been doing lately I noticed<br>
that the size of the Southbound database was around 2.5GB<br>
in one of my setups. I couldn&#39;t dig further then but now I<br>
decided to explore a bit more and these are the results in<br>
my all-in-one OpenStack setup using OVN as a backend:<br>
<br>
* Created 800 ports on the same network (logical switch).<br>
* Deleted those 800 ports.<br>
* I logged the DB sizes for both NB and SB databases every second.<br>
<br>
See attached image for the results.<br>
<br>
At around x=2000, the creation task finished and deletion starts.<br>
As you can see, there&#39;s automatic compact happening in the<br>
NB database across the whole test. However, while I was deleting<br>
ports, the SB database stop shrinking and keeps growing.<br>
<br>
After the test finished, the DB sizes remaining the same<br>
thus SB database being around 34MB. It was not until I<br>
manually compacted it when it finally shrinked:<br>
<br>
<br>
[stack@ovn ovs]$ ls -alh ovnsb_db.db<br>
-rw-r--r--. 1 stack stack 34M Mar  7 12:04 ovnsb_db.db<br>
<br>
[stack@ovn ovs]$ sudo ovs-appctl -t /usr/local/var/run/openvswitch<wbr>/ovnsb_db.ctl ovsdb-server/compact<br>
<br>
[stack@ovn ovs]$ ls -alh ovnsb_db.db<br>
-rw-r--r--. 1 stack stack 207K Mar  7 13:32 ovnsb_db.db<br>
<br>
I&#39;ll try to investigate further in the code.<br>
Thanks,<br>
<br>
Daniel<br>
</blockquote>
<br></div></div>
Daniel and I discussed this offline and I think the attached result does not necessarily indicate a bug yet.<br>
<br>
One of the requirements for the DB to compact automatically is that it needs to grow to at least 4x the size of the previous snapshot. In the graph, we can see that the first time the SB DB compacts (around x==1000), it shrinks down to ~5MB. We would expect the DB to compact again when it gets to ~20MB. This happens at around x==1900. The DB shrinks to ~9MB, so we would expect it to shrink again when it reaches ~36MB. When the test ends, the SB DB is ~34 MB, so it is not quite large enough to compact yet. If the test had gone a bit longer, then presumably we might have seen the DB shrink again.<br>
<br>
It will be interesting to see the test that leads to a 2.5GB southbound database.<span class="m_-2101733497362657887HOEnZb"><font color="#888888"><br>
<br>
Mark!<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>