Thread: Confusion on shared buffer
In some docs i read that shared buffer must be increased based on the maximum dataset size. For my scenario the dataset size is relative small less then a Gb, but database# handled by a server is nearly 200db per server and average connection# to server will be >500 (approx 5/per each DB). So for this scenario will increase in shared buffer will increase the performance.
FYI: RAM in 8GB
Regards,
Arvind S
"Many of lifes failure are people who did not realize how close they were to success when they gave up."
-Thomas Edison
FYI: RAM in 8GB
Regards,
Arvind S
"Many of lifes failure are people who did not realize how close they were to success when they gave up."
-Thomas Edison
On Thu, Oct 1, 2009 at 4:11 AM, S Arvind <arvindwill@gmail.com> wrote: > In some docs i read that shared buffer must be increased based on the > maximum dataset size. For my scenario the dataset size is relative small > less then a Gb, but database# handled by a server is nearly 200db per > server and average connection# to server will be >500 (approx 5/per each > DB). So for this scenario will increase in shared buffer will increase the > performance. > FYI: RAM in 8GB I'm pretty sure that won't help to make shared buffers larger than the size of your entire cluster. ...Robert
Thanks Robert,
So for our scenario what is the most important factor to be noted for performance.
-Arvind S
So for our scenario what is the most important factor to be noted for performance.
-Arvind S
On Sat, Oct 3, 2009 at 12:49 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Oct 1, 2009 at 4:11 AM, S Arvind <arvindwill@gmail.com> wrote:I'm pretty sure that won't help to make shared buffers larger than the
> In some docs i read that shared buffer must be increased based on the
> maximum dataset size. For my scenario the dataset size is relative small
> less then a Gb, but database# handled by a server is nearly 200db per
> server and average connection# to server will be >500 (approx 5/per each
> DB). So for this scenario will increase in shared buffer will increase the
> performance.
> FYI: RAM in 8GB
size of your entire cluster.
...Robert
On Sat, Oct 3, 2009 at 2:11 AM, S Arvind <arvindwill@gmail.com> wrote: > Thanks Robert, > So for our scenario what is the most important factor to be noted > for performance. Tough to say without benchmarking, but if you have a lot of small databases that easily fit in RAM, and a lot of concurrent connections, I would think you'd want to spend your hardware $ on maximizing the number of cores. But there are many in this forum who have much more experience with these things than me, so take that with a grain of salt... (You might also want to look at consolidating some of those databases - maybe use one database with multiple schemas - that would probably help performance significantly.) ...Robert
On Sun, Oct 4, 2009 at 6:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sat, Oct 3, 2009 at 2:11 AM, S Arvind <arvindwill@gmail.com> wrote:Tough to say without benchmarking, but if you have a lot of small
> Thanks Robert,
> So for our scenario what is the most important factor to be noted
> for performance.
databases that easily fit in RAM, and a lot of concurrent connections,
I would think you'd want to spend your hardware $ on maximizing the
number of cores.
But there are many in this forum who have much more experience with
these things than me, so take that with a grain of salt...
(You might also want to look at consolidating some of those databases
- maybe use one database with multiple schemas - that would probably
help performance significantly.)
I am not sure I understand the reasoning behind it! As long as they are different objects, how would it help performance if tables are stored in separate schema, or in separate databases; or are you referring to the difference in size of system tables and the performance improvement resulting from keeping all metadata in a single catalog.
Best regards,
--
Lets call it Postgres
gurjeet[.singh]@EnterpriseDB.com
EnterpriseDB http://www.enterprisedb.com
singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
On Sun, Oct 4, 2009 at 9:28 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote: > On Sun, Oct 4, 2009 at 6:32 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> >> On Sat, Oct 3, 2009 at 2:11 AM, S Arvind <arvindwill@gmail.com> wrote: >> > Thanks Robert, >> > So for our scenario what is the most important factor to be >> > noted >> > for performance. >> >> Tough to say without benchmarking, but if you have a lot of small >> databases that easily fit in RAM, and a lot of concurrent connections, >> I would think you'd want to spend your hardware $ on maximizing the >> number of cores. >> >> But there are many in this forum who have much more experience with >> these things than me, so take that with a grain of salt... >> >> (You might also want to look at consolidating some of those databases >> - maybe use one database with multiple schemas - that would probably >> help performance significantly.) >> > > I am not sure I understand the reasoning behind it! As long as they are > different objects, how would it help performance if tables are stored in > separate schema, or in separate databases; or are you referring to the > difference in size of system tables and the performance improvement > resulting from keeping all metadata in a single catalog. Yep, if it's all one database you don't have all the different system catalog page competing for space in shared buffers, which is bad especially for a case like this where the individual databases are quite small. I haven't actually measured this myself (so you shouldn't believe me), but there have been other comments about this on this list from time to time. Large numbers of databases seem to hurt the stats collector, too. ...Robert