16:00:01 #startmeeting Performance Team 16:00:02 Meeting started Tue Mar 15 16:00:01 2016 UTC and is due to finish in 60 minutes. The chair is DinaBelova. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:05 The meeting name has been set to 'performance_team' 16:00:08 o/ 16:00:18 o/ 16:00:28 o/ 16:00:57 rohanion, are you around? :) 16:01:24 let's wait for a few moments 16:01:37 yes 16:01:42 hello everyone! 16:01:45 yay! 16:01:56 well, I think we may start with action items 16:02:07 #topic Action Items 16:02:14 #link http://eavesdrop.openstack.org/meetings/performance_team/2016/performance_team.2016-03-01-16.00.html 16:02:20 ok, last time we had few ones 16:02:34 I'll start with my idea to propose two times for this meeting 16:02:42 US and European friendly 16:02:57 I decided to postpone this proposal due to daylight savings time in US 16:03:07 not to mix even more current schedule 16:03:12 that's UTC-based 16:03:30 so let's postpone this for a while and see if current time is ok or not for our US folks 16:03:44 so I'll leave this item on myself 16:03:51 #action DinaBelova propose to have to times for this meeting to openstack-dev - US and Europe/China friendly and switch them on weekly basis 16:03:59 going to ilyashakhat 16:04:21 ilyashakhat: were you able to move performa to openstack/* github namespace? 16:04:32 not yet 16:04:41 the patch is in infra queue 16:04:49 and has one +2 already 16:04:52 link please :) 16:05:02 https://review.openstack.org/291657 16:05:09 #link https://review.openstack.org/291657 16:05:22 ok, so let's just leave this action item not to miss it next time 16:05:42 #action ilyashakhat move Performa to openstack space (final steps) 16:05:57 as for kun_huang's change 16:06:14 I've seen he updated it, but there are no (yet) details about lab HW 16:06:25 due to the fact lab is still under building stage 16:06:53 so I decided to keep this change https://review.openstack.org/#/c/280843 on review till this will be finalized 16:07:14 #action kun_huang update https://review.openstack.org/#/c/280843 once lab HW details will be available 16:07:18 btw 16:07:32 AugieMena: here is short HW description on Mirantis-Intel lab https://review.openstack.org/#/c/292835/3 16:07:36 of* 16:08:08 we're going to publish some test results soon, so uploaded the description of where are we running these tests 16:08:17 ok, so going to final action item 16:08:26 rohanion ozamiatin__ - the floor is yours 16:08:48 may you please share details about 0MQ driver socet consumption improvement? 16:08:53 socket* 16:08:53 DinaBelova, thanks, let rohanion begin 16:09:09 ok thank you 16:09:35 rohanion and link to the bug please, if any 16:09:38 sure 16:09:53 1 minute 16:10:10 https://bugs.launchpad.net/oslo.messaging/+bug/1555007 16:10:10 Launchpad bug 1555007 in oslo.messaging "[zmq] ZMQ driver eats too many TCP sockets" [Undecided,In progress] - Assigned to Oleksii Zamiatin (ozamiatin) 16:10:13 this one? 16:10:21 yes, thanks! 16:10:22 #link https://bugs.launchpad.net/oslo.messaging/+bug/1555007 16:10:48 ok, so any ideas how to deal with it? 16:11:47 We've created a patchset which disables pub/sub listening 16:12:19 and we've reduced the number of oslo-messaging-zmq-receiver processes to three, one per controller node 16:13:05 DinaBelova, rohanion: currently we have all services connected directly to each other which finally gives us full-mesh topology, my proposal is to start using of lightweight proxies which will reduce number of sockets 16:13:12 after measuring the number of used sockets with these patches enabled 16:13:49 ozamiatin__ - yeah, that was basement idea you folks proposed last time 16:14:13 we saw that the controllers use 7000 less sockets - 28k vs 35k 16:14:48 DinaBelova, rohanion: yes, the drawback is loose on perfomance, so we need to test what performance degrade we will get finally 16:14:58 ozamiatin__ indeed 16:15:11 ozamiatin__, rohanion - when are you going to test this proxy approach? 16:15:29 DinaBelova, rohanion: I'm planning to finalize implementing it this week 16:15:36 ozamiatin__ ack 16:16:04 probably we won't even outperform rabbitmq but our solution should me more scalable than rabbitmq 16:16:17 #info work on https://bugs.launchpad.net/oslo.messaging/+bug/1555007 most probably should be finished ~March 18th 16:16:17 Launchpad bug 1555007 in oslo.messaging "[zmq] ZMQ driver eats too many TCP sockets" [Undecided,In progress] - Assigned to Oleksii Zamiatin (ozamiatin) 16:16:20 s/me/be/ 16:16:24 ack 16:16:32 rohanion, ozamiatin__ - thanks for the update 16:16:54 DinaBelova: you are welcome 16:17:07 DinaBelova what about our planned changes in osprofiler? 16:17:25 rohanion let's dscuss it when we'll go to osprofiler related topic 16:17:28 of this meeting 16:17:31 ok 16:17:38 #action rohanion ozamiatin__ collect data about possible performance degradation of light weighted proxies for 0MQ 16:17:49 ack, let's go to the test plans 16:17:50 #topic Test plans statuses 16:17:57 ilyashakhat - please go ahead 16:19:45 DinaBelova, the execution of MQ test plan is still upcoming 16:19:53 pending on lab availability 16:20:24 ilyashakhat any estimates on when this can be processed? 16:20:29 dur to current situation? 16:20:32 due* 16:20:47 the plan is to do it asap 16:21:21 by the next meeting there certainly be some results 16:21:35 ilyashakhat ack 16:21:44 thanks for the update 16:21:58 anything else to share in this section? 16:22:23 ok, so let's proceed 16:22:26 #topic OSProfiler weekly update 16:22:39 ok, so something before we'll switch to rohanion's topic 16:23:01 currently (I still think it's possible) https://review.openstack.org/#/c/103368/42 will be merged soon 16:23:10 right now it's without DB tracing support 16:23:16 there are several reasons for this 16:23:51 1) keystone changed their oslo.db usage -> I need to modify oslo.db/enginefacade module -> this is going to happen only in Newton timeframe 16:24:25 2) it looks like there can be some issues on the profiling side as well, I need to ensure after will finish #1 16:24:57 so this change was almost merged when Morgan and I caught some misunderstanding we're trying to solve now :) 16:25:10 ok, so going to further osprofiler plans 16:25:32 rohanion will continue my work on the multi-drivers approach for the profiler 16:25:40 rohanion - anything you'd love to share now? 16:26:03 hi guys :) 16:26:09 yes 16:27:13 so what I'm planning to do is to create a concept of using external services like PostrgreSQL as storage engines for osprofiler notifications 16:27:54 and probably something else 16:28:15 do you think some etherpad with the proposed drivers will be a good idea? 16:28:41 I think we may try to focus on the most prioritized 16:28:48 although there might be several variants 16:28:54 of course 16:29:07 ack, may you please prepare it before next meeting? 16:29:14 will do 16:29:20 currently we have this idea of creating a class which will initialize osprofiler directly from service 16:29:29 #action rohanion prepare list of possible drivers for osprofiler with pros/cons of each one 16:30:01 ack, thanks! 16:30:15 it looks like we may go to open discussion 16:30:27 anything else in profiler-related section? 16:30:47 ok 16:30:48 #topic Open Discussion 16:31:15 so if you have something to say please don't hesitate :) 16:31:58 ok, so it looks like we're done for today! 16:32:05 thanks everyone for joining! 16:32:10 #endmeeting