Date: Wed, 23 Feb 2011 00:21:16 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Henner Heck <Henner.Heck@web.de> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.2 Release, ZFS + Samba, running out of memory Message-ID: <20110222222116.GI78089@deviant.kiev.zoral.com.ua> In-Reply-To: <4D6430D9.8060609@web.de> References: <4D6430D9.8060609@web.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--4ijVojJviyn2gS8i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 22, 2011 at 10:55:37PM +0100, Henner Heck wrote: >=20 > Hello, >=20 > i experience freezing of my FreeBSD machine when performing certain > operations > on a Samba share. >=20 > Technical info: > - FreeBSD 8.2 Release 64 Bit (it also happened with 8.2 RC3) > - Samba 3.5.6.1 > - Athlon II Quadcore, 4 GB Ram > - 1 SSD with a ZFS pool (No.0) containing the FreeBSD system > - 12x2TB RaidZ2 pool (No.1) for data, created on 12 GEOM eli encrypted > partitions on 12 disks, > shared to a Windows 7 PC with Samba, > 8 of the disks are attached to 2 Marvell SATA controllers, 4 to the > onboard controller > - ZPool v15, ZFS v4 >=20 > Scenarios (checked using top): >=20 > A: > When copying files from one directory in pool 1 to another, the free > memory drops from > about 3700M to abaout 200M in the process, but seems to stabilize then. >=20 > B: > When copying the files onto a Windows machine using the Samba share, > the free memory seems to stabilize at about 100M. >=20 > C: > When computing a hashvalue of files from the share on Windows or doing a > binary compare to copies of the files stored on the Windows PC (using > Total Commander), > the free memory on the FreeBSD machine drops even lower and shortly > after the BSD system freezes. > Here is the last top output i got via ssh: >=20 > /last pid: 1328; load averages: 4.53, 2.23, 0.99 up 0+00:04:39=20 > 22:07:50 > 263 processes: 43 running, 201 sleeping, 19 waiting > CPU: 0.9% user, 0.0% nice, 23.1% system, 4.2% interrupt, 71.9% idle > Mem: 720K Active, 516M Wired, 144K Cache, 320K Buf, *39M Free* > Swap: 4096M Total, 12M Used, 4084M Free, 3008K In, 5124K Out >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 4 171 ki31 0K 64K RUN 0 15:54 303.61% idle > 1321 root 1 52 0 27812K 704K swread 1 0:24 14.26% smbd > 12 root 19 -60 - 0K 304K WAIT 0 0:21 12.45% intr > 16 root 1 48 - 0K 16K psleep 2 0:01 3.76% > pagedaemon > 3 root 1 -8 - 0K 16K RUN 0 0:06 3.27% g_up > 4 root 1 -8 - 0K 16K - 3 0:05 2.69% g_down > 0 root 108 -8 0 0K 1712K - 0 1:02 1.86% kernel > 8 root 6 -8 - 0K 88K tx->tx 1 0:00 1.27% zfskern > 1268 root 1 44 - 0K 16K geli:w 1 0:03 0.98% > g_eli[1] gpt > 1225 root 1 45 - 0K 16K RUN 3 0:02 0.98% > g_eli[3] gpt > 1267 root 1 44 - 0K 16K geli:w 0 0:02 0.98% > g_eli[0] gpt > 1237 root 1 44 - 0K 16K RUN 0 0:02 0.88% > g_eli[0] gpt > 1214 root 1 44 - 0K 16K RUN 2 0:02 0.88% > g_eli[2] gpt > 1244 root 1 44 - 0K 16K RUN 2 0:02 0.78% > g_eli[2] gpt > 1243 root 1 44 - 0K 16K RUN 1 0:02 0.78% > g_eli[1] gpt > 1212 root 1 44 - 0K 16K RUN 0 0:02 0.78% > g_eli[0] gpt > 1215 root 1 44 - 0K 16K RUN 3 0:02 0.78% > g_eli[3] gpt > 1213 root 1 44 - 0K 16K RUN 1 0:02 0.78% > g_eli[1] gpt > 1240 root 1 44 - 0K 16K RUN 3 0:02 0.78% > g_eli[3] gpt > 1217 root 1 44 - 0K 16K RUN 0 0:02 0.78% > g_eli[0] gpt > 1242 root 1 44 - 0K 16K RUN 0 0:02 0.68% > g_eli[0] gpt > 1238 root 1 44 - 0K 16K RUN 1 0:02 0.68% > g_eli[1] gpt > 1248 root 1 44 - 0K 16K RUN 1 0:02 0.68% > g_eli[1] gpt > 1252 root 1 44 - 0K 16K RUN 0 0:02 0.68% > g_eli[0] gpt > 1249 root 1 44 - 0K 16K RUN 2 0:02 0.68% > g_eli[2] gpt > 1269 root 1 44 - 0K 16K geli:w 2 0:02 0.68% > g_eli[2] gpt/ >=20 > It looks like a caching problem to me, but i don't know how to fix it. > I am also a bit confused, since i don't see an obvious difference > between scenario B and C. > I had a similar setup with 5 disks RaidZ1 and Samba running on 8.1 Releas= e, > and never experienced such a freeze. >=20 > Does anyone have advice on how to get rid of this problem? Try the patch from rev. 218795. If it indeed help, we would need an errara notice. --4ijVojJviyn2gS8i Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1kNtsACgkQC3+MBN1Mb4isBgCdGa6kVZ7x4nVVjzJI28cFTLZI WykAoPeitIiYULQAwOjwM3npPQ8mTKSM =SO/q -----END PGP SIGNATURE----- --4ijVojJviyn2gS8i--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110222222116.GI78089>