PostgreSQL on RAM Disk / tmpfs

Поиск
Список
Период
Сортировка
От Thomas F. O'Connell
Тема PostgreSQL on RAM Disk / tmpfs
Дата
Msg-id 7C4D5879-CC8E-461F-A89B-08E80E8360E7@sitening.com
обсуждение исходный текст
Ответы Re: PostgreSQL on RAM Disk / tmpfs  ("Merlin Moncure" <mmoncure@gmail.com>)
Список 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

3004B Poston Avenue
Nashville, TN 37203-1314
615-469-5150 x802
615-469-5151 (fax)

В списке pgsql-general по дате отправления:

Предыдущее
От: James Robinson
Дата:
Сообщение: Re: Performance/Issues with CMP and JBoss
Следующее
От: "bruce"
Дата:
Сообщение: logic/db question