Тормоза VM на ESX 4.0.0

[nihon]

Добрый день.

Приключилась такая неприятность:

на Proliant 160 G5 с ESX 4, развернуто 2 виртуалки.

Вчера создали ещё одну под ос RHEL 64-bit. Установили vmware tools.

Сейчас наблюдае деградация в производительности. Выполнение комманд date, ls и тп занимает около 2 сек.

На самом сервере ресурсов море и драки между виртуалками за них нет. Подскажите, что можно помониторить, чтобы понять и исправить данную ситуацию.

Спасибо!

[FondRGS]

> Вчера создали ещё одну под ос RHEL 64-bit. Установили vmware tools.

И Что Вам показывает команда top внутри RHEL 64-bit?

WBR, N-ff

[Deshifrator]

У Вас тормозят все три ВМ?

Неплохо было бы увидеть top RHEL'a и esxtop в разрезе VM и по дискам.

P.S.

У меня что-то подобное было, только на физическом сервере под управлением FreeBSD. Но тогда причина было в том, что сервер выключился по питанию, а, после включения, fsck его напрочь ложил на час другой. Были такие же задержки (2-4 сек).

[nihon]

Примерно так

top - 14:18:46 up 14 min,  2 users,  load average: 0.64, 0.24, 0.14

Tasks: 144 total,   3 running, 141 sleeping,   0 stopped,   0 zombie

Cpu(s):  0.6%us,  0.4%sy,  0.0%ni, 98.9%id,  0.0%wa,  0.1%hi,  0.1%si,  0.0%st

Mem:   6106980k total,   534740k used,  5572240k free,    26452k buffers

Swap:  4192956k total,        0k used,  4192956k free,   328784k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           

5370 oracle    15   0  261m  14m 8448 S  1.3  0.2   0:00.32 gnome-terminal    

4177 root      15   0 85512 9380 5020 R  1.0  0.2   0:01.03 Xorg              

4671 oracle    15   0  150m 7476 5576 S  0.4  0.1   0:00.12 metacity          

4651 oracle    16   0 87824 3896 1700 S  0.1  0.1   0:00.21 gconfd-2          

    1 root      15   0 10344  684  572 S  0.0  0.0   0:00.66 init              

    2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.02 migration/0       

    3 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0       

    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0        

    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/1       

    6 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/1       

    7 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/1        

    8 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/2       

    9 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/2       

   10 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/2        

   11 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/3       

   12 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/3       

   13 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/3 

[nihon]

Тормозит только эта ВМ. К железке пока доступ не дают, запросил статистику..

[Deshifrator]

Cpu(s):  0.6%us,  0.4%sy,  0.0%ni, 98.9%id,  0.0%wa,  0.1%hi,  0.1%si,  0.0%st

1. us -> User CPU time: The time the CPU has spent running users’ processes that are not niced.

2. sy -> System CPU time: The time the CPU has spent running the kernel and its processes.

3. ni -> Nice CPU time: The time the CPU has spent running users’ proccess that have been niced.

4. wa -> iowait: Amount of time the CPU has been waiting for I/O to complete.

5. hi -> Hardware IRQ: The amount of time the CPU has been servicing hardware interrupts.

6. si -> Software Interrupts.: The amount of time the CPU has been servicing software interrupts.

0.0%wa -> показатель того, что с дисковой подсистемой проблем у Вас нет (помониторьте данный показатель подольше, посмотрите не “прыгает” ли он).

В приведенном выше top нечего криминального нет. Все в порядке ( в плане производительности).

Видимо нужно копать в другую сторону. Вы к серверу как подключаетесь? (VNC/ssh/telnet/console).

Может у Вас больше задержки между вашим ПК и сервером? Какой канал между Вами и сервером?

P.S.

По top видно что ВМ не тормозит. А причины задержек в 2 сек кроются в чем-то другом.