Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 18 Jan 24 18:16:22, всего сообщений: 10753
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 9132 из 10753 ===================================== RU.UNIX.BSD =
От   : Eugene Grosbein                  2:5006/1           09 Aug 19 16:32:06
Кому : Dmitry Kolvakh                                      09 Aug 19 16:32:06
Тема : Re: STATE *vm ob
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+1faa038e
На   : area://RU.UNIX.BSD?msgid=2:5054/89.1+5d4c24de
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=<1187512041@ddt.demos.su>+bdf5de14
Ответ: area://RU.UNIX.BSD?msgid=2:5054/89.1+5d5415fa
==============================================================================
08 авг. 2019, четверг, в 18:26 NOVT, Dmitry Kolvakh написал(а):

DK>>> top показывает кучу процессов в состоянии *vm ob
DK>>> Что это значит?
DK>>> Freebsd 11.2 p13
DK>>> виртуальная машина под proxmox
EG>> Процессы залочены в ядре на блокировках подсистемы виртуальной
EG>> памяти (sys/vm/vm_object.c), ждут отпуская блокировки.
DK> Вот и у меня было ощущение, что процессы какой-то фигней страдают. Они мне в
DK> логи понаписали, что закончились, стёрли свои pid-файлы, а в системе висят еще
DK> минут по десять и непонятно на что кушают CPU.
EG>> Покажи скриншот top - нужно поглядеть, что за процессы,
EG>> как распределена память и сколько её, что со свопом,
EG>> если он есть.
DK> Это довольно развесистый скрипт на перле, который форкается на несколько
DK> десятков экземпляров. В VmWare было удовлетворительно, а при миграции на proxmox
DK> пошел вот такой вот эффект. Общее время работы возросло с 6-8 минут до 30.
DK> Мы решили, что распределение процессорного времени тут по другим принципам, чем
DK> в вмваре, и подкрутили параметр cpuunits у виртуальной машины, вроде бы помогло.
DK> А было так:
DK> $ top
DK> last pid:  1778;  load averages:  7.16,  9.70,  7.81                up
DK> 0+00:37:38  16:02:59
DK> 62 processes:  7 running, 34 sleeping, 21 lock
DK> CPU:  4.1% user,  0.0% nice, 95.5% system,  0.0% interrupt,  0.4% idle
DK> Mem: 4764M Active, 1155M Inact, 1042M Wired, 321M Buf, 55G Free
DK> Swap: 18G Total, 18G Free
DK>   PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
DK>  1284 keu           1  75    0  1056M  1040M CPU0    0   0:41  20.11% perl
DK>  1285 keu           1  79    0  1056M  1041M RUN     1   0:42  19.17% perl
DK>  1288 keu           1  78    0  1056M  1041M *vm ob  0   0:33  19.11% perl
DK>  1287 keu           1  78    0  1056M  1041M *vm ob  0   0:31  19.02% perl
DK>  1289 keu           1  77    0  1056M  1039M *vm ob  0   0:28  18.87% perl
DK>  1286 keu           1  78    0  1056M  1039M *vm ob  0   0:33  18.11% perl
DK>  1756 keu           1  78    0  1056M  1038M *vm ob  0   0:02  14.20% perl
DK>  1759 keu           1  75    0  1056M  1038M *vm ob  0   0:01  13.17% perl
DK>  1758 keu           1  76    0  1056M  1038M *vm ob  0   0:01  11.70% perl
DK>  1760 keu           1  76    0  1056M  1038M RUN     1   0:01   8.83% perl
DK>  1762 keu           1  75    0  1056M  1038M *vm ob  1   0:01   8.54% perl

Может оказаться, что в этом гипервизоре очень дороги
(читай: неэффективно реализованы) примитивы синхронизации CPU,
на основе которых работают мутексы в ядре FreeBSD.

Можно поиграться с опциями ядра PREEMPTION/IPI_PREEMPTION.
Можно дать виртуалке только один виртуальный CPU
и поменять шедулер с SCHED_ULE на SCHED_4BSD, который даёт
лучшую производительность для одноядерных систем.

Eugene
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.083679 секунды