"10 ways to kill [db] performance"
by Heiko W.Rupp
Some very nice slides about killing db performance.
My favorites as actually
#33 "We call it 'Edward'"
#46 "Every OS has a database optimized for the handling of LOBs" (Hello Mazz :-)
http://thebuild.com/blog/2011/02/25/10-ways-to-kill-performanc/
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 1 month
remote calls statistics window
by John Mazzitelli
Thanks to Joe's work on the stats collection for our gwt rpc calls, I
managed to build on that work and provided a way for you to see those
stats in a window - so as you poke around, you will have these stats on
a window in the UI letting you watch what backend calls are being made
and how long they are taking.
you can auto-refresh this stats window via the Refresh drop down.
And you can capture the results in a comma-sep. text to put in a
spreadsheet for later analysis.
There is nothing for you to configure and you don't need to be in dev
mode. Just go to #Test and navigate to the remote statistics option.
From there, you'll see the stats view - click the "Show In Window"
button and you can now begin navigating the app while viewing the stats.
If the window gets in the way, you can minimize it.
Highly recommended to do this during development so you can see if you
are making lots of server calls and you can see which server calls are
taking the longest amount of time.
13 years, 2 months
Thoughts on displaying 'Recent Package History' and 'Recent Bundle Deployments' on Group Activity page...
by spinder
Hi All,
[Reposting. Apologies for the duplication]
Finally made some headway with that annoying bundle criteria query. Here's the weird display that I mentioned on this morning's call. Maybe weird is a bit harsh, but when we juxtapose the two sections reusing the Content Icon for both Bundle and Package elements it strikes me as a bit wierd. See images 1 and 2 for what the empty display looks like and what the display looks like being a bit more populated.
>From a design standpoint the Package/Content system does share some overlap with Bundles so the fact that we share icons here makes sense, but all the other Summary regions have not shared similar information before.
What do people think?
When we convert this stuff to use customizable dashboards it will be even less of a problem as users will be able to choose which portlets to display and one would really only see this problem when opting to display both package and bundle info. There are still quite a few conversations to be had about customizable Groups Activity region as we continue to build that out.
-Simeon
13 years, 2 months
new gwt component - metric date range
by John Mazzitelli
I gwt-ified a new metric date range component. pull master and rebuild
to see it. you go to the Measurement>Tables UI page (this is now
converted from jsf to gwt) and you will see the new preferences-backed
metric date range component.
We need to start using the metric date range whenever we start querying
data that we want to filter. We typically want to filter on the date
range the user has persisted in his preferences. So, if you need a date
range, its very easy in the GWT code to get a start and end date (which
are longs/epoch millis):
MeasurementUserPreferences(UserSessionManager.getUserPreferences()).getMetricRangePreferences().getBeginEndTimes()
You get back a ArrayList<Long> where index #1 is the begin time and
index #2 is the end time.
BTW: the reason why I did this was all in order to fix a bugzilla on my
plate - https://bugzilla.redhat.com/show_bug.cgi?id=536401...In the
measurement table, select one or more metrics, click the "Get Live Data"
button and up pops a dialog box that contains the live data for all
those metrics (we actually go out to the agent and collect the data).
13 years, 2 months
Unit testing, uniutil and TestNG version
by Heiko W.Rupp
Hi,
currently the build is "mostly" at TestNG version 5.13.1.
But I see TestNG v 5.8 being pulled in (and this is making the performance tests fail).
mvn -X shows
[DEBUG] org.unitils:unitils-testng:jar:3.1:test (selected for test)
[DEBUG] org.testng:testng:jar:jdk15:5.8:test (selected for test)
and indeed unitils-testng has a hard dependency on 5.8 in its pom:
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.8</version>
<classifier>jdk15</classifier>
Unfortunately there is no new version of unitils available since Nov 2009.
So in enterprise/server/jar/pom.xml I've included the pull-in of testng via modules/test-utils,
which pulls the unitils and old testng version.
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 2 months
New RHQ Groups Summary/Activity pages.. thoughts?
by spinder
Hi all,
I'm looking for feedback on what the contents of the Groups Summary/Activity pages should contain.
Note:
*Resource ->Summary pages renamed to Resource->Activity
*Group had no Summary page, just defaulted to metrics view.
in RHQ 3, the related Resource Summary/Activity pages displayed the following snapshot for the specific resource selected:
- Recent Metrics (displaying sparklines and recent data points)
- Recent Alerts (five most recent)
- Recent Out of Bound Metrics (five most recent)
- Recent Configuration Updates (five most recent)
- Recent Operations (five most recent)
- Recent Event Counts (severity + counts for last 24 hrs)
- Recent Package History (five most recent)
in RHQ 4, we're adding the Summary/Activity page for Groups. My initial thoughts were to list the following for each group/autogroup:
- Recent Metrics (displaying sparklines and recent metric data points)
- Recent Alerts (five most recent) but with "More.." links for user to view full query results spanning N resources.
- Recent Configuration Updates (five most recent to display in process)
- Recent Operations (five most recent operations,include started operations as well)
- Recent Event Counts (severity + counts for last 24 hrs for only higher severity counts displayed)
- Recent Package History (five most recent across group both created and updated)
*The 'Recent Package History' has no current group support in SLSBs. Some work here to aggregate.
*How does this play with our decision to direct people to use Bundles instead of manual deploy package updates?
- Recent Out of Bound Metrics (five most recent)
*The 'Recent Out of Bound Metrics' has no current group support in SLSBs. Some work here to aggregate. Still worth it? Long standing issue with correct OOB usage for resources. Multiply problem for groups?
Given the dashboard like nature of the Activity panel now, should we consider adding:
i)ActivityView page refresh button for whole page? Individual refresh options for each section?
ii)Logic to automatically refresh the ActivityView sections every 20 seconds? Refresh round robin?
Should we add some 'Bundle Operations' section to the Group Activity page for Platform groups?
-Simeon
13 years, 2 months
RHQ 4.0 Developer Preview 3 Available
by John Sanda
Hi,
We have just released RHQ 4.0 Developer Preview 3. This release is
intended for developers and other interested parties who want a
first-hand look at upcoming changes in RHQ 4.0, in particular the new
GWT UI. Please note that this release is not intended for production use
or serious testing.
New Features:
* Improved dashboard
* Improved operations UI (for single resource)
* Improved bundles UI
* System settings have been ported to GWT
* Support for Postgres 9.0
* Support for deleting agent plugins
More detailed release notes can be found here:
http://www.rhq-project.org/display/RHQ/Release+Notes+4.0+DP3
Please check out this release and give us as much feedback as you can.
Also we are very interested in getting more translations
The release can be downloaded from the link found in the release notes
Thanks to everyone who contributed.
- John (on behalf of the RHQ team)
13 years, 2 months
[devs] Count-Queries ( Page Control)
by Heiko W.Rupp
Hi,
in many places we have something like (query behind the AD portlet):
Query queryCount = PersistenceUtility.createCountQuery(entityManager,
Resource.QUERY_FIND_QUEUED_PLATFORMS_BY_INVENTORY_STATUS);
Query query = PersistenceUtility.createQueryWithOrderBy(entityManager,
Resource.QUERY_FIND_QUEUED_PLATFORMS_BY_INVENTORY_STATUS, pc);
queryCount.setParameter("inventoryStatuses", statuses);
long count = (Long) queryCount.getSingleResult();
query.setParameter("inventoryStatuses", statuses);
List<Resource> results = query.getResultList();
here we fire 2 queries:
- first counting total number of items that may match
- second getting a subset of those matching items.
This may turn out problematic
- we always do two roundtrips to the DB
- we always fire two slightly different DB queries
as they are in the same transaction and in direct succession, the relevant tables
may still be in memory.
I propose for queries like the above, where the default result is 0 items, to check for 0 results after the first query
and only to fire the 2nd one if there are items matching.
The counterpart to this are queries with an unlimited PC - meaning that everything
should be returned. Here the count query is not needed and should not be fired.
Hand stopped for the AD portlet, this simple check for 0 cuts off ~300% time used and quite
some cpu load on the DB (the above query is entirely CPU bound).
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 2 months
rhq plugin tool chain
by Charles Crouch
Given RHQ doesn't yet support dynamic resource plugin metadata (i.e. at runtime decide you want to measure a new metric), there is I believe a need to support an automated tool-chain to enable people to get closer to having this capability, while still using the normal build-time resource plugin metadata. Does the following workflow make sense to support this for monitoring arbitrary mbean values? Please flag any errors/omissions
1) Start off with a .txt file containing mbean names and attribute values to be monitored
2) Generate an rhq-plugin.xml from the .txt file in 1). This would extend the jmx plugin, and for basic monitoring require no java code in the plugin
3) Package the rhq-plugin.xml from 2) into a plugin .jar file
4) Deploy the plugin .jar from 3) into an RHQ server
5) Tell the agents to go refresh their plugins
6) Agents should now be collecting all the metrics mentioned in 1)
In terms of automation I think all steps besides 4) should be feasible right now? Regarding 4) I'm not seeing this in the remote api. Any major reason it couldn't be added?
Cheers
Charles
13 years, 2 months
Fwd: New RHQ Groups Summary/Activity pages.. thoughts?
by Heiko W.Rupp
Very good feedback from Steve Millidge:
Anfang der weitergeleiteten E-Mail:
> Von: "Steve Millidge" <smillidge(a)c2b2.co.uk>
> Datum: 13. Februar 2011 14:50:06 MEZ
> An: "'Heiko W.Rupp'" <hrupp(a)redhat.com>
> Betreff: RE: New RHQ Groups Summary/Activity pages.. thoughts?
>
> Heiko,
>
> Some initial thoughts from experience out in the field. Apologies for the
> length!
>
> The Summary pages are one of the best features of RHQ and the page that
> delivers the most benefit to customers. I was a bit sad to see it disappear
> from the "first tab" in RHQ 4 when you click on a resource. One great
> feature that could be added on the Resource summary screen is a rollup of
> all child resources alerts, OOB metrics, operations and config changes. For
> example it would be great when clicking on a JBoss AS to see that an alert
> had been generated from a JMS queue hosted by the server. If this was
> carried out throughout the whole resource tree you could easily see by
> clicking on a Platform any alerts generated by any servers/services on that
> platform. As it is at the moment you need to have a good idea what the
> problem may be to drill down to the correct resource level and check
> metrics, config changes and alerts etc.
>
> Addition of group summaries would be a great addition and is better than the
> current group page which tends to just show availability. A key thing for a
> group summary view would be to quickly draw an operator's attention to
> anomalies within the group.
>
> One thing to add at a group level would be a traffic light for availability
> which can be drilled down. Green for all members up, Amber for some are down
> some are up, Red for all resources down. You can then drill down for exact
> details of each group member.
>
> Recent metrics at group level as the sparklines. I'm not sure how much value
> this will add as the range bars may be a bit wide. Perhaps a moving average
> value with some indication of the range of values within the group could be
> more useful.
>
> Alerts, Config changes and Operations should be shown when they were
> generated by a group alert or operations on the whole group. I think it
> would also be useful to show whether an operation had been carried out on an
> individual group member but not the whole group. Especially if it failed.
> Perhaps the traffic light concept could be used next to the operation to
> show whether it was executed successful on all members or only some.
>
> In general good summarisation is a feature lacking in RHQ at the moment. RHQ
> does a fantastic job of gathering a load of fine grained metrics etc. at a
> resource level and is therefore invaluable as an admin tool for very
> technical operators. What is needed is some "top level" view that can be
> created to give an operator a warm feeling that everything is OK and then if
> anything anomalous occurs, the operator requires immediate visual feedback
> and a signpost to the suffering resource. Followed by rapid drill down to
> the detailed metrics and timeframe where the problem occurred. These
> operators will then typically call in deep support responsible for that
> component who can use the current functionality to get at all the
> information they require to diagnose.
>
> For example for one of our customers we developed a single JSP page
> dashboard which we deployed to the RHQ server which gave a summarised view
> of the state of their system. All servers were listed with traffic lights.
> Key group metrics were also shown with current average and total values for
> the group and traffic lights to indicate anomalous metrics were in the
> group. These traffic lights then could be clicked on to show the server with
> the anomalous value. For example number of messages on a JMS queue was a
> critical metric. This queue is present on 34 servers so the top level
> dashboard showed the summed count and average for all servers with a traffic
> light if the value was out of some bounds. Clicking on the traffic light and
> count gave a view of the queue counts on each server with a traffic light
> next to each. Further drill down was a deep link into the RHQ page for the
> resource (queue).
>
> On the subject of auto-refresh. I would be careful here as some of the group
> metric calculations could be expensive to perform and therefore auto-refresh
> may hammer the database server. I think some of the values would need to be
> precalculated in the database if autorefresh at the group level was
> performed. If the heavyweight nature of the database queries can be solved
> autorefresh would be useful.
>
> Steve Millidge
> Director
> C2B2
>
> Providing the foundations for Enterprise Scale Java.
>
> T: 08450 539457
> M: 07920 100626
> W: www.c2b2.co.uk
> E: smillidge(a)c2b2.co.uk
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 2 months