Все,
В настоящее время мы запускаем виртуальную машину CentOS на нашем сервере через VMWare. Я столкнулся с низкой производительностью сверхурочной работы. При первоначальном создании сервера скорость чрезвычайно высока, но со временем становится невероятно медленной.
Я немного сбит с толку, потому что мы не используем своп и наша нагрузка не ужасна.
Вот мой главный результат:
top - 15:38:49 up 1:10, 13 users, load average: 6.94, 6.92, 6.31
Tasks: 165 total, 7 running, 158 sleeping, 0 stopped, 0 zombie
Cpu(s): 50.0%us, 50.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16189104k total, 14704772k used, 1484332k free, 61140k buffers
Swap: 4095992k total, 0k used, 4095992k free, 1201532k cached
Самый ресурсоемкий элемент ЦП -
PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20 0 1969m 1.1g 10m S 2.5 7.4 3:39.35 java
Я уверен, что это что-то глупое, что мне не хватает, но на данный момент требуется 20 секунд, чтобы передать SU другому пользователю.
Если у вас установлен strace (yum install strace), можете ли вы найти команду, которая работает медленно (вы упомянули su в своем сообщении), и запустить ее под strace -cf:
# strace -F -c su - gonzo -c exit
...
Process 3583 detached
Process 3562 resumed
Process 3563 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
95.10 0.291882 7484 39 18 waitpid
2.01 0.006160 474 13 execve
0.77 0.002359 24 98 munmap
0.75 0.002310 110 21 clone
0.32 0.000973 24 41 mprotect
0.19 0.000586 3 194 rt_sigaction
0.18 0.000556 3 211 read
0.16 0.000497 2 263 mmap2
0.15 0.000471 43 11 write
0.10 0.000301 2 184 2 open
0.05 0.000151 0 418 rt_sigprocmask
0.04 0.000119 7 17 getrlimit
0.04 0.000116 1 157 fstat64
0.03 0.000101 1 75 23 access
0.02 0.000065 0 270 5 close
0.02 0.000061 1 98 fcntl64
0.02 0.000052 2 23 22 connect
0.01 0.000034 1 67 17 stat64
0.01 0.000032 1 25 getuid32
0.01 0.000031 2 18 sigreturn
0.01 0.000030 1 37 brk
0.01 0.000029 7 4 setreuid32
0.00 0.000000 0 1 chdir
0.00 0.000000 0 4 time
0.00 0.000000 0 1 getpid
0.00 0.000000 0 3 alarm
0.00 0.000000 0 9 pipe
0.00 0.000000 0 7 ioctl
0.00 0.000000 0 1 umask
0.00 0.000000 0 28 dup2
0.00 0.000000 0 1 getppid
0.00 0.000000 0 1 getpgrp
0.00 0.000000 0 1 setsid
0.00 0.000000 0 1 setrlimit
0.00 0.000000 0 8 readlink
0.00 0.000000 0 1 getpriority
0.00 0.000000 0 1 setpriority
0.00 0.000000 0 2 uname
0.00 0.000000 0 2 _llseek
0.00 0.000000 0 6 poll
0.00 0.000000 0 1 getcwd
0.00 0.000000 0 16 getgid32
0.00 0.000000 0 16 geteuid32
0.00 0.000000 0 16 getegid32
0.00 0.000000 0 4 setregid32
0.00 0.000000 0 1 setgroups32
0.00 0.000000 0 1 setuid32
0.00 0.000000 0 1 setgid32
0.00 0.000000 0 6 getdents64
0.00 0.000000 0 11 gettid
0.00 0.000000 0 13 set_thread_area
0.00 0.000000 0 3 keyctl
0.00 0.000000 0 29 socket
0.00 0.000000 0 2 send
0.00 0.000000 0 6 sendto
0.00 0.000000 0 12 recvfrom
------ ----------- ----------- --------- --------- ----------------
100.00 0.306916 2500 87 total
После этого вы сможете увидеть, в каких системных вызовах используется время, что может дать нам представление о том, что вызывает медлительность.
strace -tT также может оказаться полезным.
Вы также можете прикрепить strace к запущенным процессам (strace -p) и узнать больше о том, что они делают.
Вопрос: Если остановить все java-процессы, средняя нагрузка начнет снижаться?
Установите / обновите инструменты VMware. Включите поддержку виртуализации в BIOS физического сервера (у вас будет такая возможность, если ваш процессор поддерживает это). Какое решение виртуализации от VMware вы используете? Проверьте производительность как на гостевой (ВМ), так и на хост-машине (сервер VMware). Пожалуйста, укажите, где верхний - от гостя или от хозяина. Сколько памяти у вас есть на хосте и сколько выделено гостевой? Есть ли у вас чрезмерное выделение памяти для виртуальных машин? Меняется ли хост?
Вы дали гостю меньше виртуальных ЦП, чем ваш хост-компьютер, не так ли? Я подозреваю, что у вашего гостя два виртуальных процессора. Сколько у хоста?
Избыточная подписка на ЦП может вызвать такое поведение.
Кроме того, есть возможность уменьшить тактовую частоту в гостевой виртуальной машине с помощью CentOS, что может несколько помочь, хотя я не думаю, что это основная причина. Посмотрите на первый пункт в разделе 3 http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.1
Использование системного процессора на 50% очень велико, особенно без какой-либо подкачки или iowait. У вас есть что-то на уровне ядра, пожирающее ресурсы. Скорее всего плохой водитель. Я бы сказал сначала yum-update до нового ядра.
Попробуйте инструменты «iostat» и «vmstat». Они дают вам гораздо больше информации о том, что происходит. Может, «сар» тебе тоже поможет. (Вам необходимо установить пакет «sysstat», чтобы получить инструменты.)
И, пожалуйста, распечатайте здесь вывод этих программ. Тогда мы могли бы вам больше помочь.
Еще одна хорошая вещь - делать то, что вам сказал "Дэйви".
У меня проблема на паре машин, на которых запущен VMWare Server, из-за чего каждая виртуальная машина с течением времени медленно использует все больше и больше ресурсов ЦП. Остановка виртуальных машин и перезапуск затем решают проблему, хотя их перезагрузка или приостановка + возобновление - нет.
Это легче всего увидеть на сервере с низкими характеристиками (старый P4), на котором работают три виртуальные машины, на которых запущены базовые веб-службы: график внизу эта страница показывает измеренное влияние на использование ЦП с течением времени и внизу эта страница вы можете увидеть эффект, измеренный по показаниям «средней нагрузки». Эффект гораздо менее заметен на других машинах, на которых я запускаю VMWare, потому что они гораздо более мощные в целом. Эффект пропорционален количеству запущенных виртуальных машин (т. Е. Фантомная нагрузка увеличивается в два раза быстрее, если работает в два раза больше виртуальных машин). До сих пор остановка и перезапуск виртуальных машин всегда решали проблему - перезагрузка хост-машины не нужна (хотя, если хост должен перезагрузиться для чего-то вроде обновления ядра, имеет смысл координировать эту перезагрузку с выходом виртуальных машин).