On 12.04.2007, at 15:58, Jason Lustig wrote:
Wow! That's a lot to respond to. Let me go through some of the
ideas... First, I just turned on autovacuum, I forgot to do that.
I'm not seeing a major impact though. Also, I know that it's not
optimal for a dedicated server.
Hmm, why not? Have
Hi all,
Wow! That's a lot to respond to. Let me go through some of the
ideas... First, I just turned on autovacuum, I forgot to do that. I'm
not seeing a major impact though. Also, I know that it's not optimal
for a dedicated server. It's not just for postgres, it's also got our
apache se
Jeff Frost wrote:
You know, I should answer emails at night...
Indeed you shouldN'T ;-)
Carlos
--
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Thu, 12 Apr 2007, Scott Marlowe wrote:
On Thu, 2007-04-12 at 10:19, Guido Neitzer wrote:
On 12.04.2007, at 08:59, Ron wrote:
Depends. As I said - if the whole DB fits into the remaining space,
and a lot of website backend DBs do, it might just work out. But this
seems not to be the case
On Thu, 2007-04-12 at 10:19, Guido Neitzer wrote:
> On 12.04.2007, at 08:59, Ron wrote:
>
> Depends. As I said - if the whole DB fits into the remaining space,
> and a lot of website backend DBs do, it might just work out. But this
> seems not to be the case - either the site is chewing on se
On Thu, 12 Apr 2007, Jason Lustig wrote:
0 <-- BM starts here
10 0180 700436 16420 9174000 0 176 278 2923 59 41 0
0 0
11 0180 696736 16420 9174000 0 0 254 2904 57 43 0
0 0
12 0180 691272 16420 9174000 0 0 255 3043 60
On 12.04.2007, at 08:59, Ron wrote:
1= Unless I missed something, the OP described pg being used as a
backend DB for a webserver.
Yep.
I know the typical IO demands of that scenario better than I
sometimes want to.
:-(
Yep. Same here. ;-)
2= 1GB of RAM + effectively 1 160GB HD = p*ss
At 10:08 AM 4/12/2007, Guido Neitzer wrote:
On 12.04.2007, at 07:26, Ron wrote:
You need to buy RAM and HD.
Before he does that, wouldn't it be more useful, to find out WHY he
has so much IO?
1= Unless I missed something, the OP described pg being used as a
backend DB for a webserver.
I
On 12.04.2007, at 07:26, Ron wrote:
You need to buy RAM and HD.
Before he does that, wouldn't it be more useful, to find out WHY he
has so much IO?
Have I missed that or has nobody suggested finding the slow queries
(when you have much IO on them, they might be slow at least with a
hig
1= RAID 1improves data =intregrity=, not IO performance.
Your HD IO performance is essentially that of 1 160GB HD of whatever
performance one of those HDs have.
(what kind of HDs are they anyway? For instance 7200rpm 160GB HDs
are not particularly "high performance")
BEST case is streaming IO
On Wed, 11 Apr 2007, Jason Lustig wrote:
Hello all,
My website has been having issues with our new Linux/PostgreSQL server being
somewhat slow. I have done tests using Apache Benchmark and for pages that do
not connect to Postgres, the speeds are much faster (334 requests/second v.
1-2 reque
Jason Lustig skrev:
and work_mem to 8096. What would cause the computer to only use such a
small percentage of the CPU, with more than half of it waiting on I/O
requests?
Do your webpages write things to the database on each connect?
Maybe it do a bunch of writes each individually commited? F
Hello all,
My website has been having issues with our new Linux/PostgreSQL
server being somewhat slow. I have done tests using Apache Benchmark
and for pages that do not connect to Postgres, the speeds are much
faster (334 requests/second v. 1-2 requests/second), so it seems that
Postgres
13 matches
Mail list logo
