slow console service

[foster29]

This is a followup to a post that I had earlier in the week regarding service console performance. At the time any script run within the console would consume all the CPU0, once the task was completed the CPU would remain at 0. This issue no longer exisit, scripts executed in the console consume normal levels of cpu while executing.

However the intial problem is still around. My copy, migrate, moving files via the console is taking around 5 to 6xs longer today than a week ago. Any additional suggestions would be appreciated

[ronzo]

A couple things to help in the console.

Up the console memory, the default install of 272M is not enough for the console run. Give it at leas 500m or 800M.

If you are going to be doing stuff in the console, go ahead an upd the CPU for the console. The default is pretty low..

When you do your stuff in the console, run 'top -c -d1' on another putty, anything besides the copy using up CPU?

And you might want to test your disk I/O. using phdcat.

http://www.vmware.com/community/thread.jspa?messageID=621817&#621817

thanks

ron

[bertdb]

ronzo, can you explain what is eating up your memory ? What extra processes are you running that need the extra 200-500 MB of memory ?

We are talking about ESX3 here, in my opinion 272M is OK if you don't install extra software in the Service Console (backup agents, system management agents, ...)

[bertdb]

foster29, if I was investigating this, I'd install the "dstat" tool and use it to check the Service Console and - more important - the VMkernel I/O during the operations that take too long.

get http://dag.wieers.com/rpm/packages/dstat/dstat-0.6.6-1.el3.rf.noarch.rpm, and install it using "rpm -Uvh dstat*rpm".

Then run (as root)

dstat -M vmkhba -d

You'll be able to investigate the bandwidth used, and compare that to the normal rates you'd expect.

[ronzo]

bertdb-

If you install Vi3 with the default memory of 272M, the JAVA back-end of VMware can barely keep up. Run and watch top.. As soon as you start creating, powering, changing VM configurations, the console will start swapping memory.

Also if you use VC, if you have hosts that are dropping out and coming back all the time, increasing the console memory will help and usually fix this.

In ESX 2.5, the 272M was enough, but not in VI3.

But as you say, if you install all type of other software (dell/hp agents) then more memory is required.

thanks

ron

[foster29]

in working with this further the following happened. When attempting to execute a scheduled task (copying a existing VM) the operation timed out? could this be related to my slow console performance?

whats the command to restart the service console?

Message was edited by:

foster29

[Texiwill]

Hello,

Yes it could be related. To change the memory of the SC you should first change this setting by using the VI client. It can also be done from the SC.

If you 'restart' the SC you will reboot your ESX server. Be sure you want to do that and that any running VMs are vMotioned off.

It really sounds like you have a runaway process.

Best regards,

Edward

[foster29]

Ok, had a call with VM support this morning and i'm still in the same boat. The service console is very close to coming to a complete halt in terms of functionality.

How many services is normal to be running in the service console. I currently have 161 running after restarting the service console, this number will continue to grow on its own in upwards of 300 processes. Trying to execute a script from the console at this point is useless

Currently I have over 50 Process labled Web access running. Any thoughts at all, i'm pretty much stuck at this point

In the past 10 minutes the number of processes has increased to 191

Process Information:

161 processes: 160 sleeping, 1 running, 0 zombie, 0 stopped

Message was edited by:

foster29