OpenVZ performarce issues

[asmar]

Hi,

I've migrated a large web site from a dedicated server to an OpenVZ vm and having issues with very slow response. I've increased the cpu units to 500000, all 8 cores and 32GB of RAM but still very small improvement.

Is it anything else that I can configure to give the max resources to this vm?

My vm conf is:

ONBOOT="no"

PHYSPAGES="0:8388608"
SWAPPAGES="0:4192M"
KMEMSIZE="15617490944:17179869184"
DCACHESIZE="7808745472:8589934592"
LOCKEDPAGES="unlimited"
PRIVVMPAGES="unlimited"
SHMPAGES="unlimited"
NUMPROC="unlimited"
VMGUARPAGES="0:unlimited"
OOMGUARPAGES="0:unlimited"
NUMTCPSOCK="unlimited"
NUMFLOCK="unlimited"
NUMPTY="unlimited"
NUMSIGINFO="unlimited"
TCPSNDBUF="unlimited"
TCPRCVBUF="unlimited"
OTHERSOCKBUF="unlimited"
DGRAMRCVBUF="unlimited"
NUMOTHERSOCK="unlimited"
NUMFILE="unlimited"
NUMIPTENT="unlimited"

# Disk quota parameters (in form of softlimit:hardlimit)
DISKSPACE="60G:66G"
DISKINODES="12000000:13200000"
QUOTATIME="0"
QUOTAUGIDLIMIT="0"

# CPU fair scheduler parameter
CPUUNITS="1000"
CPUS="8"

 

[udo]

Hi,

I've migrated a large web site from a dedicated server to an OpenVZ vm and having issues with very slow response. I've increased the cpu units to 500000, all 8 cores and 32GB of RAM but still very small improvement.

Is it anything else that I can configure to give the max resources to this vm?

...

Hi,
try to find the bottleneck!

Perhaps io-related?
What is the output of

pveperf /var/lib/vz

Udo

 

[asmar]

root@proxmox3:~# pveperf /var/lib/vz
CPU BOGOMIPS: 44798.24
REGEX/SECOND: 1485016
HD SIZE: 370.22 GB (/dev/mapper/pve-data)
BUFFERED READS: 187.26 MB/sec
AVERAGE SEEK TIME: 4.61 ms
FSYNCS/SECOND: 56.79
DNS EXT: 144.17 ms
DNS INT: 61.56 ms

 

[udo]

Hi,
fsyncs are low. What kind of storage is it?
One sas-hdd?

If your openvz-CT is slow, do you see io-waits in top?

Udo

 

[asmar]

Hi Udo,

There are 2 sas drives on HW raid 1.
No io-waits in top.

Thanks a lot

 

[udo]

Hi,
then your raid-controller don't have cache (because no BBU?).

Normaly fsyncs should be > 1000 (on my system I got more than 3k).
But if this is the issue, you should see io-waits...

Try to find inside your CT why the system is laggy. About the fsyncs: if you have an SSD, you can try to mount an SSD and move CT on SSD-space.

Another possibility: how do you mounted (and what filesystem) the ct-storage?

Can you post the output of "mount"?

Udo

 

[asmar]

Hi Udo,

yes, there is no cache. It's not possible to move it to SSD at the moment.
The site was working fine on a single i7 with 8GB of RAM and 2x160GB SATA drives so can't understand how it can be a disk related issue. I've got no other VMs on this server.

The output of mount can be found below.

root@proxmox3:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=12366603,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=9895248k,mode=755)
/dev/mapper/pve-root on / type ext3 (rw,relatime,errors=remount-ro,user_xattr,acl,barrier=0,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=19790480k)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/mapper/pve-data on /var/lib/vz type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered)
/dev/sda2 on /boot type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
/dev/fuse on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
beancounter on /proc/vz/beancounter type cgroup (rw,relatime,blkio,name=beancounter)
container on /proc/vz/container type cgroup (rw,relatime,freezer,devices,name=container)
fairsched on /proc/vz/fairsched type cgroup (rw,relatime,cpuacct,cpu,cpuset,name=fairsched)