[pve-devel] [RFC PATCH manager] pvestatd: fix status server udp overflow

Thomas Lamprecht t.lamprecht at proxmox.com
Wed Mar 4 10:11:23 CET 2020


On 3/4/20 10:01 AM, Dominik Csapak wrote:
> On 3/4/20 9:46 AM, Thomas Lamprecht wrote:
>> On 2/27/20 4:14 PM, Dominik Csapak wrote:
>>> for big vms (many disks/nics) a single status update can be bigger
>>> than 20k (i measured about 21k for a vm with 31 disks and nics)
>>> which means that a single update can bring the length of
>>> $txn->{data} over 65k (if it was >45k before)
>>
>> nice catch
>>
>>>
>>> we could reduce the limit when we send, but this would only move
>>> the problem, and we might run into it later on again
>>>
>>> to solve it (mostly) completely, append the data to $txn->{olddata}
>>> as long as the new and old data together do not get over 65k
>>>
>>> in that case, flush the olddata instead
>>>
>>> on finish flush olddata and if somehow data was left in data, flush
>>> that also
>>>
>>> one problem remains: if a single update from a vm/node/etc.. is over
>>> 65k, but this would require a bigger refactoring of the status
>>> plugins...
>>
>> hmm, your changes seems wrong, or better said unnecessarily complicated
>> while not solving all issues..
>>
>> I'll simply loop over data in 64k chunks if it's bigger than that and
>> send those out, simple package segmentation..
>>
> 
> but i guess that won't work properly, since e.g. the influxdb
> protocol is line-based and i guess it does not concatenate
> multiple udp packets... so if a line gets cut right in the middle
> the first part puts potentially wrong data into the db
> and the second is not the right syntax...
> 

do not just guess around.. UDP segmentation is something programs must
cope with, something in the network stack could even to this, else they
should use TCP..
And if this really is a problem, then:
1. curse at those *@?$! time series devs
2. still batch send but let the segmentation handle the plugin,
   so it can split one newline or whatever...

But i would take a solution that works, not a hack which solves some
parts only to redo it all in a few months anyway




More information about the pve-devel mailing list