Re: brk() function and performance
От | Andrew Sullivan |
---|---|
Тема | Re: brk() function and performance |
Дата | |
Msg-id | 20020719180255.M6252@mail.libertyrms.com обсуждение исходный текст |
Ответ на | Re: brk() function and performance (Andrew Sullivan <andrew@libertyrms.info>) |
Ответы |
Re: brk() function and performance
Re: brk() function and performance |
Список | pgsql-general |
On Tue, Jul 16, 2002 at 10:28:02AM -0400, Andrew Sullivan wrote: > On Thu, Jul 11, 2002 at 12:30:12PM -0400, Andrew Sullivan wrote: > > > > We have noticed that one of the machines is considerably slower than > > the other. We have traced the problem to the brk() funciton call. More news, in case anyone is interested. It appears, after poking around the Net, that Sun ships their poor-performing malloc as the default on purpose, because it uses less memory. You can set your CFLAGS="-llibbsdmalloc" if you want to use the BSD library (which is on the system by default), or even just set LD_PRELOAD to pick up the BSD malloc instead (the latter seems to work just fine for the postmaster, but it breaks some other things, so I think I'd compile against it instead for any real work). The BSD malloc uses about 4 times the memory of the Solaris version, but it's plenty faster. Memory is cheap. Further tests, however, seem to indicate that brk() is not our main problem. On a test machine today, we found simple selects on a table with only a couple hundred rows are taking > 300 milliseconds when we set the shared buffers to some large number (like enough to allocate a Gig of memory), more than 250 ms when running with about 512 Meg of shared memory, but under 125 ms when running with a small shared buffer setting (say, enough to allocate less than 200 meg -- one test we allocated only 4 meg). The main culprit seems to be a memset() call that happens over and over to the same address. I've no idea why, but there it is. The same results are _not_ found in testing with 7.2.1. In that case, allocating a Gig of shared memory does not seem to affect the result at all. The only question is whether they might be if we ran a lot of updates agains the 7.2.x tree. (We tarred up and copied the data tree from production, since I had it from a recent maintenance period; but we had to use pg_dump to put the data into the 7.2 database, obviously). We'll do a great whack of updates, and see if that makes a difference. A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110
В списке pgsql-general по дате отправления: