Re: brk() function and performance

Поиск
Список
Период
Сортировка
От Gregory Seidman
Тема Re: brk() function and performance
Дата
Msg-id 20020716165039.GE10022@cs.brown.edu
обсуждение исходный текст
Ответ на Re: brk() function and performance  (Andrew Sullivan <andrew@libertyrms.info>)
Список pgsql-general
Andrew Sullivan sez:
} 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.
}
} My Sun-loving colleague, Sorin Iszlai, wondered why this problem was
} cropping up, and remembered the qsort() debacle.  So he did some
} tests.  Guess what?  Here's what he found:
}
} > I ran some tests with the realloc() function from the standard lib;
} > If the application calls realloc() 4096 times the results are:
}
} > - if linked with bsdmalloc, realloc() calls brk() 17 times only:
} > syscall      seconds   calls
} > brk              .40      17
}
} > - and without bsdmalloc :
} > syscall      seconds   calls
} > brk             1.36   24527
}
} At this rate, I'm beginning to get the feeling that maybe getting
} FreeBSD to work well on 64 bit Sun machines is the most important
} project we could undertake ;-)
}
} Anyway, I'm going to do some tests with this, but in the meantime, if
} anyone has any views on the subject, insights, or experience, it'd be
} much appreciated.

Way back when I was a college freshman or sophomore, I was talking to a
professor who mentioned having had tremendous problems with the brk()
system call robbing him of system performance. His solution, since brk() is
called when malloc decides it needs another page or so, was to allocate a
*tremendous* amount of memory at the very beginning of his run, then free
it all. This meant that Solaris mapped a whole bunch of pages to his app
with just one brk() call, and once it was released it was in malloc's free
list. The pages weren't swapped/paged or anything because until they were
written to or read from, they didn't even really exist except in the OS's
internal tables. It just took the OS out of the loop in memory allocation.

This may ar may not be a good solution. I would expect it to fail or have
bad performance characteristics on at least some flavors of Unix, and
probably Windows. Still, it might be worth looking into on Solaris.

} Thanks.
} A
--Greg


В списке pgsql-general по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: Disabling case sensitivity
Следующее
От: Tom Lane
Дата:
Сообщение: Re: integer out of range errors