> In a 24 CPU, SPARC Solaris 8 E6500 system (with 7Gbytes of memory), are
> there any disadvantages to adding large amounts of disk space as swap space
> in order to increase the maximum size of /tmp? I would like to increase the
> size of /tmp to around 40G but am concerned that managing that amount of swap
> space may have a detrimental effect on the system paging performance.
> Anyone have any experience with very large swap-based /tmp filesystems?
The general opinion was DON'T.
Some suggested creating a seperate work area rather than increase the size
of /tmp -- well, that's what we have now. This works, of course, but has
problems with 3rd party binary only applications that do not follow the
TMPDIR convention (grrrr) It also has the advantage that we can set quotas
on the filesystem and so share it fairly.
A few suggested making /tmp a standalone filesystem. In the past we tried
this under Solaris 2.5 but the performance hit was huge, around 100%, for
our service. Keeping all those filesystem operations in memory is a huge
So, it looks like we'll stick with what we have for now. Perhaps a bit of
quiet modification of misbehaved programs with a hex editor is called for
-- /\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
Elwood: It's a 106 miles to Chicago. We've got a full tank of gas, and a half a pack of cigarettes. It's dark, and we're wearing subglasses. Jake: Hit it!
S U BEFORE POSTING please READ the FAQ located at N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq . and the list POLICY statement located at M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy A To submit questions/summaries to this list send your email message to: N firstname.lastname@example.org A To unsubscribe from this list please send an email message to: G email@example.com E and in the BODY type: R unsubscribe sun-managers S Or . unsubscribe sun-managers firstname.lastname@example.org L To view an archive of this list please visit: I http://www.latech.edu/sunman.html S T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:20 CDT