is TMPFS still highly experimental?
Olivier Smedts
olivier at gid0.org
Mon Oct 3 21:36:50 UTC 2011
Le lundi 3 octobre 2011, Xin LI <delphij at gmail.com> a écrit :
> On Sun, Oct 2, 2011 at 3:33 PM, Ivan Voras <ivoras at freebsd.org> wrote:
>> On 02/10/2011 07:27, Xin LI wrote:
>>
>>> The problem Ivan have asserted was not confirmed by anyone who have
>>> swap configured properly. Gleb have pointed out that it might be
>>> related to a series of integer overflow by the way (he have also fixed
>>> a lot of tmpfs issues by the way).
>>
>> Well, instead of guessing I can point you to the way I got the original
>> situation - you said you have ZFS configured so it would be easy for you
>> to check.
>>
>> You should to something like this:
>>
>> - configure your system to the best of your abilities (but post
what
>> you did different from the defaults)
>
> It's mostly "normal" configuration -- 6GB RAM, 14GB swap, ZFS as /usr;
>
> The following sysctl tweaks were done to make postgresql start (these
> are not scientific, just large enough to make it work):
>
> kern.ipc.shmmax=4294967296
> kern.ipc.shmall=1048576
>
>> - install postgresql (8.4+, but I don't think the version is
>> important), configure it so it gets half the system memory or 2/3 the
>> system memory for its shared_buffers.
>
> Configured to half of system memory (3072MB).
>
> # ipcs -a
> Message Queues:
> T ID KEY MODE OWNER GROUP CREATOR
> CGROUP CBYTES QNUM
> QBYTES LSPID LRPID STIME RTIME CTIME
>
> Shared Memory:
> T ID KEY MODE OWNER GROUP CREATOR
> CGROUP NATTCH SEGSZ CPID LPID ATIME
> DTIME CTIME
> m 65536 5432001 --rw------- pgsql pgsql pgsql
> pgsql 6 3295936512 2130 2130 10:57:12
> 11:09:17 10:57:12
>
> Semaphores:
> T ID KEY MODE OWNER GROUP CREATOR
> CGROUP NSEMS OTIME CTIME
> s 65536 5432001 --rw------- pgsql pgsql pgsql
> pgsql 17 11:09:25 10:57:12
> s 65537 5432002 --rw------- pgsql pgsql pgsql
> pgsql 17 10:57:12 10:57:12
>
>> - install pgbench
>
> Done.
>
>> - initialize pgbench so that the database definitely is larger
than the
>> entire memory you got (NOTE: THIS IS NOT A CONTRIVED TEST - lots of
>> databases in practice are larger than the RAM in the server).
>
> Initialized with pgbench -i -s 500 pgbench.
>
>> - run pgbench & observe the results.
>
> pgbench -t 20000 -c 64 -S pgbench
>
> Can't seem to reproduce:
>
> # df -Httmpfs
> Filesystem Size Used Avail Capacity Mounted on
> tmpfs 10G 69k 10G 0% /tmp
>
> Any suggestions?
Try reducing the swap size to less than the RAM size. No "configuration
issue", try with some RAM + swap that should fit all.
And please excuse if we're not speaking of the same tmpfs caveat :-)
>
>> This should create really bad contention problem for memory between
>> postgresql and ZFS, which should manifest itself in tmpfs shrinking to 0
>> bytes free.
>>
>> If you don't get this problem then great, it might be solved!
>>
>>
>> (for more info on pgbench, see this:
>> http://www.westnet.com/~gsmith/content/postgresql/pgbench-scaling.htm).
>>
>> _______________________________________________
>> freebsd-fs at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>>
>
>
>
> --
> Xin LI <delphij at delphij.net> https://www.delphij.net/
> FreeBSD - The Power to Serve! Live free or die
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: olivier at gid0.org - against HTML email & vCards X
www: http://www.gid0.org - against proprietary attachments / \
"Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas."
More information about the freebsd-fs
mailing list