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>