Network load on VDS KVM, a large number of PPS, How to unload the network?

Question

linux

Good day, I have such a problem, there is a VDS KVM with a dedicated channel of 1GB, an IPIP tunnel is spinning on it, on the other side a service is spinning that loads the network very much, but there is little traffic, only 30-40Mbps, but PPS reaches 35000, and delays inside the tunnel begin, ping in idle mode is 10-11ms. when it reaches 35k PPS, then the ping increases by 5 times, reaches 50-70ms. at the same time, this service on the other side starts to work with delays.
There are 2 options for choosing a network card on VDS, these are Intel 1000 PRO and Virtio, if you choose Intel, then under such a load the processor is loaded up to 100% 1 core, the second is in a calm state, if you select Virtio, then the processor is almost not loaded, up to 2x% , Debian7 OS, 1GB RAM, 4Cores IntelXeon E3
sysctl -a | grep conntrack
[email protected]:~# sysctl -a | conntrack grep
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300 netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300 net.netfilter_tcp_conntrack
= 300 netfilter_tcp_conntrack = 300 netfilter.nf_conntrack = 300
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_acct = 0
net.netfilter.nf_conntrack_timestamp = 0
net .netfilter.nf_conntrack_events = 1
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_max = 7836
net.netfilter.nf_conntrack_count = 983
net.netfilter.nf_conntrack_buckets = 2048
net.netfilter.nf_conntrack_checksum = 1
net.net_conntrack.nlogind
net.net_conntrack_d netfilter.nf_conntrack_expect_max = 32
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter .ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net .ipv4.netfilter.ip_conntrack_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0
net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_timeconntrack_icmp_timeout =
180 .ip_conntrack_max = 7836
net.ipv4.netfilter.ip_conntrack_count = 983
net.ipv4.netfilter.ip_conntrack_buckets = 2048
net.ipv4.netfilter.ip_conntrack_checksum = 1
net.ipv4.netfilter.ip_conntrack_log_invalid = 0
net.nf_conntrack_max = 7836
Help can be how to fix the problem??? If there is someone who can really help, I will pay money

Answer 1

NIC emulation should be used by virtio, no options.
It is not clear what exactly processing at 35Kpps rests on. If the processor is occupied by 2%, then everything should be fine. What is in dmesg? Are there any messages from the kernel?

Answer 2

https://docs.google.com/document/d/1XLwJRw71CLPsPe...
This is with a similar VDS, only there are 2 cores and 256 RAM, a similar problem with the tunnel

Answer 3

You rest against the bridge on the host, most likely.

Answer 4

VDS from some operator, i.e. no access to the host? Most likely the problem is with the host. Maybe the network card on the host is too simple, without queues, and does not spread interrupts over the cores.