Re: DB cache size strategies
От | Ed L. |
---|---|
Тема | Re: DB cache size strategies |
Дата | |
Msg-id | 200401301519.56488.pgsql@bluepolka.net обсуждение исходный текст |
Ответ на | DB cache size strategies ("Ed L." <pgsql@bluepolka.net>) |
Ответы |
Re: DB cache size strategies
|
Список | pgsql-general |
On Friday January 30 2004 2:33, Ed L. wrote: > > One key aspect of pgsql performance tuning is to adjust the memory > consumption settings (shared_buffers, sort_mem, etc) large enough to hold > as much of the database in shared memory as possible while not causing > page swap-ins. I understand that both page swap-outs and swap space > usage is normal and OK, but lots of page swap-ins are bad). In other > words, for absolute fastest performance, we want a database buffer cache > hit rate of as close to 100% as possible. I'm also curious about the relationship of DB shared buffer cache to the linux/hpux kernel caches. In particular, if the block being retrieved in pgsql was in the kernel's cache but not in the DB cache, thereby forcing a read() system call, what kind of quantitative difference in performance would one expect when comparing with block retrievals coming from the cache? I would think they'd differ only by something on the order of microseconds. Is the linux kernel disk cache normally a duplicate of much of what is in the DB cache? For linux, does the kernel cache use only "available" memory until a program needs it, while the pgsql DB cache memory is guaranteed at startup? TIA. Ed
В списке pgsql-general по дате отправления: