manual update very very slow

4.8.1169
I didn’t time it, but after clicking for a manual update, it takes at least a minute or two before anything happens. Then everything is in super slow motion. It eventually finishes but something is surely wrong. It was always reasonably fast in the past.

Your concern seems to be related to this thread.

If you have some actual timings we can compare then it is hard to have a discussion with “I recall” or “reasonably fast”.

Thanks. I read the thread and didn’t see any solutions. Same system here as it has been for the last few years, and always before the updates were reasonably fast. Now they’re super slow. I mean if the latest update is already installed, so no update is necessary, it still takes a minute or two after pressing the update button for anything to happen. Something is wrong.

I guess that my point is … the response is always instant in my case.

What evidence can you give us to take a look at.

The evidence is my observation that it is not working right.

Difficult to troubleshoot… does the update finished?

Read my original post.
I’m outa this stupid forum and will go back to free AVG.
Goodbye.

Well… there is no place for hard feelings. We’re trying to help.
If you want you’ll get it into AVG, go ahead…

Nice attitude for someone with a Peace symbol for their avatar ???

We are only trying to help you, it would have been just as easy to have said, '“It does complete, as I mentioned in my first post.”

Good luck with AVG and their forums.

This may be too late but before you leave, how about just taking a deep breath and watch a floating cloud like this one? ;D

http://msnbcmedia2.msn.com/j/msnbc/Components/Photo_StoryLevel/080416/080416-flogo-peace-hmed.hmedium.jpg

Back on topic.

Do you mean update process does not only take time but it also slows down whole the system? If so, it is definitely odd since the process may take time depending on the connection but it shouldn’t be such a load on whole the system…except probably heavy program updates, which shouldn’t be a case because you probably meant VPS update considering 4.8.1169 was released almost a month ago. I agree it sounds odd. I wonder how ordinarily VPS update can slow down whole the system at annoying level?

Rumpelstiltskin,

the process may take time depending on the connection but it shouldn't be such a load on whole the system

This is really not correct at all … please read the explanation in the thread I linked to at the top of this thread.

Probably because of my lack of understating on how Avast’s VPS update works, I took it’s all about program update when I skimmed the thread first time. I knew Avast’s each update takes time but I thought it was the same reason for AntiVir, which seems to be suffering from the scarce server resource. Seems I totally mixed them up. Honestly, I haven’t noticed Avast VPS update has been so resource intensive. Most likely I thought the slow-down was just a part of start up process since I rarely update manually.

And it is not… the automatic update runs at lower priority. The manual, of course, as invoked by the user himself, will run at high priority.

Yous beat me totally. ;D

That explains a lot. So, if someone who hasn’t updated VPS for a while manually updates it, then, it can be really resource intensive although the recent program tweaks are aimed to make it less problematic? Now I wonder if this is the case of JohnnyBob’s…well…

Whether the update runs at normal priority or lower priority is not entirely relevant. The avast process of updating the virus database still is very CPU intensive (as acknowledged by the avast team) and whichever way it is run still takes exactly the same number of CPU seconds/minutes to complete.

To say it is not is simply ignoring facts.

I believe that the issue here may well be different - if we could have got more information.

The “nothing happening for a minute or two” is not normal for a manual update.

Just out of interest I ran two manual updates (even though my VPS is up to date) and both told me I am up to date:

  1. avast on demand manual update:

Download 1s Total time 8s

  1. VPSUPD.exe download

Download 3s. Total time 4s

During the first 4.8 beta I was doing a lot of restoring back to avast 4.7 (to perform comparisons with 4.8 ). What became very clear to me in that time was that if you are more than a few days behind on VPS updates it is very much faster (at least for broadband users) to download and run the VPSUPD.exe file.

Oh dear … where to begin?

I have done some further testing … and …

Seems I may well owe an apology to JohnnyBob if he is still reading for - well at least for not asking the right questions - and I offer the apology without reservation.

Since Tech was way off the mark too maybe we can both learn something together.

I do not know how many of you reading this (even the evangelists) ever bother to pay too much attention to the avast setup log. It is rather verbose and if you are like me (and I hazard a guess this even applies to the avast team) I only pay close attention to the part that I am really interested in for any given problem.

