Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Jan 2007 03:58:02 -0500
From:      Kris Kennaway <kris@obsecurity.org>
To:        Kris Kennaway <kris@obsecurity.org>
Cc:        Zbigniew Szalbot <zbyszek@szalbot.homedns.org>, freebsd-questions@freebsd.org
Subject:   Re: virtual memory management
Message-ID:  <20070120085802.GA5216@xor.obsecurity.org>
In-Reply-To: <20070120085137.GA5113@xor.obsecurity.org>
References:  <60131.192.168.11.7.1169279847.squirrel@lists.lc-words.com> <20070120080417.GA4365@xor.obsecurity.org> <60303.192.168.11.7.1169280828.squirrel@lists.lc-words.com> <20070120085137.GA5113@xor.obsecurity.org>

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

--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 20, 2007 at 03:51:38AM -0500, Kris Kennaway wrote:
> On Sat, Jan 20, 2007 at 09:13:48AM +0100, Zbigniew Szalbot wrote:
> > Hello again,
> >=20
> > >> The swap size usage grow so big probably because I started wget to
> > >> download an iso image and then WinSCP to grab it from the FBSD machi=
ne
> > >>  to my laptop. When I started wget, the swap usage was around 19% and
> > >> had been like that for many days.
> > >
> > > That should not cause such a thing (wget does not try to fit the whole
> > > file in memory, so it won't be pushing stuff out to swap).  Look at t=
he
> > > process sizes in top to see what is using the swap space - something(=
s)
> > > that is still running is using that 482MB.
> >=20
> > I do not see such a process:
> >=20
> >   PID USERNAME   THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
> > 21442 root         2  20    0   224M 26128K kserel   0:06  0.00% java
> >   896 mysql       16  20    0 70756K 14764K kserel 255:35  0.00% mysqld
> > 98693 bind         1  96    0 32812K 32172K select   0:22  0.00% dnscac=
he
> >  5035 www          1   4    0 28372K 15660K accept   5:05  1.86% httpd
> >  5026 www          1   4    0 28240K 15104K accept   4:46  0.00% httpd
> >  5065 www          1   4    0 28128K 15196K accept   4:29  0.00% httpd
> >  5030 www          1   4    0 27892K 15144K accept   4:21  0.00% httpd
> >  5126 www          1   4    0 27784K 14864K accept   4:20  0.00% httpd
> >  5029 www          1   4    0 27760K 14644K accept   4:22  0.00% httpd
> >  5027 www          1   4    0 27740K 15140K accept   4:30  0.00% httpd
> >  5028 www          1   4    0 27516K 14812K accept   4:03  0.00% httpd
> > 95977 www          1   4    0 27216K 14532K accept   2:21  0.00% httpd
> >   703 root         1  96    0 16412K  2296K select   4:35  0.00% httpd
> > 91014 mailman      1   8    0 11492K  1600K nanslp   6:00  0.00% python
> > 91012 mailman      1   8    0 11024K  1560K nanslp   5:32  0.00% python
> > 91010 mailman      1   8    0 11008K  1568K nanslp   5:23  0.00% python
> > 91009 mailman      1   8    0 11008K  1552K nanslp   5:20  0.00% python
>=20
> I see lots of them; every one in that list is contributinig.  If you
> add up all those process sizes you'll see where the space is going.

By which I mean the difference between size and res, which indicates
the amount of process memory allocated but not currently resident in
RAM.  This isn't a foolproof method (see e.g. the FAQ entry on
rpc.statd), but it's true in your case.

> Basically you are just overloading your system by trying to run too
> much at once.  Reduce the load or add more RAM.
>=20
> Kris



--x+6KMIRAuhnl3hBn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFFsdmZWry0BWjoQKURAkUgAKDVEY1P05wUyolHRzvOkpLQvGxsKACeO7G4
ogemQI6eR6GlSwiaSIg56jI=
=bRJy
-----END PGP SIGNATURE-----

--x+6KMIRAuhnl3hBn--



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