Swap space for Solaris running Sybase?
Susan Cole
memory. The server is running Solaris 2.3 and Sybase 10.0.1, soon to
be Solaris 2.4 and Sybase 10.0.2.
When I originally set this system up I asked Sybase and Sun tech support
about how much swap space to allocate. I was told by Sun that the "2 times
memory" rule was out of date and that setting swap space close to memory
would be plenty. I ended up assigning 320MB of swap space (160MB on each of
the two internal disks).
The machine has been very lightly loaded so far so I can't meaningfully
assess performance. But as we tool up for heavy testing and production, a
consultant has questioned the amount of swap space. He thinks it's way low.
Since I've already asked Sun and Sybase, I thought I'd try to get the opinion
of people in the field -- how much swap space would you consider optimal for
a system like this? We have 1MB of internal storage and 30MB in a disk
array, projected to rise to 100MB or more. BTW, we are also using swap space
for /tmp (tmpfs).
Also, I realize I can adjust swap space later by using UNIX files instead
of raw disk partitions. I guess I've assumed that the fastest swap is
on the internal disks as opposed to the disks in the disk array, and on
raw partitions as opposed to file systems. Also, having swap in files
seems like it will complicate the dumps. Comments?
Thanks - Susan
Paul Chen
>We're about to do a repartition of disks on a 4-CPU SS1000 with 256MB of
>memory. The server is running Solaris 2.3 and Sybase 10.0.1, soon to
>be Solaris 2.4 and Sybase 10.0.2.
>
>When I originally set this system up I asked Sybase and Sun tech support
>about how much swap space to allocate. I was told by Sun that the "2 times
>memory" rule was out of date and that setting swap space close to memory
>would be plenty. I ended up assigning 320MB of swap space (160MB on each of
>the two internal disks).
It really depends on your anticipated workload on that machine. If that
Solaris machine is to be dedicated to Sybase SQL Server and little else,
then, yes, it is a good idea to set the swap space close to memory.
here is why ...
Solaris is based on SVR4 (UNIX System V Release 4) technology. In SVR4,
a shared memory segment (obtained through shmget()) is a pageable
virtual memory object; while in most other flavors of UNIX, a shared
memory segment is wired to the physical memory and thus is non-pageable.
Sybase SQL Server uses shared mermory to implement the buffer pool for
data as well as procedure cache. For performance reason, it is
important to prevent these buffers from being paged out. Setting
the swap space close to physical memory effectively shuts down paging.
The down side of this is that you may lose some of those benefits that
come with the "virtual memory".
>The machine has been very lightly loaded so far so I can't meaningfully
>assess performance. But as we tool up for heavy testing and production, a
>consultant has questioned the amount of swap space. He thinks it's way low.
>Since I've already asked Sun and Sybase, I thought I'd try to get the opinion
>of people in the field -- how much swap space would you consider optimal for
>a system like this?
What is optimal is a difficult question to answer without knowing the
anticipated workload on that machine. Remember that the swap space
needs to be large enough to accommodate all the workload on that
machine. On the other hand, setting the swap space close to physical
memory can prevent the Sybase buffers from being paged out on a Solaris
machine. It is a trade-off that has to be made based on the anticipated
workload.
--
Paul Chen, Ph.D.
consulting at DEC
Disclaimer: My opinions only!
Philip Bondi; 416.368.7979 x224
Your article seems to imply between the lines that SQL Server *needs*
swap space. This is false. SQL Server should ONLY use real RAM for
caching. It's internal buffer management algorithms and query
optimizer assume that SQL Server cache is real RAM. Do not allow SQL
Server to run on virtual RAM.
Database applications, by definition, perform a lot of I/O. You can
only squeeze so much performance from your system before you start
degrading it. Buying more RAM would be the only alternative that I
can think of -- as a matter of fact, I find 256 Mb RAM to be small for
a database server machine. You didn't mention in your posting the
amount of I/O throughput that you expect.
Furthermore, I believe that SQL Server will try to lock itself into
RAM. Beware of degrading the performance of other applications on
your system by allocating SQL Server too much RAM.
Good Luck. Let me know if I can be of further assistance.
.....Philip.
In article <3ig2td$j...@unix.sri.com> co...@unix.sri.com (Susan Cole) writes:
> Path: spctrm.spctrm.com!uunet.ca!uunet.ca!spool.mu.edu!howland.reston.ans.net!news.sprintlink.net!uunet!kithrup.com!news.Stanford.EDU!unix.sri.com!unix.sri.com!not-for-mail
> From: co...@unix.sri.com (Susan Cole)
> Newsgroups: comp.databases.sybase,comp.sys.sun.admin
> Date: 22 Feb 1995 11:22:21 -0800
> Organization: SRI International, Menlo Park, CA
> Lines: 26
> Distribution: world
> NNTP-Posting-Host: unix.sri.com
> Xref: spctrm.spctrm.com comp.databases.sybase:2892 comp.sys.sun.admin:21145
>
[ stuff deleted ]
> But as we tool up for heavy testing and production, a
> consultant has questioned the amount of swap space. He thinks it's way low.
--
Philip Bondi Spectra Securities Software, Inc.
Database Administrator 150 York St., #700, Toronto, Ontario, M5H 3S5, Canada
pjb...@spctra.com voice: (416)368-7979 x224 fax: (416)368-7886
--
Philip Bondi Spectra Securities Software, Inc.
Database Administrator 150 York St., #700, Toronto, Ontario, M5H 3S5, Canada
pjb...@spctra.com voice: (416)368-7979 x224 fax: (416)368-7886
Paul Chen
>
> Furthermore, I believe that SQL Server will try to lock itself into
> RAM.
As far as I know, to lock a memory area in RAM in Solaris requires
root privilege; and we know that Sybase SQL Server does NOT usually run
as root ...
As far as buffers mannaged SQL Server are concerned, they are implemented
as shared memory. In most flavors of UNIX, shared memory is indeed locked
in RAM. But I believe that in SVR4, upon which Solaris is based, the
shared memory is not automatically locked in RAM. I don't pretend to
be an expert in Solaris. So I would cross post this article to
comp.unix.solaris and ask for the expert opinions in that land.
--
Paul Chen, Ph.D.
Disclaimer: my opinions only.