Potential memory issues with agents full of data ?
by Heiko W.Rupp
Hi,
I have had my RHQ server pinned at a heap of 256M max and saw some OOMEs.
Increased memory to 320M and was able to see the following heap usage with
an agent obviously sending a ton of spooled data.
First red line is when the agent was connecting. 2nd red line was at the time
the agent prompt did finally show up on the agents internal command line.
I get the impression that we somehow (in the alert processing?) keeping
incoming metrics alive for much too long. But this is only a guess without any
proof.
Anyway - I did have the agent running over the weekend and the sender
was for some time not sending anymore. Perhaps this can be reproduced by
stopping the sender, having the agent collect data. And before re-enabling
the sender, the data file could be copied to be used for a few runs for
investigation with a profiler attached.
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
11 years, 7 months
anyone working with cassandra?
by John Sanda
One of the recent efforts by the core RHQ development has been to investigate alternative persistence/storage solutions for metric and event data. We have decided to focus our efforts around Cassandra. I would love to get feedback from anyone in the community on any of the following,
* Are you or have you used Cassandra? If so, was it in conjunction with RHQ?
* Have you used RHQ to manage Cassandra? If so, would you be willing to contribute anything with the community?
* Would you be willing to provide feedback on using RHQ to manage Cassandra when that functionality is made available?
Some relevant background information can be found on the RHQ wiki at,
* https://docs.jboss.org/author/display/RHQ/Next+Generation+Metrics+Storage
* https://docs.jboss.org/author/display/RHQ/Databases
Thanks
- John
11 years, 7 months
dbupgrade - Master reverted to 2.124 version
by Stefan Negrea
Hello Everybody,
I just reverted the dbupgrade scripts to use sequential update ids. There is no impact for releases. However, developers that rely on master will need to either drop the existing database (if 2.125 was installed) or manually update it to show version 2.124. For development purposes, the actual database should be in good shape without reapplying 2.124 if 2.125 was already applied.
Thank you,
Stefan Negrea
Software Engineer
11 years, 7 months
agent packaging
by John Mazzitelli
As part of the AS7 porting work, I spent some time looking at the packaging of both the embedded agent (within a SAR deployed in our RHQ Server AS container) and the standalone agent.
As for the embedded agent - when we start shipping with an AS7 container, we will no longer ship with even an experimental version of the embedded agent. AS7 has some additional issues we would have to resolve in order to get the embedded agent to work. I managed to work around some, but not all the way. Rather than spend more time on this issue, I have taken out the embedded agent from the build (this is in the rhq-on-as7 branch, we'll merge to master within the next few months).
As for the standalone agent, I wanted to start using some newer JBoss jars that come from the AS7 line (for example, the JMX jar "jboss-as-jmx-7.1.1.jar" to replace "jboss-jmx-4.2.3.GA.jar"). Alas, we can't do it without upgrading our remoting infrastructure. This is because the remoting infrastructure needs code that exists in the old JMX jar but is no longer in the new JMX jar.
In order to move away from some of these older JBoss jars, we'd need to investigate how we can swap out the Remoting 2.x stuff with the newer Remoting 3.x.
11 years, 7 months
Fwd: [jboss-as7-dev] Optional modules / subsystems usage best practices?
by Charles Crouch
We should probably make sure our AS7 migration includes a slimming/hardening phase too. I don't know about this time but with the previous app server we ended up turning off a lot of services we weren't using just to reduce the number of open ports...
----- Forwarded Message -----
From: "Marek Goldmann" <mgoldman(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Cc: "Ben Browning" <bbrownin(a)redhat.com>
Sent: Monday, October 1, 2012 3:40:24 AM
Subject: [jboss-as7-dev] Optional modules / subsystems usage best practices?
Hi all,
We are able to make a dependency optional in modules.xml. That's
awesome, now the question is how to use this feature in real life? Are
there any best practices?
A bit of background.
In TorqueBox we add several subsystems to the plain JBoss AS 7. We plan
to have a slimmed down TB called TorqueBox Lite, that will run as a
RubyGem directly. It's obvious that we would like to slim down the JBoss
AS distribution itself too since >120MB is too big for a reasonable
sized Gem. I dropped everything we don't need and I end up with JBoss AS
distribution that weights ~15MB.
In the TB Lite version we don't need several of AS7 subsystems, that are
required in the normal TB distribution. One example is the jmx
subsystem. It's currently marked as optional in the TB core subsystem.
How can I make sure I use the jmx subsystem only when it's available? It
would be ideally if we could disable some subsystems without breaking
the platform and instead just remove some features. What's the best way
to do it?
Thanks!
--Marek
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11 years, 7 months
AUTO: David A. Webster is on vacation (returning 10/08/2012)
by David A. Webster
I am out of the office until 10/08/2012.
I will be participating in a national senior league men's baseball
tournament in Phoenix, AZ.
Note: This is an automated response to your message "Handling of
Domain-mode objects of AS7 ?" sent on 10/1/2012 3:54:48 AM.
This is the only notification you will receive while this person is away.
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
11 years, 7 months
Handling of Domain-mode objects of AS7 ?
by Heiko W.Rupp
Hi,
this email is triggered by https://bugzilla.redhat.com/show_bug.cgi?id=846756
Basically in AS7 domain mode you have 2 conceptually different things:
- configuration information
- runtime information
Configuration information is present in e.g. the profiles with all their subsystems and and sub-resources,
but also in the form of server-group-definition or by creating new managed servers.
In domain mode all configuration changes must go through the domain controller.
Runtime information is present as data on deployments, and managed servers
And then there is the constraint that configurations need to be changed on the
domain controller and not on the host controllers.
So I think that on a host controller, the profiles section should not be shown,
and probably also not the server groups. Same for deployments, as they are supposed
to be manipulated on the DC as well.
For the managed servers, that are created on the DC, but are instantiated on the individual HCs,
we have a mixed situation:
- manipulation should happen on the DC
- metrics runtime should optimally be obtained on the HCs via an agent on the machine
So where in the tree do we show the managed servers?
Current situation is to show them as direct child of the respective HC
We could also show all managed servers on the level of the DC:
This view could be improved by having the managed server name in the form of <product> <host>/<name> e.g.
"EAP master/server-one" or "AS7 pintAS/pint one"
Another alternative could be to move the managed servers one level down below the hosts
So that it is clear which host hosts which managed servers.
This scenario would require to make the managed servers a service or
the hosts a server too (*1)
Still the question of where do we take which metrics from stays open, as in the
above scenarios, the usability improves, as the domain management is better
centered around one place, but would require to run all requests for metrics to
go through the DC (*2).
Optimally, we would show the managed servers with their configuration parts
below the host at the DC, have each HC list the managed servers as they are
today for metric collection AND have a sibling relationship from the managed
server a the DC below the host to the "real" one on the respective HC.
As this would further require splitting and duplicating resource types in the
already overfull plugin descriptor, we would also need to allow to add a flag
in the descriptor that can for runs-inside types enable/disable a certain element
for a specific (set of) parent(s). As example:
<service bla>
<runs-inside>
<server managed-as/>
<service profile/>
<service deployment/>
</runs-inside>
<metric name="a" available="not(profile)" .../>
<operation name="b" available="not(profile)" .. />
<operation name="c" available="profile"/>
<operation name="d" available="profile,managed-as"/>
<resource-configuration available="profile"../>
Detection if a HC is a HC or a DC is simple (*3), so modifying the
discovery to not discovery profiles at HC level can be easily achieved.
Heiko
*1) Services can not have servers inside in the resource category; we may also just
loosen that requirement.
*2) Which on the other hand allows to support hosts in a domain that do not run
an RHQ agent, which may be of interest in small virtual machine installations.
*3)
Operation op = new ReadAttribute(new Address(),"process-type");
Result res = connection.execute(op);
if (res.isSuccess()) {
String type = (String) res.getResult();
return type.startsWith("Domain");
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
11 years, 7 months