Dear Karl,
it is good surprise for me, and I cannot explain why this happen.
Probably following fix was help you:
042stab113.18:
* force charge swapin readahead pages if in ub0 (PSBM-44857)
Backup on host triggered memory reclaim activity inside containers,
and we had few reports about hard
Hi Vasily,
I've upgraded two nodes last week from 113.12 to 113.21 and it seems
better. Backups last weekend took the same time as it was on <=108.8. I'll
still keep an eye on this and also on the development of 115 in OpenVZ Jira.
Thanks!
Karl
On Thu, Mar 31, 2016 at 4:13 AM, Vasily Averin
On 30.03.2016 18:38, Karl Johnson wrote:
> Hi Vasily,
>
> I do indeed use simfs / ext4 / cfq. Only a backup of each containers
> private areas is done with vzdump and then transferred to a backup
> server with ncftpput. Compressing the data is OK while transferring
> the dump over local network
Hi Vasily,
I do indeed use simfs / ext4 / cfq. Only a backup of each containers
private areas is done with vzdump and then transferred to a backup server
with ncftpput. Compressing the data is OK while transferring the dump over
local network peak the load so the issue is with (read) IO. I’m
On 30.03.2016 12:48, Vasily Averin wrote:
> Dear Karl,
>
> thank you for explanation.
> however some details are still not it clear.
>
> I believe you use simfs containers (otherwise you can do not worry about
> PSBM-34244,
> using of 113.12 kernels also confirms it)
> but it isn't clear how
Dear Karl,
thank you for explanation.
however some details are still not it clear.
I believe you use simfs containers (otherwise you can do not worry about
PSBM-34244,
using of 113.12 kernels also confirms it)
but it isn't clear how exactly you backup your nodes.
Do you dump whole partition
You could return to v108 and watch performance again.
El 29/03/16 a les 22:19, Karl Johnson ha escrit:
> Disks are fine and RAID is optimal. It doesn't happen only when backups
> run but it's easier to see during this time. What's strange is that
> there were no issue on <108 kernels.
>
> It
Disks are fine and RAID is optimal. It doesn't happen only when backups run
but it's easier to see during this time. What's strange is that there were
no issue on <108 kernels.
It could have been this following patch from RedHat but 113 isn't based on
2.6.32-573.22.1, 114 will be I think.
**
On 29.03.2016 21:03, Karl Johnson wrote:
Every weekend I do backups of all CT which take a lot of IO. It didn't
affect much load average before 108 but as soon as I upgraded to 113, load
got very high and nodes became sluggish during backups. It might be
something else but I was looking for
Hi Vasily,
Every weekend I do backups of all CT which take a lot of IO. It didn't
affect much load average before 108 but as soon as I upgraded to 113, load
got very high and nodes became sluggish during backups. It might be
something else but I was looking for feedback if someone else had the
Dear Karl,
no, we know nothing about possible performance degradation between
042stab108.x and 042stab113.x kernels.
High load average and CPU peaks are not a problems per se,
it can be caused by increased activity on your nodes.
Could you please explain in more details,
why you believe you
Hello,
Did anyone notice performance degradation after upgrading vzkernel to
042stab113.X? I’ve been running 042stab108.5 on few nodes for a while with
no issue and upgraded to 042stab113.12 few weeks ago to fix an important
CVE and rebase to latest rhel6 kernel.
Since the upgrade from 108.5 to
12 matches
Mail list logo
