perfSONAR User Q&A and Other Discussion

[Pete Siemsen <>]

Thanks for the reply!

The machine is not part of a mesh. It is at the FRGP in Denver. It's connected only to research networks (Internet2, ESNet, some others). So it's a centrally-located and perfect for testing research links, so I guess it's popular.

-- Pete

On Thu, Jun 13, 2019 at 1:39 PM Mark Feit <> wrote:

Pete Siemsen writes:

 

1.5 years later, and I have this problem again. When it arose a few days ago, I got frustrated and did a clean install. This time, I installed Debian 9.9, and installed perfsonar-toolkit 4.1.6 via apt-get. There are no tests configured and no maddash. Similar process counts to those I reported earlier in this thread:

 

perfsonar-1850$ ps -eTf | wc -l
2155
…

 

Seems crazy. This time around, the system is quite responsive, so I am simply going to raise the threshold from 2000 to 3000 and call it good.

 

 

That’s the right thing to do for the time being if the system isn’t performing badly.  The sheer number of processes will make the load average look higher.

 

The current situation is that every streaming latency session is going to spawn a total of four powstream-related processes on the source and one owampd on the destination.  It’s not ideal, but we have to live with it for the time being because owamp and powstream are old programs and weren’t really written with this use case in mind.   (I assume that machine is part of a mesh, because something has to set all of those tests up.)

 

The good news for the future is that we are in the very early design stages of a replacement for powstream.  It should cut the number of always-on processes by 75% and will turn the remaining 25% into inexpensive threads under a single process.  The nature of this test is that there has to be one execution context for each, so we won’t be able to trim it back more than that.  Owampd isn’t particularly complicated, and we may be able to make it multithreaded instead of forking, but it will have to be done carefully.

 

--Mark