Jeff Ross wrote:
Hopefully if I can get it to run well under pgbench the same setup
will work well with drupal. The site I was worried about when I went
to this bigger server has started a little slower than originally
projected so the old server is handling the load.
The standard TPC-B-like
Greg Smith wrote:
Jeff Ross wrote:
I think I'm doing it right. Here's the whole script. I run it from
another server on the lan.
That looks basically sane--your description was wrong, not your
program, which is always better than the other way around.
Note that everything your script is d
Jeff Ross wrote:
I think I'm doing it right. Here's the whole script. I run it from
another server on the lan.
That looks basically sane--your description was wrong, not your program,
which is always better than the other way around.
Note that everything your script is doing and way more i
Greg Smith wrote:
Jeff Ross wrote:
pgbench is run with this:
pgbench -h varley.openvistas.net -U _postgresql -t 2 -c $SCALE
pgbench
with scale starting at 10 and then incrementing by 10. I call it
three times for each scale. I've turned on logging to 'all' to try
and help figure out whe
Jeff Ross wrote:
pgbench is run with this:
pgbench -h varley.openvistas.net -U _postgresql -t 2 -c $SCALE pgbench
with scale starting at 10 and then incrementing by 10. I call it
three times for each scale. I've turned on logging to 'all' to try
and help figure out where the system panics
Tom Lane wrote:
Martijn van Oosterhout writes:
On Tue, Feb 09, 2010 at 08:19:51PM +0500, Anton Maksimenkov wrote:
Can anybody briefly explain me how one postgres process allocate
memory for it needs?
There's no real maximum, as it depends on the exact usage. However, in
ge
Martijn van Oosterhout writes:
> On Tue, Feb 09, 2010 at 08:19:51PM +0500, Anton Maksimenkov wrote:
>> Can anybody briefly explain me how one postgres process allocate
>> memory for it needs?
> There's no real maximum, as it depends on the exact usage. However, in
> general postgres tries to keep
2010/2/10 Martijn van Oosterhout :
>> Can anybody briefly explain me how one postgres process allocate
>> memory for it needs?
>
> There's no real maximum, as it depends on the exact usage. However, in
> general postgres tries to keep below the values in work_mem and
> maintainence_workmem. Most of
On Tue, Feb 09, 2010 at 08:19:51PM +0500, Anton Maksimenkov wrote:
> It means that on openbsd i386 we have about 2,2G of virtual space for
> malloc, shm*. So, postgres will use that space.
>
> But mmap() use random addresses. So when you get big chunk of memory
> for shared buffers (say, 2G) then
2010/2/9 Scott Marlowe :
> On Tue, Feb 9, 2010 at 3:18 AM, Anton Maksimenkov wrote:
>>> Isn't the usual advice here is to log the ulimit setting from the pg
>>> startup script so you can what it really is for the user at the moment
>> I think that "su" is enough:
> In previous discussions it was m
On Tue, Feb 9, 2010 at 3:18 AM, Anton Maksimenkov wrote:
> 2010/1/28 Scott Marlowe :
>>> related to maximum per-process data space. I don't know BSD very well
>>> so I can't say if datasize is the only such value for BSD, but it'd be
>>> worth checking. (Hmm, on OS X which is at least partly BSD
2010/1/28 Scott Marlowe :
>> related to maximum per-process data space. I don't know BSD very well
>> so I can't say if datasize is the only such value for BSD, but it'd be
>> worth checking. (Hmm, on OS X which is at least partly BSDish, I see
>> -m and -v in addition to -d, so I'm suspicious Op
On Wed, Jan 27, 2010 at 4:42 PM, Tom Lane wrote:
> related to maximum per-process data space. I don't know BSD very well
> so I can't say if datasize is the only such value for BSD, but it'd be
> worth checking. (Hmm, on OS X which is at least partly BSDish, I see
> -m and -v in addition to -d,
Jeff Ross writes:
> Tom Lane wrote:
>> Better look at the "ulimit" values the postmaster is started with;
> OpenBSD makes a _postgresql user on install and it is in the daemon class
> with
> the following values:
> daemon:\
> :ignorenologin:\
> :datasize=infinity:\
>
Tom Lane wrote:
Jeff Ross writes:
Running a simple select only pgbench test against it will fail with an out of
memory error as it tries to vacuum --analyze the newly created database with
750 tuples.
Better look at the "ulimit" values the postmaster is started with;
you shouldn't be get
Jeff Ross writes:
> Running a simple select only pgbench test against it will fail with an out of
> memory error as it tries to vacuum --analyze the newly created database with
> 750 tuples.
Better look at the "ulimit" values the postmaster is started with;
you shouldn't be getting that out-
I'm not getting something about the best way to set up a server using
PostgreSQL as a backend for a busy web server running drupal.
The postgresql performance folks
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
say that in a server with more that 1GB of ram
"a reasonable sta
17 matches
Mail list logo
