[SOLVED] LXC startup slow

[dik23]

LXC container with LAMP installed

pct start 999 && pct enter 999

Running top I can see that a couple of processes are running eg rsyslogd, upstart*

It takes 1-2 minutes for apache etc to start

Why is this? Is it editable?

Sorry if this has already been covered but I've not found anything written.

 

[fireon]

Hello

please post some information:

• Hardware: CPU/Memory, what storagetype, how many HDD's, SSD's
• pveversion -v
• pveperf /yourstorage(s)
• What system do you using in LXC?

 

[dik23]

Just updated to 5.1 with the same results...

AMD Opteron 4334
2x 7200 drives ZFS raid
Nothing running - load 0.00 - results seen with single ubuntu 14 lxc

pveversion -v

proxmox-ve: 5.1-25 (running kernel: 4.13.4-1-pve)
pve-manager: 5.1-35 (running version: 5.1-35/722cc488)
pve-kernel-4.13.4-1-pve: 4.13.4-25
pve-kernel-4.10.17-4-pve: 4.10.17-24
pve-kernel-4.10.17-2-pve: 4.10.17-20
pve-kernel-4.10.17-3-pve: 4.10.17-23
pve-kernel-4.10.17-1-pve: 4.10.17-18
libpve-http-server-perl: 2.0-6
lvm2: 2.02.168-pve6
corosync: 2.4.2-pve3
libqb0: 1.0.1-1
pve-cluster: 5.0-15
qemu-server: 5.0-17
pve-firmware: 2.0-3
libpve-common-perl: 5.0-20
libpve-guest-common-perl: 2.0-13
libpve-access-control: 5.0-7
libpve-storage-perl: 5.0-16
pve-libspice-server1: 0.12.8-3
vncterm: 1.5-2
pve-docs: 5.1-12
pve-qemu-kvm: 2.9.1-2
pve-container: 2.0-17
pve-firewall: 3.0-3
pve-ha-manager: 2.0-3
ksm-control-daemon: 1.2-2
glusterfs-client: 3.8.8-1
lxc-pve: 2.1.0-2
lxcfs: 2.0.7-pve4
criu: 2.11.1-1~bpo90
novnc-pve: 0.6-4
smartmontools: 6.5+svn4324-1
zfsutils-linux: 0.7.2-pve1~bpo90

 

[fireon]

Only two drivers for ZFS... not fast. And... you have not answerd all my questions.

Memory of the pvehost, and "pveperf /yourstorgage"

Thank you

 

[dik23]

Apologies, was taking part in the evening dash to the exits.

pvehost - 32GB

pveperf /rpool//data

CPU BOGOMIPS:      37198.92
REGEX/SECOND:      1414104
HD SIZE:           1500.30 GB (rpool/data)
FSYNCS/SECOND:     114.41
DNS EXT:           85.59 ms
DNS INT:           3.52 ms

I appreciate this is no supercomputer but I don't feel that I'm asking it to do anything. Once the container is running I can start / stop apache instantly. It seems to me as if the 1-2 minute delay on start is planned rather than a restriction. Using the same hardware running openvz container processes started straight away.

 

[dcsapak]

can you post your container config ?

 

[dik23]

arch: amd64
cores: 2
cpulimit: 1
hostname: xxxxx
memory: 6144
net0: name=eth0,bridge=vmbr0,gw=10.0.0.1,hwaddr=9A:EE:13:CC:4A:47,ip=10.0.0.131/32,type=veth
onboot: 0
ostype: ubuntu
rootfs: zfs:subvol-999-disk-1,size=50G
swap: 512
unprivileged: 1

 

[dik23]

I've just noticed something....

This is only seems to be a problem in containers that have been converted from OpenVZ. Newly created containers don't seem to have this problem.

Is there a fix/ workaround?

 

[dik23]

Anyone?

 

[fireon]

Can you test it with "unprivileged: 0" ?

 

[dik23]

Same result, uptime in htop got to 2min 1sec before I could see apache / mysql etc starting.

I've also noticed that @reboot touch file crontab entry happens at this time and not when the container is booted

 

[fireon]

FSYNCS/SECOND: 114.41

Only for information. This is not very nice. Should be 3000+ for productive performance. But for your container this is enough.

 

[dik23]

Only for information. This is not very nice. Should be 3000+ for productive performance. But for your container this is enough.

I am aware that this machine is no Cray but I'm not planning on doing any heavy lifting with it

What I would like is apache to start when I tell it to

 

[dik23]

No ideas?

 

[fabian]

check the network and mount config inside the container - maybe it is waiting for DHCP or some mount point to timeout or something like this?

 

[giorgiosca]

I was in the same situation of you: an LXC converted from an OpenVZ container, based on Debian 7: after the boot I had to wait ~ 2 minutes before the container to be reachable from the outside network.

I noticed that the delay was caused by several SLEEP commands contained in /etc/init/failsafe.conf

As suggested on ASKUBUNTU (sorry, but I'm not allowed to post external links) I commented the sleep commands and now it is reachable from the network as the other LXCs.

Bye

 

[dik23]

I was in the same situation of you: an LXC converted from an OpenVZ container, based on Debian 7: after the boot I had to wait ~ 2 minutes before the container to be reachable from the outside network.

I noticed that the delay was caused by several SLEEP commands contained in /etc/init/failsafe.conf

As suggested on ASKUBUNTU (sorry, but I'm not allowed to post external links) I commented the sleep commands and now it is reachable from the network as the other LXCs.

Bye

That's it, thanks!!