Re: Physical sites handling large data
От | Ericson Smith |
---|---|
Тема | Re: Physical sites handling large data |
Дата | |
Msg-id | 1032267596.3796.1.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Physical sites handling large data ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>) |
Ответы |
Re: Physical sites handling large data
|
Список | pgsql-general |
Out Vacuum frequency is once daily, with EXPLAINS happening every 2 hours. We use the default kernel buffer settings. - Ericson On Tue, 2002-09-17 at 02:37, Shridhar Daithankar wrote: > On 16 Sep 2002 at 17:01, Ericson Smith wrote: > > > ... that sound you hear is the sound of me knocking my head against the > > brick wall in here... > > > > Well it looks like Tom Lane was right (as always) on this one. On our > > previous server, we had 4 Gigs of RAM and 1.6 Gigs of shared memory. > > Does this mean now that the OS is efficiently caching disk, and they our > > 320MB of shared memory is good enough? > > Looks like you are asking but if you ask me you just proved that it's enough.. > > > Our database is about 4 Gigs at this point with some tables having > > hundreds of thousands or millions of records. > > Any definitive insight here as to why I'm running so well at this point? > > I would suggest looking at pg metadata regarding memory usage as well as ipcs > stats. Besides what are the kernle disk buffer setting. I believe you are using > linux and these buffer settings can be controlled via/for bdflush. > > Your typical ipcs usage would be a much valuable figure along with free.. > > And BTW, what's your vacuum frequency? Just to count that in.. > > > > > > > Bye > Shridhar > > -- > Worst Vegetable of the Year: The brussels sprout. This is also the worst > vegetable of next year. -- Steve Rubenstein > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
В списке pgsql-general по дате отправления: