<html><body><span class="xfm_28382529"><div><span style="font-size:10pt;line-height:12pt;font-family:Arial;" class="xfmc1">Привет,</span><br/></div>
<div><span style="font-size:10pt;line-height:12pt;font-family:Arial;" class="xfmc1"><br data-mce-bogus="1"/></span></div>
<div><span style="font-size:10pt;line-height:12pt;font-family:Arial;" class="xfmc1">Спасибо. Была микроскопическая надежда, что это глюк топа и что дебажить софт не придётся.</span></div>
<div><br/></div>
<div><i><span style="font-size:10pt;line-height:12pt;"><span style="font-family:Arial;">17 січня 2018, 12:26:44, від "Valentin Nechayev" <</span><a href="mailto:netch@netch.kiev.ua" target="_blank" rel="noreferrer noopener"><span style="font-family:Arial;">netch@netch.kiev.ua</span></a><span style="font-family:Arial;">>:</span></span></i></div>
<div><br/></div>
<blockquote style="border-left:1px solid #cccccc;margin:0px 0px 0px 0.8ex;padding-left:1ex;"><span>
<pre style="margin:5px 0;"> Wed, Jan 17, 2018 at 12:20:29, vladimir.sharun wrote about "[uanog] Про freebsd/top":
> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 31334 10 1 52 0 40960G 16K pfault 23 138:51 0.00% process.worker
>
>
> Обратите внимание на size - почти 41 терабайт. А теперь вопрос - это м.б. баг в топе или на самом деле процесс нааллоцировал столько памяти ?
Ничего не мешает столько нааллоцировать формально, если нет rlimit на
виртуальную память. Если это, например, многократный mmap одного и
того же файла, или просто /dev/null на 40TB без закоммиченных страниц
- оно может такое делать почти сколько угодно.
Вот если бы он начал их использовать - начались бы чудеса. Поэтому
разумный лимит на всю VM процесса - может быть полезен.
> Особенно пикантно выглядит его res. В системе при этом ок. 300Гб +/- было в Active.
> Что это могло быть с точки зрения системы ?
Странный, но штатный режим. Увы, такое во всех потомках Mach.
-netch-
</pre>
</span></blockquote></span></body></html>