> On Aug. 7, 2015, 8:03 p.m., Robert Levas wrote: > > ambari-server/src/main/java/org/apache/ambari/server/serveraction/ServerActionExecutor.java, > > line 242 > > <https://reviews.apache.org/r/37161/diff/3/?file=1034554#file1034554line242> > > > > 'requestSharedDataMap' needs to be _synchronized_ throughout this > > method.
Thanks for the review. I misread requestSharedDataMap as a ConcurrentHashmap - it's not, one of its parameter types is. I'll make sure it's synchronized. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37161/#review94599 ----------------------------------------------------------- On Aug. 7, 2015, 7:31 p.m., Jonathan Hurley wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/37161/ > ----------------------------------------------------------- > > (Updated Aug. 7, 2015, 7:31 p.m.) > > > Review request for Ambari, Alejandro Fernandez, Myroslav Papirkovskyy, Robert > Levas, Sumit Mohanty, and Sid Wagle. > > > Bugs: AMBARI-12657 > https://issues.apache.org/jira/browse/AMBARI-12657 > > > Repository: ambari > > > Description > ------- > > We started doing larger cluster creates (48 workernodes) with SQL Azure DB as > an Ambari DB, and we are seeing below HTTP GET requests timeout on the client > side (even after retries), resulting in cluster create failures (15%). This > is a tracking Jira to resolve the CRUD failures. > > What I’m seeing is that DB CPU usage goes above 50% in some of my experiments > for 48 node clusters. This might explain why SQL is running slow. > > Basically, it’s this one query which consumes most of the CPU. Query plan is > also attached. > ``` > SELECT DISTINCT t0.request_id FROM host_role_command t0 WHERE NOT EXISTS > (SELECT @P0 FROM host_role_command t1 WHERE (t1.status IN > (@P1,@P2,@P3,@P4,@P5,@P6,@P7,@P8,@P9))) ORDER BY t0.request_id ASC > ``` > > There's no need to do a JOIN on the same table here; we can eliminate the > inner SELECT and use a `NOT IN` clause. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostRoleCommandDAO.java > a72e1fe > > ambari-server/src/main/java/org/apache/ambari/server/serveraction/ServerActionExecutor.java > 49c031f > > ambari-server/src/test/java/org/apache/ambari/server/actionmanager/TestActionDBAccessorImpl.java > 8def61f > > Diff: https://reviews.apache.org/r/37161/diff/ > > > Testing > ------- > > mvn clean test > > Tests run: 3112, Failures: 0, Errors: 0, Skipped: 23 > > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 01:02 h > [INFO] Finished at: 2015-08-05T21:21:52-04:00 > [INFO] Final Memory: 29M/847M > > Verified the new SQL works on all databases. > > > Thanks, > > Jonathan Hurley > >
