I've finished implementing Hobbit 4.2 at a customer site, the last little problem being the rrd issue that Henrik (and others) confirmed the problem that I was having with moving graphs between architectures.
When the release notes indicated that there was up to a 50% reduction in CPU Utilization, I really took notice. This customer runs Hobbit in a shared, virtualized environment (in a Linux virtual machine on the mainframe). In this environment we like applications that get the work done while using the least amount of CPU and memory possible.
Before 4.2 at it's peak the Hobbit virtual machine would use ~13% of the CPU. I wasn't worried too much about that, since the peak comes at a consistent interval.
After 4.2 I've noticed that the Hobbit virtual machine now barely gets about 1% of CPU Utilization. I was very surprised at the significant reduction in resources required for this release.
I must commend Henrik, not only on this wonderful achievement, but also on the amazing new features in 4.2. May all your releases be so good!
Regards,
Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com
Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
I must commend Henrik, not only on this wonderful achievement, but also on the amazing new features in 4.2. May all your releases be so good!
And after much time spent RTFM'ing and asking on this mailing list, I've finally figured out the log monitoring. It works a little differently than I thought, but after getting used to it, it's so much better than BB's implementation. I look forward to see what future releases will bring.
Hi Gary,
On Sun, Aug 27, 2006 at 11:19:47PM -0400, Gary B. wrote:
I must commend Henrik, not only on this wonderful achievement, but also on the amazing new features in 4.2. May all your releases be so good!
And after much time spent RTFM'ing and asking on this mailing list, I've finally figured out the log monitoring. It works a little differently than I thought, but after getting used to it, it's so much better than BB's implementation. I look forward to see what future releases will bring.
It would be interesting to hear what it was that confused you. If you have any suggestions for extra documentation or such that would make it easier to setup, I'm all ears.
The problem with writing docs is that you only do it after you have been working with something for a long time. So it's difficult to forget everything you know, and try catch everything you must describe to someone without that knowledge.
Regards, Henrik
On 8/28/06, Henrik Stoerner <henrik at hswn.dk> wrote:
Hi Gary,
On Sun, Aug 27, 2006 at 11:19:47PM -0400, Gary B. wrote:
I must commend Henrik, not only on this wonderful achievement, but also on the amazing new features in 4.2. May all your releases be so good!
And after much time spent RTFM'ing and asking on this mailing list, I've finally figured out the log monitoring. It works a little differently than I thought, but after getting used to it, it's so much better than BB's implementation. I look forward to see what future releases will bring.
It would be interesting to hear what it was that confused you. If you have any suggestions for extra documentation or such that would make it easier to setup, I'm all ears.
I will be putting together some internal documentation on log file monitoring--a "cheat-sheet" of sorts. Once I complete it, I'll post what I have here.
The problem with writing docs is that you only do it after you have been working with something for a long time. So it's difficult to forget everything you know, and try catch everything you must describe to someone without that knowledge.
I think part of the confusion on my part was having a different idea in my head of how it should work than what was actually written, and thus was partly confusing myself. But I understand what you mean, as I've often run in to similar problems when trying to explain things to others who know less about the given subject than I do.
On 8/28/06, Gary B. <gmbfly98 at gmail.com> wrote:
On 8/28/06, Henrik Stoerner <henrik at hswn.dk> wrote:
Hi Gary,
On Sun, Aug 27, 2006 at 11:19:47PM -0400, Gary B. wrote:
I must commend Henrik, not only on this wonderful achievement, but also on the amazing new features in 4.2. May all your releases be so good!
And after much time spent RTFM'ing and asking on this mailing list, I've finally figured out the log monitoring. It works a little differently than I thought, but after getting used to it, it's so much better than BB's implementation. I look forward to see what future releases will bring.
It would be interesting to hear what it was that confused you. If you have any suggestions for extra documentation or such that would make it easier to setup, I'm all ears.
I will be putting together some internal documentation on log file monitoring--a "cheat-sheet" of sorts. Once I complete it, I'll post what I have here.
I've attached two plaintext files. One is the internal documentation I wrote for setting up clients for monitoring and alerting. The other is the internal documentation I just wrote for setting up log monitoring. Both are meant to be used as supplements to the full documentation.
good write-up, Gary. maybe this should be added to the Hobbit Wiki.
Question, which takes precedence, if a line matches both IGNORE and the alert string/reg. One line of particular interests to me is the SELinux's pts relabeling warning in /var/log/messages, which is harmless but annoying. I am on 4.2-RC1-20060712 and have seen such a log line causing this log test to go red.
In 'hobbit-clients.cfg', I have log /var/log/messages %WARNING|NOTICE|ERROR IGNORE=relabeling
The offending log lines goes line: Jul 30 18:22:25 SRV01 su[31747]: Warning! Could not relabel /dev/pts/0 with user_u:object_r:devpts_t, not relabeling.Operation not permitted
On 8/28/06, Gary B. <gmbfly98 at gmail.com> wrote:
On 8/28/06, Gary B. <gmbfly98 at gmail.com> wrote:
On 8/28/06, Henrik Stoerner <henrik at hswn.dk> wrote:
Hi Gary,
On Sun, Aug 27, 2006 at 11:19:47PM -0400, Gary B. wrote:
I must commend Henrik, not only on this wonderful achievement, but also on the amazing new features in 4.2. May all your releases be so good!
And after much time spent RTFM'ing and asking on this mailing list, I've finally figured out the log monitoring. It works a little differently than I thought, but after getting used to it, it's so much better than BB's implementation. I look forward to see what future releases will bring.
It would be interesting to hear what it was that confused you. If you have any suggestions for extra documentation or such that would make it easier to setup, I'm all ears.
I will be putting together some internal documentation on log file monitoring--a "cheat-sheet" of sorts. Once I complete it, I'll post what I have here.
I've attached two plaintext files. One is the internal documentation I wrote for setting up clients for monitoring and alerting. The other is the internal documentation I just wrote for setting up log monitoring. Both are meant to be used as supplements to the full documentation.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Mon, Aug 28, 2006 at 11:08:20AM -0400, Jerry Yu wrote:
Question, which takes precedence, if a line matches both IGNORE and the alert string/reg. One line of particular interests to me is the SELinux's pts relabeling warning in /var/log/messages, which is harmless but annoying. I am on 4.2-RC1-20060712 and have seen such a log line causing this log test to go red.
In 'hobbit-clients.cfg', I have log /var/log/messages %WARNING|NOTICE|ERROR IGNORE=relabeling
The offending log lines goes line: Jul 30 18:22:25 SRV01 su[31747]: Warning! Could not relabel /dev/pts/0 with user_u:object_r:devpts_t, not relabeling.Operation not permitted
IGNORE takes precedence over the matching rule. So this line would not trigger an error status.
Regards, Henrik
Hello,
I can't compile the new version of hobbit client (4.2 stable) on AIX 4.2. I've uncommented the 'CC' and 'CFLAGS' lines in 'build/Makefile.AIX' to use gcc and not the IBM compiler. There is no problem on AIX 4.3.3. Can you help me ? Best regards,
Thomas
sigma </opt/gnu/hobbit-4.2.0 >#oslevel 4.2.1.0
sigma </opt/gnu/hobbit-4.2.0 >#gmake
CC="gcc" CFLAGS="-g -DDEBUG -D_REENTRANT -DAIX -I. -Ipwd/include
-DCLIENTONLY=1" LDFLAGS="" OSDEF="-DAIX" RPATHOPT="" PCREINCDIR=""
SSLFLAGS="" SSLINCDIR="" SSLLIBS="" NETLIBS="" BBTOPDIR="/opt/hobbit"
BBLOGDIR="" BBHOSTNAME="" BBHOSTIP="158.157.156.91" BBHOSTOS=""
LOCALCLIENT="no" gmake -C lib client
gmake[1]: Entering directory /opt/gnu/hobbit-4.2.0/lib' gcc -g -DDEBUG -D_REENTRANT -DAIX -I. -I/opt/gnu/hobbit-4.2.0/include -DCLIENTONLY=1 -I. -I../include -o test-endianness test-endianness.c cpp: installation problem, cannot exec cpp': The parameter or environment
lists are too long.
gmake[1]: *** [test-endianness] Error 1
gmake[1]: Leaving directory `/opt/gnu/hobbit-4.2.0/lib'
gmake: *** [lib-client] Error 2
sigma </opt/gnu/hobbit-4.2.0 >#which cpp /opt/gnu/usr/local/bin/cpp
sigma </opt/gnu/hobbit-4.2.0 >#gcc --version 2.95.2
Ce message (et toutes ses pieces jointes eventuelles) est confidentiel et etabli a l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, CNP Assurances et ses filiales declinent toute responsabilite au titre de ce message, s'il a ete altere, deforme ou falsifie.
This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither CNP Assurances nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.
On Sun, Aug 27, 2006 at 08:12:08PM -0500, Rich Smrcina wrote:
Before 4.2 at it's peak the Hobbit virtual machine would use ~13% of the CPU. I wasn't worried too much about that, since the peak comes at a consistent interval.
Sounds like it was every 5 minutes when the webpage update kicked in.
After 4.2 I've noticed that the Hobbit virtual machine now barely gets about 1% of CPU Utilization. I was very surprised at the significant reduction in resources required for this release.
Nice! Well, it just goes to show how embarassingly non-optimal some of my early coding was :-) It's good that there are open source profiling tools available to point out where the hotspots are in your program.
I must commend Henrik, not only on this wonderful achievement, but also on the amazing new features in 4.2. May all your releases be so good!
I'll do my very best.
Thanks, Henrik
participants (5)
-
gmbfly98＠gmail.com
-
henrik＠hswn.dk
-
jjj863＠gmail.com
-
rsmrcina＠wi.rr.com
-
thomas.seglard.enata＠cnp.fr