We use solaris 10 at my company, but I noticed this behavior is the
same/worse on sxde, and I wanted to know if someone could test this on
a recent nevada build.
The problem:
We have long used tmpfs for /tmp on systems where we want to provide
our uses with a scratch space for them to put small files. This does
get abused occasionally, but for that use it has been fine.
The other day, we saw some puzzling behavior. Specifically, when a
system with a lot of memory (16gb) had a 10gb file in /tmp, and a few
large processes running (say 2 gb in 2 processes for the sake of
argument) reading that file from /tmp became unbearably slow.
While investigating this, we came up with a test scenario that
consistantly reproduced this behavior. The behavior is that if you
have a system with 4gb of memory, and create a 1gb file in /tmp, and a
1gb file in /var/tmp, and then you start 2 processes each with an rss
of about 1gb, your reads from /tmp get very... very..... slow. The
file in /tmp was maxing out at about 6mb/sec read, with a typical read
speed of about 2.5mb/sec as measured by iostat. The file from /var/tmp
reads about 50mb/sec.
All the large processes do is keep scanning their active memory in
this loop:
for(;;) {
for (int i=0; i < nints; i++) {
buf[i]++;
}
}
We've found that using a similar scenario with 3 of these processes,
one will swap out, an when killing the most active one, the swap in
happens again at aound 2.5mb/sec.
This makes /tmp pretty bad in most scenarios, but what's stunning is
how swap behaves so slowly when paging a program back in.
Does anyone know what is going on here, does this happen in nevada,
and what we can do about this? We are persuing this with sun support
but I thought this was a topic of broader interest.
Thanks,
-Peter
--
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
