Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Jan 2009 14:48:48 -0800
From:      "Michael K. Smith - Adhost" <mksmith@adhost.com>
To:        "Max Laier" <max@love2party.net>, <freebsd-pf@freebsd.org>
Subject:   RE: Issues with PF and 7.1
Message-ID:  <17838240D9A5544AAA5FF95F8D52031605658786@ad-exh01.adhost.lan>
In-Reply-To: <200901231904.22558.max@love2party.net>
References:  <17838240D9A5544AAA5FF95F8D520316056585C1@ad-exh01.adhost.lan> <d5992baf0901230921h27e78ffndfc2e20d1f7ff6eb@mail.gmail.com> <200901231904.22558.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--PGP_Universal_049A5D3D_A7A9586A_C05CE6F8_3588547D
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hello All:

<snip>

> > What does sysctl vm.kmem_size_max show?   Try increasing that size a
> > bit in loader.conf and see if that helps.
>=20
> Seconded.  My guess is that the system flushes buffers when you first loa=
d the
> tables due to memory pressure, so when you load the tables a second time =
there
> is more space available.  This, however, suggest that you are pretty thin
> stretched regarding kvm and should really increase it.  I'd shoot for at =
least
> 512M which I believe is the maximum in 7.1 with the stock kernel.  It see=
ms
> that there is work in progress to increase that limit for amd64 in releng=
_7,
> however.  Increasing this is worthwhile in any case, as I have a hard time
> imagining what else you'd be doing with those 4G on the firewalls (unless=
 you
> are running heavy webcaches on them, too).
>=20

Thanks for the info.  In stages, we upped the vm.kmem_size_max from 300M to=
 1536M after modifying the kernel (we actually tried 2048M but that caused =
a panic).  With the 1536M setting the 'DIOCADDRULE: Cannot allocate memory'=
 doesn't occur anymore, but we still have to flush the tables manually when=
 the system comes up.  Now, at least, the flush actually works and PF loads=
 successfully, but only after we do the flush on all the tables.  As you ca=
n imagine, this is not optimal for unattended/random reboots, which we see =
about 3 times a week.

Regards,

Mike

--PGP_Universal_049A5D3D_A7A9586A_C05CE6F8_3588547D
Content-Type: application/pgp-signature;
	name="PGP.sig"
Content-Transfer-Encoding: 7BIT
Content-Disposition: attachment;
	filename="PGP.sig"

-----BEGIN PGP SIGNATURE-----
Version: 9.9.1 (Build 287)

iQEVAwUBSXpJUPTXQhZ+XcVAAQgjdQf/QmzlgzNbjvDbd5SC+JytZQCmznhH6QPg
HFXUCf8VUR1EFNmJSohrHoCwq9S0K6A6bpaCZ5RMxt523Om6UfRBD3VEi/ADKcNZ
4Uieew895GZ/0oQjPodnae5cE5MvD9u7LHwmQSZIFdS6bLm/sMxAKx7rG6x4A7sg
Ffjv+r9H1Uu5Sn8xwBaKJRqxEUAWqMxC01pvdVVPea5uFgSIQ6aU/55I3kGKRViK
sTjpPWfkqkcJpEk0fNvrhL58fNZoWN3Fj5eogIPJfQj242W5JrJ7E+TsOTEgCNCm
HIvuBIug+sK6JjJk7zq08VyvVWbJU1NClONnx8pGKjimzGHrTS6VEw==
=GX/3
-----END PGP SIGNATURE-----

--PGP_Universal_049A5D3D_A7A9586A_C05CE6F8_3588547D--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17838240D9A5544AAA5FF95F8D52031605658786>