I've seen a large jump in CPU usage on many of my perfsonar hosts
since upgrading to 3.4.2. See attached image for an example (went
from around 25% CPU to 75% in this case).
Is this expected behavior, or any ideas of what might have caused
this?
I'm seeing high CPU from apache httpd processes on my machines. TOP
shows stuff similar to this:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13406 apache 20 0 247m 42m 4716 S 13.2 1.1 1:12.25 httpd
13407 apache 20 0 244m 39m 4716 S 10.9 1.0 1:13.40 httpd
13405 apache 20 0 243m 39m 4716 S 6.9 1.0 1:14.42 httpd
28247 perfsona 20 0 0 0 0 Z 4.9 0.0 0:00.15 daemon
<defunct>
28248 perfsona 20 0 0 0 0 Z 4.9 0.0 0:00.15 daemon
<defunct>
28249 perfsona 20 0 0 0 0 Z 4.9 0.0 0:00.15 daemon
<defunct>
1491 cassandr 20 0 1455m 759m 58m S 4.0 19.4 5:24.91 java
Jeremy Palmer
Senior Network Engineer
ViaWest, Inc.
Office: 720.891.1045
Fax: 303-874-5236
http://www.viawest.com
On 3/25/2015 5:48 AM, Andrew Lake
wrote:
You can ignore those warnings, you do not need to do any manual
changes. The toolkit package changes that file the first time it's
installed which is why they were not automatically replaced. There
is nothing from the new version of those files you need.
As for the stack trace message I think you can ignore as
well. I think I may tweak the spec file so that message goes
away though.
Thanks,
Andy
On Mar 25, 2015, at 4:41 AM, Roderick Mooi <>
wrote:
Oops.
Missed these 2 warnings:
warning: /opt/esmond/esmond.conf created as
/opt/esmond/esmond.conf.rpmnew
warning:
/opt/esmond/esmond/settings.py created as
/opt/esmond/esmond/settings.py.rpmnew
Do I
need to replace those 2 files with the new versions? I
don’t recall doing any manual changes (doesn’t that
mean they should’ve been automatically replaced?).
Thanks,
Roderick
On 25 Mar 2015, at 10:40 AM, Roderick
Mooi <>
wrote:
Hi
On update we got the following:
Installing
Pip....................................................................................................................................done.
Traceback (most recent call last):
File "esmond/manage.py", line 4,
in <module>
import settings # Assumed to be
in the same directory.
File
"/opt/esmond/esmond/settings.py", line 16,
in <module>
raise Error("ESMOND_ROOT not
definied in environemnt")
NameError: name 'Error' is not
defined
Is this a cause for
concern? The rest of the update seems to be
fine…
Thanks,
Roderick
On 24 Mar 2015, at 4:51 PM,
Andrew Lake <>
wrote:
Hi all,
The final release of
perfSONAR 3.4.2 is now available.
This is primarily a bug fix release
with a few minor enhancements.
Notable features and changes
include:
* BWCTL graphs now show
test failures as red dots on the
graph. This should make it easier to
distinguish between cases where no
test was run versus a test tried to
run but failed.
* The amount of
installed memory is now shown in the
Toolkit main page. This makes it
easier to debug issues caused by a
system below the recommended memory
requirements of 4GB . Hosts under
this recommended amount will have
this field highlighted in red.
* A number of fixes to
the regular_testing daemon to
prevent issues with data files,
configuration files and logs from
filling disks.
* Continues to include
latest BWCTL (1.5.4) and iperf3
(3.0.11) software
Existing users that have
auto-updates configured should
download the changes in the next 24
hours. Those without auto-updates
can run 'yum update' by hand to get
the latest version. It
is recommended all users reboot
their host after this update. This
not only ensures all updated
services are running, but that any
recently downloaded kernel patches
and security fixes are applied. No
other special steps are required for
upgrade and all of your data prior
to update should be retained. Please
let us know if that is not the case.
Special Note
for RC Testers: If you are
upgrading from 3.4.2rc1
auto-updates should migrate you
back to the main repository
eventually but it may take an
extra day. If you want to do this
update by hand run "yum update",
followed by "yum clean all", and
then "yum update" again. After
that, perform a reboot. These
extra steps are required to point
an installation back at the
primary yum repository (instead of
the testing repository). You may
not have any package updates since
the last commit to the testing
branch became the final release.
Thanks again to all our
testers and those that provided
feedback. If you have any questions
please direct them to .
Thanks,
Andy
