Home » International » Russian » Поведение процессов
Поведение процессов [message #24623] |
Fri, 07 December 2007 01:20 ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
atshellnick
Messages: 9 Registered: December 2007
|
Junior Member |
|
|
День/вечер добрый!
Есть небольшая, но очень не приятная проблема, которая возможно вовсе и не связана с openvz, однако совета хочется испросить именно у вас.
Дело в том, что я собрал на базе OpenVZ web-сервер работающий под нагрузкой 30-40 тыс. хостов в день, до этого я делал подобное на джейлах бсд, однако решил попробывать OpenVZ. Вообщем изучил документацию, разобрался с базовыми приемами работы, настроил и запустил сервер на Gentoo/OpenVZ, перевел часть нагрузки и вообщем все очень даже работает и устраивает...
Однако, при попытке запустить "тяжелый" процесс внутри VE или даже на HW, получаю большие очереди Load Average по всему железному серверу, если такой процесс не завершить, то скопившиеся очередь валидных, рабочих процессов приводит к останову системы. Не подскажите почему такое происходит?
Под "тяжелым" процессом понимается развертывание дампа mysql сжатого gzip или например работа vzctl create 800 --ostemplate ...
Машина DL360G5; 2 x Quad Core 1,6Ghz; 6 GB RAM; HDD SATA.
В чем тут дело я недопонимаю... =(
PS:
Спасибо за OpenVZ, классная штука!
[Updated on: Fri, 07 December 2007 02:59] Report message to a moderator
|
|
|
|
|
|
Re: Поведение процессов [message #24790 is a reply to message #24644] |
Mon, 10 December 2007 15:57 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
atshellnick
Messages: 9 Registered: December 2007
|
Junior Member |
|
|
Огромное спасибо за отклик!
1. Проверил noatime в fstab - присутствует на HN и в опциях монтирования внутри VPS. По mount видно:
/dev/cciss/c0d0p3 on / type ext3 (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
udev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw,nosuid,noexec)
/dev/cciss/c0d0p5 on /home type ext3 (rw,noatime)
/dev/cciss/c0d0p6 on /var type ext3 (rw,noatime)
/dev/cciss/c0d0p7 on /usr type ext3 (rw,noatime)
/dev/cciss/c0d0p8 on /vz type ext3 (rw,noatime)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)
...
2. Мысль насчет свопирования привела к обнаружению досадного ляпа, у меня был отключен high memory support в ядре при физических 6GB ОЗУ. После включения этой опции и перезагрузки сервера система обнаружила все 6GB, до этого она видела соотв. 4GB.
22:56:47@~ #-> free -m
total used free shared buffers cached
Mem: 6077 3239 2837 0 116 2332
-/+ buffers/cache: 791 5286
Swap: 7634 0 7634
Дистрибутив Gentoo 32-bit. Хотел сразу поставить 64-bit, но меня напугали тем, что в 64-битных релизах плохая поддержка драйверов.
3. После этого смоделировал ситуацию развертывания дампа и начал по вашему совету анализировать STATE и WCHAN.
NB!
Прежде всего хочу сказать, что сервер у меня поделен 6-ю VPS, один из которых выделен исключительно mysqld, в остальных работают форумы написанные на php, который работает модулем под Apache/2.0.58, который используется как backend к nginx.
Вообщем при развертывании дампа mysql получаю на HN, вот что:
ps axl | grep " D"
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 60 27286 26954 16 0 417032 125420 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 27296 26954 16 0 417032 125420 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 27388 26954 16 0 417032 125420 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 27447 26954 16 0 417032 125420 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29037 26954 18 0 416700 125300 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29072 26954 16 0 416700 125304 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29090 26954 18 0 416700 125304 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29101 26954 16 0 416700 125308 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29131 26954 17 0 416700 125324 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29140 26954 16 0 416700 125324 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29148 26954 17 0 416700 125324 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29182 26954 16 0 416700 125344 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29208 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29211 26954 18 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29216 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29219 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29220 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29223 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29248 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29279 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29302 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29305 26954 17 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29352 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29359 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29382 26954 16 0 416700 125428 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29465 26954 16 0 416700 125432 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29476 26954 18 0 416700 125432 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1 60 29497 26954 16 0 416700 125432 sync_p D ? 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
...
и т.д.
Вообщем как видно - они все встают в sync_p в столбце WCHAN.
И вот что это такое я не знаю =(
Системщики! =) Поделитесь тайными знаниями насчет понимания sync_p, в поиске по манам и в сети, толком ничего не нарыл.
PS:
Соотв. понятно почему сервер останавливается при этой операции, узкое место mysqld, надо наверно более тщательно выверять его настройки...
[Updated on: Mon, 10 December 2007 16:00] Report message to a moderator
|
|
|
|
Re: Поведение процессов [message #24897 is a reply to message #24853] |
Tue, 11 December 2007 19:43 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
atshellnick
Messages: 9 Registered: December 2007
|
Junior Member |
|
|
Собрал vzps и начал опять распаковывать нечто большое gunzip в контексте HN. Вот такие очереди теперь выстраиваются:
Причем в wchan стоит "-". Штатный ps тоже показывает "-" в wchan.
Добиться состояния "sync_p" теперь почему-то не получается. А очереди вырастают мгновенно, скачком до 15-20 процессов.
22:11:40@~ #-> vzps ax -o veid,pid,ppid,stat,comm,wchan | grep " D"
0 4348 27 DW< kjournald sync_buffer
800 10846 10845 D nginx sync_buffer
800 10847 10845 D nginx -
701 28676 27630 D apache2 -
701 28678 27630 D apache2 -
701 13177 13161 D apache2 -
701 13178 13161 D apache2 -
701 31728 31711 D apache2 -
701 31729 31711 D apache2 -
701 31733 31711 D apache2 -
701 531 522 D apache2 -
701 594 581 D apache2 -
701 599 581 D apache2 -
701 2909 2906 D apache2 -
701 2910 2906 D apache2 -
701 2915 2906 D apache2 -
701 12589 12580 D apache2 -
701 12590 12580 D apache2 -
701 12591 12580 D apache2 -
701 12642 12637 D apache2 -
701 12643 12637 D apache2 -
701 12649 12637 D apache2 -
701 12650 12637 D apache2 -
701 14718 14682 D apache2 -
701 19099 19096 D apache2 -
701 19103 19096 D apache2 -
701 19106 19096 D apache2 -
701 19220 19214 D apache2 -
701 19276 19262 D apache2 -
701 19278 19262 D apache2 -
701 19282 19262 D apache2 sync_buffer
701 19283 19262 D apache2 -
701 24886 24884 D apache2 -
701 24891 24884 D apache2 -
701 24894 24884 D apache2 -
701 27305 27299 D apache2 -
701 27310 27299 D apache2 -
701 28936 28934 D apache2 -
701 28943 28934 D apache2 -
701 4163 4157 D apache2 -
701 4167 4157 D apache2 -
701 4169 4157 D apache2 -
701 4180 4159 D apache2 -
701 4230 4227 D apache2 -
701 4232 4227 D apache2 -
701 4233 4227 D apache2 -
701 4234 4227 D apache2 -
701 4236 4227 D apache2 -
701 4239 4227 D apache2 -
701 4253 4243 D apache2 -
701 4268 4243 D apache2 -
701 4270 4247 D apache2 -
В маунт поинтс я отрезал только подмонтированные gentoo portages к нескольким VPS (дерево пакетов, на всяк случай, пока идет "строительство" в VPS)
CIFS и NFS не используется на сервере.
701 - это как раз форум vBulletin - модули php под апаче. VPS в котором работает mysqld в этой серии экспериментов не проявлял себя в D-state.
Спасибо за информацию по 64-bit мне она тоже показалась абсурдной! Хотя я в таких тонкостях не разбираюсь.
[Updated on: Tue, 11 December 2007 19:58] Report message to a moderator
|
|
|
|
|
Re: Поведение процессов [message #25224 is a reply to message #25209] |
Tue, 18 December 2007 05:42 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
vaverin
Messages: 708 Registered: September 2005
|
Senior Member |
|
|
CPUUMITS -- это относительная величина, ее надо рассматривать как вес VE. По CPUUNITS определяется fair share CPU для VE, и VE может рассчитывать, что эту свою fair share она получит всегда, даже на полностью загруженной ноде.
Если на ноде есть свободный ресурс -- то VE может его использовать.
Если же VE свою долю не использует -- этот ресурс будут использовать другие VE.
Примеры: 2 VE c одинаковым весом + VE0, все активно работают
VE0 = VEx = VEy
fair share каждой VE -- 1/3, то есть каждая VE получит треть процессорного времени.
Теперь пусть одна из VE свою задачу выполнила и перестала потреблять CPU. В этом случае остальные VE станут получать по 1/2 CPU.
Теперь вторая VE тоже все сделала и CPU ей тоже больше не нужен -- в этом случае оставшаяся VE сможет юзать все процессорное время.
Однако тут надо отметить следующий момент: В VE0 ранятся системные треды: kjournald, kswapd и другие. Эти треды обеспечивают нормльную работоспособность всей системы -- пишут на диск, память чистят. Если этим процессам не давать CPU для решения этих задач -- встанет вся система: процессы внутри VE будут ждать пока им почистят память, а память чистится медленно потому что kswapd не дают CPU.
Поэтому вес VE0 должен быть в несколько раз выше веса самой крупной VE. Отчасти по этой причине мы не рекомендуем оставлять какие-либо тяжелые процессы в VE0.
Для fair share абсолютная велчина CPUunits не важна, ваджно соотоношение этих величин назначенных для VE.
то есть можно поставить всем по 100 cpuunits, можно по 1000, можно по 10000. главное -- соблюсти требуемую пропорцию между VE.
А абсолютная величина CPUunits может быть полезна в следующем случае: если его поделить на Power of the node (которое как-то пересчитывается из bogomips, то есть как-то зависит от мощности CPU на ноде), пересчитать эту гарантию в мегагерцы и говорить о ней клиентам. Клиенты плохо понимают cpuunits, но всегда интересуются мегагерцами
поэтому owercommit по cpuunits не страшен, разве что Вам гарантию в мегагерцы придется пересчитывать несколько по более "неудобной" формуле -- и что наиболее важно гарантия изменится когда вы поднимите на этой ноде еще одну VE.
С уваженеим,
Василий Аверин
|
|
|
|
Goto Forum:
Current Time: Sun Sep 01 04:23:53 GMT 2024
Total time taken to generate the page: 0.10917 seconds
|