Немного оффтопик, но как-то года 3 тому назад поднимали вопрос о производительности oracle и постгреса на фре - в итоге все ушло к тому, что на сильно нагруженных базах лучше использовать линукс или солярку
19 декабря 2013 г., 12:09 пользователь Anton Yuzhaninov <[email protected]> написал: > Пишут, что начиная с 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 ?
