Re: Bug#735927: general: X *always* crashes when ram is full
On Mon, Jan 20, 2014 at 10:46:50AM -0500, The Wanderer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 01/20/2014 09:56 AM, Kevin Chadwick wrote:
> > On Mon, 20 Jan 2014 14:30:24 +0000 Roger Leigh wrote:
> >> This is a system with 8 cores @4GHz, 16GiB RAM, over 16GiB swap, so
> >> should be pretty performant, yet /tmp on an SSD made it crawl and
> >> freeze continually.
> > Interesting, have a look if it states the write access time spec in
> > the datasheet (if available) of that SSD? Though when I've looked for
> > write access time on off the shelf SSD drives it usually only
> > mentions throughput or reading.
> He said this was the Intel 320 Series 128GB drive. As far as I know
> there is no officially 128GB model of that drive, but the 120GB model
> (that being the advertised capacity after overprovisioning et cetera)
> was reviewed in depth by The Tech Report back in 2011:
> The article includes spec-sheet information and detailed benchmark
> results. Glancing over them again, I'm not surprised by this described
> result from that drive; there are other SSDs that might do much better.
You are correct--it is indeed 120GB, my mistake.
I'm not sure if it's just the write speed. It's also reading stuff back
from /tmp and the rest of the rootfs so it may just be a pathological
workload. That said, I would have classed it as "very light"--/var,
/home and the build chroots etc. are all on a separate RAID/LVM array,
so /tmp was the sole part of the rootfs being actively written.
It would be interesting to have further data from users who could try
running with /tmp on the rootfs SSD and on a tmpfs (with or without
the swap on the SSD).
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800