Date: Wed, 29 Jul 2015 16:37:00 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-fs@freebsd.org Subject: Re: pw operations slow under zfs load Message-ID: <55B9477C.2050302@denninger.net> In-Reply-To: <CAP1HOmTXTau5nALRCmpgQRoS%2B=sRMhKPd8L-t_us1_xG26XeTg@mail.gmail.com> References: <CAP1HOmTuxi7HL0_-SLJ8pd9s=3ob2D_ZU0pu%2BMSZfuxMPDydWw@mail.gmail.com> <CAP1HOmTXTau5nALRCmpgQRoS%2B=sRMhKPd8L-t_us1_xG26XeTg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On 7/29/2015 16:13, javocado wrote:
> Sorry, the boot disk (SSD) is plain old ufs.
>
> On Wed, Jul 29, 2015 at 2:11 PM, javocado <javocado@gmail.com> wrote:
>
>> Hi,
>>
>> We have a pretty busy ZFS pool running on an 8.3 AMD system. We are
>> noticing that when the pool is busy pw-related operations seem to take a
>> long time to complete:
>>
>> # time pw unlock 1000
>> 0.007u 0.036s 0:39.72 0.0% 45+1953k 0+113io 0pf+0w
>>
>> # time pw lock 1000
>> 0.032u 0.022s 1:09.63 0.0% 24+1132k 0+114io 0pf+0w
>>
>> Wile the command is running, we note that the process is locked in the D
>> state:
>>
>> root 85051 0.0 0.0 5832 960 0 D+ 1:53PM 0:00.02
>> /usr/sbin/pwd_mkdb -u 1000 /etc/master.passwd
>>
>> We also note that there is next to 0 disk activity on the boot volume:
>>
>> # gstat -f ad
>>
>> dT: 1.005s w: 1.000s filter: ad
>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
>> 0 0 0 0 0.0 0 0 0.0 0.0| ad6
>> 0 0 0 0 0.0 0 0 0.0 0.0| ad8
>> 0 0 0 0 0.0 0 0 0.0 0.0| ad10
>> 0 0 0 0 0.0 0 0 0.0 0.0| ad12
>>
>> And plenty of free mem:
>>
>> Mem: 400M Active, 3391M Inact, 128G Wired, 1935M Cache, 14G Buf, 6055M Free
>>
>> So, what's going on here? How does a busy pool with it's own set of drives
>> (which operate off an HBA) affect the speed of operations involving the
>> boot volume (an SSD connected to the mobo)?
>>
>>
>>
A very common manifestation of the way ZFS and the VM system interact,
unfortunately.
It's better in 9.x and 10.x, and the patch I have against them makes it
even better, but it still isn't completely resolved.
--
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
01 0 + 0 *H
_0[0C)0
*H
01 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA0
150421022159Z
200419022159Z0Z1 0 UUS10UFlorida10U
Cuda Systems LLC1 0 UKarl Denninger (OCSP)0"0
*H
0
X@vkY
Tq/vE]5#֯MX \8LJ/V?5Da+
sJc*/r{ȼnS+ w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-< ? HN5y
5}F|e f"V لio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬ Ϝ/,$+;4y 'Bz<qT9_?rRUpn5
Jn&Rx/p Jyel*pN8/#9u/YP EC)TY>~/˘N[vyiDKˉ ,^" ?$T8 v& K%z8C @?K{9f`+@,| Mbia 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB
OpenSSL Generated Certificate0 U -h\Ff Y0 U #0$q}ݽʒm50 U 0karl@denninger.net0
*H
Owbabɺx&Uk[ (Oj!%p MQ0I!#QH}.>~2&D}<wm_>V6 v ]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր _up|_ǰc/%ۥ
nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q -(cAeGX)f}-˥6cv~Kg8m~v ;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p# }D Z9;V9#>Sw"[UP710001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0 + !0 *H
1 *H
0 *H
1
150729213700Z0# *H
1-c-$l%\0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +71001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0 *H
101 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
*H
B " yJ !n([\ JƚaUZ۲bL>revzez. i;QL3HdǾf1 Ou6yvdwq;J:|j?ݾr (V+v|>7M \x,q+(Ƥeiy
7t}a`Vp%SOԉ=Jܐ#51#䧑b#&v P,- v|U@}cFb5 lɨ}߽^Y<pm~ԗ *R\+d,pPͿ.`.E =pg4]MʇC 0xppCD#&=O8'ӲdӫW Q \^T
]ܙcʼn33x1Q. pl;ը/TN$>z 5.P |y ~CY.Qw>F A}`տ@~Uϴ*
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55B9477C.2050302>