From: | "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com> |
---|---|
To: | PgSQL-General <pgsql-general(at)postgresql(dot)org> |
Subject: | PostgreSQL on RAM Disk / tmpfs |
Date: | 2006-08-02 18:35:50 |
Message-ID: | 7C4D5879-CC8E-461F-A89B-08E80E8360E7@sitening.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I'm working on a postgres instance (8.1.2 running on Solaris 10)
where the data directory (including WAL) is being mounted on tmpfs.
Based on this, and with knowledge that fsync is disabled, I'm
operating under the assumption that recoverability is not a
precondition for optimized performance. With that assumption, I have
several questions, some performance-related, others internals-related:
1. Should there be any perceptible difference between using a RAM
disk and tmpfs? Would the fact that the RAM disk were fixed-size make
it at all faster?
2. Would there be any benefit to having WAL on a separate RAM disk?
I.e., would RAM access be contentious in anything resembling the way
disk access is contentious? One possible setup would be a fixed-size
RAM disk for data and WAL on tmpfs, for instance.
3. In this scenario, is the strategy of keeping checkpoints far apart
still a valid performance consideration? I would expect that there
would be an optimal spot on the curve somewhere on the axes of
checkpoint distance and available memory. During testing on the RAM
disk, one problem encountered was that increasing checkpoint_segments
caused the RAM disk to fill up, which suggests one potential benefit
of pushing WAL off to tmpfs but possibly leaving data on the RAM
disk. There would be no reason to push for aggressive checkpointing,
would there?
4. Considering that recoverability is not a precondition, is there an
easy patch that could be applied to the 8.1.x series from 8.1.4 on
that would allow disabling full_page_writes? For a database in RAM
with high write volume, is this setting even likely to make a
difference?
5. Does wal_debug provide insight into whether LogInsert is being
forced to write WAL buffers? This would seem to be a useful indicator
as to whether wal_buffers was set high enough. (A side note: I
couldn't find reference to LogInsert or LogFlush in the source; would
it make sense to have the documentation refer to the actual
functions?) Unfortunately, I don't have access to a system that can
be easily recompiled for me to test this. A corollary question: if
data and pg_xlog are both in RAM, does LogInsert still spill to the
kernel cache, or would it spill to RAM?
--
Thomas F. O'Connell
Sitening, LLC
http://www.sitening.com/
3004B Poston Avenue
Nashville, TN 37203-1314
615-469-5150 x802
615-469-5151 (fax)
From | Date | Subject | |
---|---|---|---|
Next Message | bruce | 2006-08-02 18:54:40 | logic/db question |
Previous Message | Roman Neuhauser | 2006-08-02 18:23:29 | Re: LISTEN considered dangerous |