Hello, yes 1 second should be ok as well and it can be configured. Maybe if pvestatd has problems with blocking, an upper limit would be good as well to prevent misconfiguration.
I agree that we don't read from that socket, therefore "$carbon_socket->read_timeout($timeout);" should not be required. However, I don't know how perl works internally and therefore I think it won't hurt to set read and write to prevent any blocking. Maybe someone with better knowledge about perl and pvestatd should answer that. -- Martin Verges Managing director Mobile: +49 174 9335695 E-Mail: martin.ver...@croit.io Chat: https://t.me/MartinVerges croit GmbH, Freseniusstr. 31h, 81247 Munich CEO: Martin Verges - VAT-ID: DE310638492 Com. register: Amtsgericht Munich HRB 231263 Web: https://croit.io YouTube: https://goo.gl/PGE1Bx Am Mi., 6. Nov. 2019 um 21:11 Uhr schrieb Thomas Lamprecht < t.lampre...@proxmox.com>: > On 11/5/19 10:34 PM, Martin Verges wrote: > > This change allows sending statistics to graphite over TCP. > > > > So far only UDP is possible, which is not available in some > environments, like behind a loadbalancer. > > > > Configuration example: > > ~ $ cat /etc/pve/status.cfg > > > > graphite: > > server 10.20.30.40 > > port 2003 > > path proxmox > > proto tcp > > timeout 3 > > > > Signed-off-by: Martin Verges <martin.ver...@croit.io> > > --- > > PVE/Status/Graphite.pm | 25 ++++++++++++++++++++++++- > > 1 file changed, 24 insertions(+), 1 deletion(-) > > > > applied, but with a followup reducing the default timeout to 1 > second, which should be still high enough for most people, as TCP > needs roughly 1.5 time of the Round Trip Time for connection setup, > So, with 1 second timeout we're still good for connections with 660ms > latency in-between. > > Users can always increase it if required in their environment. > > Thanks a lot! > > _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
