Пишут, что начиная с 9.3 для shared buffers вместо shared memory начал
использоваться mmap (и ручек для отключения в конфиге не видно):
http://www.postgresql.org/docs/9.3/static/release-9-3.html
Для пользователей freebsd это насколько понимаю приведет к заметному падению
производительности. Вот сообщение про коллег из Dragonfly, но они пишут что под
FreeBSD то же самое:
http://lists.dragonflybsd.org/pipermail/kernel/2012-September/000004.html
Раньше можно было написать в sysctl.conf
kern.ipc.shm_use_phys=1
и это позволяло оптимизировать работу с этой памятью за счет того, что
1. она никогда не свопится. если повезло и произошел superpage promotion, то
demotion уже не случился (а долгоживущие буфера, которые можно свопить рано или
поздно фрагментируются, и никаких superpages там не будет).
2. если N процессов, используют один shared memory segment, то на каждую
страницу памяти будет N PV entry в случае shm_use_phys=0 и одна PV entry в
случае shm_use_phys=1 (там почти все и делают для PostgreSQL).
В случае mmap насколько понимаю все будет так же плохо, как с shared memory +
shm_use_phys=0
а именно на каждую страницу буфера будет много PV entry (по числу процессов),
что увеличивает расход памяти (и вымывание кешей CPU).
достаточно, чтобы память под shared buffer хотя бы один раз и частично попала в
сфоп, и в физической памяти она будет фрагментирована, и superpages
использоваться уже не будут.
Отсюда такой вопросы:
1. Если в master-е сделать mmap + mlock будет ли такой же эффект как
shm_use_phys=0 ?
2. Нет ли желающих послать разработчикам postgresql патчи с добавлением mlock ?
