Thursday, 2018-11-29

*** bobh has joined #openstack-vitrage03:35
*** bobh has quit IRC03:41
*** eyalb has joined #openstack-vitrage06:21
*** e0ne has joined #openstack-vitrage07:10
*** ifat_afek has joined #openstack-vitrage07:23
*** openstackgerrit has joined #openstack-vitrage07:24
openstackgerritIdan Hefetz proposed openstack/vitrage master: WIP  - Api performance enhancements  https://review.openstack.org/62079507:24
openstackgerritIdan Hefetz proposed openstack/vitrage master: WIP  - Api performance enhancements  https://review.openstack.org/61962307:24
e0neifat_afek: hi. do you know if Idan usually connected to IRC? I've got some questions according his patch09:01
eyalbI told him to connect09:02
*** idan_hefetz has joined #openstack-vitrage09:03
idan_hefetzHi!09:03
idan_hefetzwhats up?09:03
e0neeyalb: thanks09:04
e0neidan_hefetz: I09:04
idan_hefetzhi e0ne09:04
e0neidan_hefetz: I'm looking on your patch with API performance improvements09:04
idan_hefetzcool, thanks, still in progress though09:05
e0neI"m worried about garbage collector configuration09:05
idan_hefetzOK, i will try to explain the logic09:05
e0neit could lead to some  performance issue during garbage collecting09:06
idan_hefetzOn a large scale environment - topology returns large amounts of data that is a single string that is very big. I wanted to configure the GC to collect even if there is only one collectable object. this is done only in vitrage-api service09:08
e0nedo you have an example of such data?09:09
idan_hefetzI have tested this on a large scale, and it prevents vitrage-api memory usage to create large peaks for every api (a peak of additional 1-2 gb)09:10
e0neI understand the reason and the root cause09:11
e0nethe issues is we'll have GC.collect call on the each API which could lead to high CPU usage09:12
e0necan we use weakref instead of tweaking GC?09:13
idan_hefetzMemory is mainly used and held by oslo.messaging09:13
idan_hefetzAlso i'm not very familiar with weak ref09:14
idan_hefetzAre you worried about the "gc.set_threshold(1, 1, 1)"  or about the gc.collect() per each API? or both :)?09:15
e0neI'm worried about both of these calls09:16
idan_hefetzI have not thought of all the implications of these, but I feel comfortable as these are only in vitrage-api and I have tested it under load.09:18
e0nedid you measure CPU usage and API response time too?09:19
idan_hefetzI measured API response time, which this commit is mostly about09:20
idan_hefetzI think the GC does not have allot of objects to collect, problem is the we have few large objects that need to be collected.09:21
idan_hefetzSo it shouldn't work to hard.09:22
idan_hefetztoo09:22
e0nesounds reasonable09:22
idan_hefetzOK, cheers, alyway I will look into weakref and consider if it can be of use here..09:25
e0nethanks. I'll test your patch later this week09:26
idan_hefetzThat'll be great, thanks!09:27
*** idan_hefetz has quit IRC10:01
*** ifat_afek has quit IRC10:06
*** ifat_afek has joined #openstack-vitrage11:06
*** e0ne has quit IRC12:53
*** ifat_afek has quit IRC12:57
*** e0ne has joined #openstack-vitrage13:31
*** bobh has joined #openstack-vitrage14:09
openstackgerritIdan Hefetz proposed openstack/vitrage master: WIP  - Api performance enhancements  https://review.openstack.org/61962314:59
*** eyalb has quit IRC15:19
*** e0ne has quit IRC16:26
*** e0ne has joined #openstack-vitrage16:38
*** e0ne has quit IRC16:48
openstackgerritMerged openstack/vitrage master: Bug fix: delete outdated entities for OpenStack datasources  https://review.openstack.org/61956616:55
*** bobh has quit IRC18:12
*** e0ne has joined #openstack-vitrage20:20
*** e0ne has quit IRC20:30
*** ifat_afek has joined #openstack-vitrage21:26
*** ifat_afek has quit IRC22:01

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!