I have tended to assume (even though reality runs counter to intuition) that avast VPS manual updates really differ hardly at all from the automatic updates. I have allowed my intuition (rather than the hard slog of detailed testing) to guide me in posting to others in the forum on this matter. While it would seem reasonable to me that the avast team would, logically, endeavor to make the differences minimal this is not the case.

I am also disturbed by the fact that the avast team have chosen not to correct the errors that both Tech and I have posted in this forum about the workings of the avast VPS updates within the past days.

If I now malign the avast team I am sure they may choose to respond but my recent testing indicates:

  1. The Windows priority setting of an avast update is “Below normal” for both automatic updates and manual updates.
  2. The avast automatic updates contain a parameter “/limitcpu” and that this parameter does not apply to manual updates
  3. I have posted in this forum as though the /limitcpu parameter (whereby avast attempts to ensure that the CPU intensive nature of avast updates does not push CPU utilization above 30% and so ensures little or no degradation of overall system performance) applied to all VPS updates. I was wrong.
  4. It is now clear that, without the /limitcpu parameter on manual updates avast.setup easily consumes >90% CPU utilization and where there is a significant update gap to be covered will severely degrade system performance.
  5. The logic of restricting avast CPU utilization on automatic updates is clear. The logic, if it exists, for not applying that restriction on manual updates completely escapes me.

So, if anyone managed to stay this far:

If you have the avast VPS update settings set to manual and you are more than a few days of avast updates behind I must recommend:

  1. download from the avast site and run the VPSUPD.exe file to bring you up to date (if you are on broadband by far the best option)

-or-

  1. temporarily set your avast VPS update settings to automatic and wait for an update or restart your system. The avast update will automatically update and limit the use of your CPU to no more than 30%.

-or-

  1. perform a manual update - go away … clean the house, do the laundry, run your chores … when you get back the system should be usable.

Seems you are right here.

I missed that part since it’s quite normal for automatic update: A few minutes after start-up, the notice about VPS update almost always pops up…I thought it was due to connection rather than Avast’s trying not to get in the way of other processes as explained in the other thread, though.

I searched the boards and post some references here for someone interested.
“Saving package, this may take a while…” Question for Vlk, Igor.
No problem, query about some update’s speed.
How do I configure aswServ.exe (on managed clients) to use “Normal” priority?

Above, alanrf did a good job on summarizing but I think I can add something here.

The Logic is Avast! assumes users want update when they manually update. ;D

Then … I very much regret to say, as one who has also had much dealing with user’s expectations, that Vlk’s assumption is foolish in the extreme.

avast is only, just, nothing more than another application we choose to employ on our systems. We want it to behave in a way that does not disrupt the ability of our operating system or the general availability of our systems to run.

If it chooses to deploy itself in a way that does disrupt, against the wishes of its users, then it may join those many others - free or not - in the “whatever happened to?” list of products - much to my personal sadness.

The CPU limit has been inplemented because some users complained that the update started in the middle of an intensive CPU task (game) and disrupted their gaming experience. This makes some sense - as the automatic updates may start at any time, and yes, they might be a computationally intensive process if an update really takes place, it’s hard to avoid.
However, if the user invokes the update manually, he is hardly just in the middle of a fullscreen game - and he’s probably got a reason for the update (wants to start an on-demand scan?) So, the update is performed in the usual way.

I mean, how many programs have you seen limit their CPU usage when you start some longish operation? None? It’s normal for a program to perform whatever it’s asked to in the usual way, using as much CPU as needed (there’s even no documented way to limit one’s CPU usage, as far as I know - it’s kind of a trick here). It’s up to the operating system to distribute the CPU usage amongst concurrent programs, if needed.

So, I must say I’m sorry, but I don’t understandat all what do you mean… Yes, avast! is just another application, so it does exactly the same as other applications do. If you ask it to perform some action, it does perform it - in the usual way. Why should it prolong the operation 3 times artificially?

Besides, all this doesn’t explain the original post - on contrary, actually. The more CPU is used, the faster the manual updates should be, right?