[ovs-dev] [PATCH 2/3] Save performance stats to database.

Mark Michelson mmichels at redhat.com
Mon Jan 8 21:32:39 UTC 2018


On 01/04/2018 06:38 PM, Ben Pfaff wrote:
> On Mon, Dec 18, 2017 at 04:51:38PM -0600, Mark Michelson wrote:
>> This commit builds on the performance library by storing compiled
>> statistics in the OVS vswitchd database.
>>
>> This can make it more useful for administrators to keep tabs on
>> performance in real time and make adjustments if necessary.
>>
>> Signed-off-by: Mark Michelson <mmichels at redhat.com>
> 
> It seems somewhat odd to put this table in the OVS database, when the
> (initial) intent is for the performance measurements to come from OVN
> instead.

Yeah, this was a case where my thought process was that I was adding 
something that is an OVS-level library, so it made the most sense to add 
the data to the OVS database.

Further, since my first use of the library was within ovn-controller, it 
made sense to be adding the data to databases that are local to each 
ovn-controller. That again led me to using the OVS database.

> 
> performance_destroy() needs to be called within a database transaction.
> 
> Database transactions don't always succeed; sometimes they fail and need
> to be retried.  I think that this will happen naturally with
> performance_run(), but I think that the deletion from
> performance_destroy() will not be retried if it fails (because the
> internal object has been destroyed).  This is not ideal.
> 
> One way to fix that might be to make performance_run() something that
> runs once, in the daemon's main loop, instead of once per performance
> object.  Then, performance_run() could compare the database table to
> 'performances', adding missing rows, updating existing rows, and
> deleting rows that should be abandoned.
> 
> The database schema seems pretty rough to me.  It is going to be hard to
> modify and extend.  I can think of a few ways to make it more flexible.
> One would be to have columns (name, age, samples, average, min, max,
> percentiles), where percentiles would be a map from a real (a
> percentile) to its score, and each performance object would have three
> rows, with ages 1, 5, and 10, (You might consider using columns of type
> 'real'.)  Another would be to have (name, samples, average, min, max,
> p95), where average, min, max, and p95 were maps from an age to the
> value for that age.  There are other possibilities too.
> 
> Thanks,
> 
> Ben.
> 



More information about the dev mailing list