2

I am running openstack on LXC container and i found inside my LXC container network is very slow but from host its very fast

HOST

[root@ostack-infra-01 ~]# time wget http://mirror.cc.columbia.edu/pub/linux/centos/7.5.1804/updates/x86_64/repodata/0d7e660988dcc434ec5dec72067655f9b0ef44e6164d3fb85bda2bd1b09534db-primary.sqlite.bz2
--2018-08-04 00:24:09--  http://mirror.cc.columbia.edu/pub/linux/centos/7.5.1804/updates/x86_64/repodata/0d7e660988dcc434ec5dec72067655f9b0ef44e6164d3fb85bda2bd1b09534db-primary.sqlite.bz2
Resolving mirror.cc.columbia.edu (mirror.cc.columbia.edu)... 128.59.59.71
Connecting to mirror.cc.columbia.edu (mirror.cc.columbia.edu)|128.59.59.71|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4515677 (4.3M) [application/x-bzip2]
Saving to: ‘0d7e660988dcc434ec5dec72067655f9b0ef44e6164d3fb85bda2bd1b09534db-primary.sqlite.bz2’

100%[===========================================================================================================================================>] 4,515,677   23.1MB/s   in 0.2s

2018-08-04 00:24:09 (23.1 MB/s) - ‘0d7e660988dcc434ec5dec72067655f9b0ef44e6164d3fb85bda2bd1b09534db-primary.sqlite.bz2’ saved [4515677/4515677]


real    0m0.209s
user    0m0.008s
sys     0m0.014s

LXC container on same host

[root@ostack-infra-01 ~]# lxc-attach -n ostack-infra-01_neutron_server_container-fbf14420
[root@ostack-infra-01-neutron-server-container-fbf14420 ~]# time wget http://mirror.cc.columbia.edu/pub/linux/centos/7.5.1804/updates/x86_64/repodata/0d7e660988dcc434ec5dec72067655f9b0ef44e6164d3fb85bda2bd1b09534db-primary.sqlite.bz2
--2018-08-04 00:24:32--  http://mirror.cc.columbia.edu/pub/linux/centos/7.5.1804/updates/x86_64/repodata/0d7e660988dcc434ec5dec72067655f9b0ef44e6164d3fb85bda2bd1b09534db-primary.sqlite.bz2
Resolving mirror.cc.columbia.edu (mirror.cc.columbia.edu)... 128.59.59.71
Connecting to mirror.cc.columbia.edu (mirror.cc.columbia.edu)|128.59.59.71|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4515677 (4.3M) [application/x-bzip2]
Saving to: ‘0d7e660988dcc434ec5dec72067655f9b0ef44e6164d3fb85bda2bd1b09534db-primary.sqlite.bz2’

100%[===========================================================================================================================================>] 4,515,677   43.4KB/s   in 1m 58s

2018-08-04 00:26:31 (37.3 KB/s) - ‘0d7e660988dcc434ec5dec72067655f9b0ef44e6164d3fb85bda2bd1b09534db-primary.sqlite.bz2’ saved [4515677/4515677]


real    1m59.121s
user    0m0.002s
sys     0m0.361s

I don't have any fancy configuration of any limit set for network, i have other host which is working fine and max speed, what do you think wrong here

kernel version Linux ostack-infra-01 3.10.0-862.3.3.el7.x86_64 #1 SMP

CentOS 7.5

  • Have you checked the block io prioritization? Try running "lxc-group -n ostack-infra-01_neutron_server_container-fbf14420 blkio.weight". I believe anything under 1000 will de-prioritize the IO of the container. – rcv Aug 9 '18 at 15:56
1

Solution

Host machine had following setting, it was causing my dmesg flood with lots of kernel error stack. (7 - debug level).

[root@lxc ~]# cat /proc/sys/kernel/printk
7   4   1   3

I have changed it to:

[root@lxc ~]# cat /proc/sys/kernel/printk
3   4   1   3

Later I found I had iptables --checksum-fill rules in iptables which was generating lots of checksum error which causing kernel stack error food into dmesg.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.