Re: was there a change in FreeBSD SHM implementation from
От | Vivek Khera |
---|---|
Тема | Re: was there a change in FreeBSD SHM implementation from |
Дата | |
Msg-id | 15661.40858.819829.49331@onceler.kciLink.com обсуждение исходный текст |
Ответ на | Re: was there a change in FreeBSD SHM implementation from (Curt Sampson <cjs@cynic.net>) |
Ответы |
Re: was there a change in FreeBSD SHM implementation from
|
Список | pgsql-general |
>>>>> "CS" == Curt Sampson <cjs@cynic.net> writes: >> For those familiar with postgres, I was using shared_buffers=100000 >> with 4.4, but had to back that down to 32000 for 4.6. This is >> obviously impacting performance... CS> Yes, I'm sure your performance improved. By going from 780 MB to CS> 25 MB of shared memory, you just increased the amount of data the CS> OS can buffer from about 1.1 GB to 1.8 GB. You've just increased CS> your cache size by about 60%. Actually performance went down. Way down. I disagree with your argument that increasing the cache will help, since the cache is not needed if you don't pushd out your SHM pages in the first place and need to reload them quickly. What it turned out to be was that SHMMAX was larger than my SHMALL. Why the kernel let me build it that way without warnings is a hole in the config system, but not fatal. Bumping up SHMALL fixed my issue, and now my performance is back to normal. Perhaps Postgres could identify the smaller of SHMMAX and SHMALL when reporting the failure to get the memory, and indicate which one is too small. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
В списке pgsql-general по дате отправления: