<div dir="ltr"><div>Hmm... I am not sure if it is normal. In our environment with even larger scale (in terms of number of ports), the memory is usually less than 1GB for each ovsdb-server process, and we didn't see symptom of memory leak (after months of clustered mode deployment in live environment).<br></div><div><br></div><div>Could you check which DB (NB or SB) is the major memory consumer? If it is SB DB, it is normal to see memory spike for the first time you switch from standalone mode to clustered mode if you have big number of compute nodes connected to SB DB. After it stablizes, the memory footprint should decrease. Of course it is possible that you have more complex scenarios that triggers more memory consumption (or memory leak). Could you try with a server with more memory (to avoid OOM killer), to see if it stablizes at some point or just keep increasing day after day?<br></div><div><br></div><div>Besides, I believe Ben has some better trouble shooting steps for memory issues of ovsdb-server. Ben, could you suggest?</div><div><br></div><div>Thanks,</div><div>Han<br></div><div><br>On Sun, Dec 15, 2019 at 9:56 PM 刘梦馨 <<a href="mailto:liumengxinfly@gmail.com">liumengxinfly@gmail.com</a>> wrote:<br>><br>> After more iteration (6 in my environment) the rss usage stabilized in 759128KB.<br>><br>> This is a really simplified test, in our real environment we run about 3000 containers and with lots other operations, like set route, loadbalancer, all the ovn-sb operations etc. The memory consumption can quickly go up to 6GB (nb and sb together) and lead a system OOM.  Is that a reasonable resource consumption in your experience? I didn't remember the actual numbers of standalone db resource consumption, however in the same environment, it didn't lead to an OOM.<br>><br>> Han Zhou <<a href="mailto:hzhou@ovn.org">hzhou@ovn.org</a>> 于2019年12月16日周一 下午1:05写道:<br>>><br>>> Thanks for the details. I tried the same command with a for loop.<br>>><br>>> After the first 4 iterations, the RSS of the first NB server increased to 572888 (KB). After that, it stayed the same in the next 3 iterations. So it seems to just build memory buffers up and then stayed at the level without further increasing and doesn't seem to be memory leaking. Could you try more iterations and see if it still continuously increase?<br>>><br>>> Thanks,<br>>> Han<br>>><br>>> On Sun, Dec 15, 2019 at 7:54 PM 刘梦馨 <<a href="mailto:liumengxinfly@gmail.com">liumengxinfly@gmail.com</a>> wrote:<br>>> ><br>>> > Hi, Han<br>>> ><br>>> > In my test scenario, I use ovn-ctl to start a one node ovn with cluster mode db and no chassis bind to the ovn-sb to just check the memory usage of ovn-nb.<br>>> > Then use a script to add a logical switch, add 1000 ports, set dynamic addresses and then delete the logical switch.<br>>> ><br>>> > #!/bin/bash<br>>> > ovn-nbctl ls-add ls1<br>>> > for i in {1..1000}; do<br>>> >   ovn-nbctl lsp-add ls1 ls1-vm$i<br>>> >   ovn-nbctl lsp-set-addresses ls1-vm$i dynamic<br>>> > done<br>>> > ovn-nbctl ls-del ls1<br>>> ><br>>> > I run this script repeatedly and watch the memory change.<br>>> ><br>>> > After 5 runs (5000 lsp add and delete), the rss of nb increased to 667M.<br>>> > The nb file increased to 119M and didn't automatically compacted. After a manually compact the db file size change back to 11K, but the memory usage didn't change.<br>>> ><br>>> ><br>>> ><br>>> > Han Zhou <<a href="mailto:hzhou@ovn.org">hzhou@ovn.org</a>> 于2019年12月14日周六 上午3:40写道:<br>>> >><br>>> >><br>>> >><br>>> >> On Wed, Dec 11, 2019 at 12:51 AM 刘梦馨 <<a href="mailto:liumengxinfly@gmail.com">liumengxinfly@gmail.com</a>> wrote:<br>>> >> ><br>>> >> ><br>>> >> > We are using ovs/ovn 2.12.0 to implementing our container network. After switching form standalone ovndb to cluster mode ovndb, we noticed that the memory consumption for both ovnnb and ovnsb will keep increasing after each operation and never decrease.<br>>> >> ><br>>> >> > We did some profiling by valgrind. The leak check report a 16 byte leak in fork_and_wait_for_startup, which obviously is not the main reason. Later we use memif to profile the memory consumption and we put the result in the attachment.<br>>> >> ><br>>> >> > Most of the memory come from two part ovsthread_wrapper (ovs-thread.c:378) that allocates a subprogram_name and  jsonrpc_send (jsonrpc.c:253) as below, (I just skipped the duplicated stack of jsonrpc).<br>>> >> ><br>>> >> > However I found both part have a related free operation in near place, so I don't know how to further explore this memory issue. I'm not aware of the differences here between cluster mode and standalone mode.<br>>> >> ><br>>> >> > Can anyone give some advice and hint? Thanks!<br>>> >> ><br>>> >> > 100.00% (357,920,768B) (page allocation syscalls) mmap/mremap/brk, --alloc-fns, etc.<br>>> >> > ->78.52% (281,038,848B) 0x66FDD49: mmap (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | ->37.50% (134,217,728B) 0x66841EF: new_heap (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | | ->37.50% (134,217,728B) 0x6684C22: arena_get2.isra.3 (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | |   ->37.50% (134,217,728B) 0x668AACC: malloc (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | |     ->37.50% (134,217,728B) 0x4FDC613: xmalloc (util.c:138)<br>>> >> > | |       ->37.50% (134,217,728B) 0x4FDC78E: xvasprintf (util.c:202)<br>>> >> > | |         ->37.50% (134,217,728B) 0x4FDC877: xasprintf (util.c:343)<br>>> >> > | |           ->37.50% (134,217,728B) 0x4FA548D: ovsthread_wrapper (ovs-thread.c:378)<br>>> >> > | |             ->37.50% (134,217,728B) 0x5BE5E63: start_thread (in /usr/lib64/<a href="http://libpthread-2.17.so">libpthread-2.17.so</a>)<br>>> >> > | |               ->37.50% (134,217,728B) 0x670388B: clone (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | |<br>>> >> > | ->36.33% (130,023,424B) 0x6686DF3: sysmalloc (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | | ->36.33% (130,023,424B) 0x6687CA8: _int_malloc (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | |   ->28.42% (101,711,872B) 0x66890C0: _int_realloc (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | |   | ->28.42% (101,711,872B) 0x668B160: realloc (in /usr/lib64/<a href="http://libc-2.17.so">libc-2.17.so</a>)<br>>> >> > | |   |   ->28.42% (101,711,872B) 0x4FDC9A3: xrealloc (util.c:149)<br>>> >> > | |   |     ->28.42% (101,711,872B) 0x4F1DEB2: ds_reserve (dynamic-string.c:63)<br>>> >> > | |   |       ->28.42% (101,711,872B) 0x4F1DED3: ds_put_uninit (dynamic-string.c:73)<br>>> >> > | |   |         ->28.42% (101,711,872B) 0x4F1DF0B: ds_put_char__ (dynamic-string.c:82)<br>>> >> > | |   |           ->26.37% (94,371,840B) 0x4F2B09F: json_serialize_string (dynamic-string.h:93)<br>>> >> > | |   |           | ->12.01% (42,991,616B) 0x4F2B3EA: json_serialize (json.c:1651)<br>>> >> > | |   |           | | ->12.01% (42,991,616B) 0x4F2B3EA: json_serialize (json.c:1651)<br>>> >> > | |   |           | |   ->12.01% (42,991,616B) 0x4F2B3EA: json_serialize (json.c:1651)<br>>> >> > | |   |           | |     ->12.01% (42,991,616B) 0x4F2B540: json_serialize (json.c:1626)<br>>> >> > | |   |           | |       ->12.01% (42,991,616B) 0x4F2B540: json_serialize (json.c:1626)<br>>> >> > | |   |           | |         ->12.01% (42,991,616B) 0x4F2B540: json_serialize (json.c:1626)<br>>> >> > | |   |           | |           ->12.01% (42,991,616B) 0x4F2B540: json_serialize (json.c:1626)<br>>> >> > | |   |           | |             ->12.01% (42,991,616B) 0x4F2B3EA: json_serialize (json.c:1651)<br>>> >> > | |   |           | |               ->12.01% (42,991,616B) 0x4F2B540: json_serialize (json.c:1626)<br>>> >> > | |   |           | |                 ->12.01% (42,991,616B) 0x4F2D82A: json_to_ds (json.c:1525)<br>>> >> > | |   |           | |                   ->12.01% (42,991,616B) 0x4F2EA49: jsonrpc_send (jsonrpc.c:253)<br>>> >> > | |   |           | |                     ->12.01% (42,991,616B) 0x4C3A68A: ovsdb_jsonrpc_server_run (jsonrpc-server.c:1104)<br>>> >> > | |   |           | |                       ->12.01% (42,991,616B) 0x10DCC1: main (ovsdb-server.c:209)<br>>> >> ><br>>> >> > _______________________________________________<br>>> >> > discuss mailing list<br>>> >> > <a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a><br>>> >> > <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>>> >><br>>> >> Thanks for reporting the issue. Could you describe your test scenario (the operations), the scale, the db file size and the memory (RSS) data of the NB/SB?<br>>> >> Clustered mode maintains some extra data such as RAFT logs, compares to standalone, but it should not increase forever, because RAFT logs will get compacted periodically.<br>>> >><br>>> >> Thanks,<br>>> >> Han<br>>> ><br>>> ><br>>> ><br>>> > --<br>>> > 刘梦馨<br>>> > Blog: <a href="http://oilbeater.com">http://oilbeater.com</a><br>>> > Weibo: @oilbeater<br>><br>><br>><br>> --<br>> 刘梦馨 <br>> Blog: <a href="http://oilbeater.com">http://oilbeater.com</a><br>> Weibo: @oilbeater</div></div>