out of memory in UB
- Thread starter c0mputerking
- Start date
Thanks for the reply and here is the output
# pveversion -v
pve-manager: 2.1-14 (pve-manager/2.1/f32f3f46)
running kernel: 2.6.32-14-pve
proxmox-ve-2.6.32: 2.1-74
pve-kernel-2.6.32-14-pve: 2.6.32-74
pve-kernel-2.6.32-6-pve: 2.6.32-55
pve-kernel-2.6.32-7-pve: 2.6.32-60
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.3-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.92-3
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.8-1
pve-cluster: 1.0-27
qemu-server: 2.0-49
pve-firmware: 1.0-18
libpve-common-perl: 1.0-30
libpve-access-control: 1.0-24
libpve-storage-perl: 2.0-31
vncterm: 1.0-3
vzctl: 3.0.30-2pve5
vzprocps: 2.0.11-2
vzquota: 3.0.12-3
pve-qemu-kvm: 1.1-8
ksm-control-daemon: 1.1-1
# pveversion -v
pve-manager: 2.1-14 (pve-manager/2.1/f32f3f46)
running kernel: 2.6.32-14-pve
proxmox-ve-2.6.32: 2.1-74
pve-kernel-2.6.32-14-pve: 2.6.32-74
pve-kernel-2.6.32-6-pve: 2.6.32-55
pve-kernel-2.6.32-7-pve: 2.6.32-60
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.3-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.92-3
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.8-1
pve-cluster: 1.0-27
qemu-server: 2.0-49
pve-firmware: 1.0-18
libpve-common-perl: 1.0-30
libpve-access-control: 1.0-24
libpve-storage-perl: 2.0-31
vncterm: 1.0-3
vzctl: 3.0.30-2pve5
vzprocps: 2.0.11-2
vzquota: 3.0.12-3
pve-qemu-kvm: 1.1-8
ksm-control-daemon: 1.1-1
update to latest version, see http://pve.proxmox.com/wiki/Downloads#Update_a_running_Proxmox_Virtual_Environment_2.x_to_latest_2.2
and then check the memory consumption inside your backuppc container. analyse how much memory do you need for this application and then assign more ram if needed.
and then check the memory consumption inside your backuppc container. analyse how much memory do you need for this application and then assign more ram if needed.
I thought i was getting the latest version, not sure what i am missing here, but my proxmox repo line looks the same as the one in the post you have mentioned. Except for the non-free part using a dell r410 and it was the only way i could get the network cards to work using the debian non-free install cd. The non-free is left over from then and i was not sure if it would break my networking cards by removing it
deb http://ftp.ca.debian.org/debian/ squeeze main non-free contrib
deb-src http://ftp.ca.debian.org/debian/ squeeze main non-free contrib
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free
# PVE packages provided by proxmox.com
deb http://download.proxmox.com/debian squeeze pve
I have also tried using this, but also not working which brings me back to my other post today http://forum.proxmox.com/threads/11953-Problems-doing-dist-upgrade
deb http://http.at.debian.org/debian squeeze main contrib # PVE packages provided by proxmox.com deb http://download.proxmox.com/debian squeeze pve # security updates deb http://security.debian.org/ squeeze/updates main contrib
deb http://ftp.ca.debian.org/debian/ squeeze main non-free contrib
deb-src http://ftp.ca.debian.org/debian/ squeeze main non-free contrib
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free
# PVE packages provided by proxmox.com
deb http://download.proxmox.com/debian squeeze pve
I have also tried using this, but also not working which brings me back to my other post today http://forum.proxmox.com/threads/11953-Problems-doing-dist-upgrade
deb http://http.at.debian.org/debian squeeze main contrib # PVE packages provided by proxmox.com deb http://download.proxmox.com/debian squeeze pve # security updates deb http://security.debian.org/ squeeze/updates main contrib
Ok i am running the latest version now it was enough of a struggle to get my system to update that i will include a pveversion -v below
Something curious here this vz container is running backuppc and has 1G of RAM and 512M of swap assigned which it eventually uses all of both, then gets some failcounts. Also the hypervisor starts out using less than 7G of RAM, but during this backup it scales up to over 12G in the Web interface. One more thing of importance the Web GUI states under 13G of RAM out of 16G but a ps shows all the RAM on the hyper visor is being used and even some swapping going on not cool. Lastly there is no processes listed as using all the ram? its just gone not sure what to do or where to loolk here, thankfully proxmox eventually kills the backuppc process before it melts my server.
Mem: 16413124k total, 16353684k used, 59440k free, 2885560k buffers
Swap: 1949688k total, 463016k used, 1486672k free, 284356k cached
pve-manager: 2.2-31 (pve-manager/2.2/e94e95e9)
running kernel: 2.6.32-16-pve
proxmox-ve-2.6.32: 2.2-82
pve-kernel-2.6.32-16-pve: 2.6.32-82
pve-kernel-2.6.32-14-pve: 2.6.32-74
pve-kernel-2.6.32-6-pve: 2.6.32-55
pve-kernel-2.6.32-7-pve: 2.6.32-60
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.4-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.93-2
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.9-1
pve-cluster: 1.0-33
qemu-server: 2.0-69
pve-firmware: 1.0-21
libpve-common-perl: 1.0-39
libpve-access-control: 1.0-25
libpve-storage-perl: 2.0-36
vncterm: 1.0-3
vzctl: 4.0-1pve2
vzprocps: 2.0.11-2
vzquota: 3.1-1
pve-qemu-kvm: 1.2-7
ksm-control-daemon: 1.1-1
.
NOTE this openvz container is being used to backup the actual proxmox hypervisor that it lives within i do not remember having issues with this before and is a new problem
Something curious here this vz container is running backuppc and has 1G of RAM and 512M of swap assigned which it eventually uses all of both, then gets some failcounts. Also the hypervisor starts out using less than 7G of RAM, but during this backup it scales up to over 12G in the Web interface. One more thing of importance the Web GUI states under 13G of RAM out of 16G but a ps shows all the RAM on the hyper visor is being used and even some swapping going on not cool. Lastly there is no processes listed as using all the ram? its just gone not sure what to do or where to loolk here, thankfully proxmox eventually kills the backuppc process before it melts my server.
Mem: 16413124k total, 16353684k used, 59440k free, 2885560k buffers
Swap: 1949688k total, 463016k used, 1486672k free, 284356k cached
pve-manager: 2.2-31 (pve-manager/2.2/e94e95e9)
running kernel: 2.6.32-16-pve
proxmox-ve-2.6.32: 2.2-82
pve-kernel-2.6.32-16-pve: 2.6.32-82
pve-kernel-2.6.32-14-pve: 2.6.32-74
pve-kernel-2.6.32-6-pve: 2.6.32-55
pve-kernel-2.6.32-7-pve: 2.6.32-60
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.4-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.93-2
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.9-1
pve-cluster: 1.0-33
qemu-server: 2.0-69
pve-firmware: 1.0-21
libpve-common-perl: 1.0-39
libpve-access-control: 1.0-25
libpve-storage-perl: 2.0-36
vncterm: 1.0-3
vzctl: 4.0-1pve2
vzprocps: 2.0.11-2
vzquota: 3.1-1
pve-qemu-kvm: 1.2-7
ksm-control-daemon: 1.1-1
.
NOTE this openvz container is being used to backup the actual proxmox hypervisor that it lives within i do not remember having issues with this before and is a new problem
Last edited:
I have done some more testing an cannot get this solved, i need backups so as a workaround i will try a KVM. However i would really like to get this sorted openvz is my prefer
Ok i am still working on this have moved backuppc that seems to try and break proxmox to a KVM, and i am still experiencing what i think may become an issue for someone (like) me who tries to do something really dumb.\
EDITED ...... sorry my browser decided to post this before i was ready so anyone who read this original post before i figured out what i was doing wrong. Please disregard.
I have managed to stop this problem from occurring, and a usual it was me doing something very wrong i messed up my exclude syntax for backuppc so it was trying to backup itself while it was backing up. Not to make excuses but this gets confusing with weird key system backuppc uses for excludes, also bind mounts all over the place that backuppc does not ignore with the -x switch.
Anyways proxmox did the right thing however i do think it might given the vz container to much RAM before stopping the backuppc command as the vz is/was set to 1GB and promox seemed to give it all the physical RAM on the system for sometime before stopping it is this what is supposes to happen?
OR i guess it could have been proxmox using all the RAM since i was trying to use a VZ to incorrectly backup the physical machine.
While using a KVM it seemed to stop things quicker and not use as much physical RAM
PS my to top never matches my web interlace RAM must be a different average or something
PPS sorry for the mostly bogus post, but i think it turned out to be a great way to stress test proxmox and it survived without even an interruption
EDITED ...... sorry my browser decided to post this before i was ready so anyone who read this original post before i figured out what i was doing wrong. Please disregard.
I have managed to stop this problem from occurring, and a usual it was me doing something very wrong i messed up my exclude syntax for backuppc so it was trying to backup itself while it was backing up. Not to make excuses but this gets confusing with weird key system backuppc uses for excludes, also bind mounts all over the place that backuppc does not ignore with the -x switch.
Anyways proxmox did the right thing however i do think it might given the vz container to much RAM before stopping the backuppc command as the vz is/was set to 1GB and promox seemed to give it all the physical RAM on the system for sometime before stopping it is this what is supposes to happen?
OR i guess it could have been proxmox using all the RAM since i was trying to use a VZ to incorrectly backup the physical machine.
While using a KVM it seemed to stop things quicker and not use as much physical RAM
PS my to top never matches my web interlace RAM must be a different average or something
PPS sorry for the mostly bogus post, but i think it turned out to be a great way to stress test proxmox and it survived without even an interruption
Last edited: