Remove me from your email traffic.
> Date: Thu, 24 Jun 2010 23:05:06 -0400
> Subject: Re: [PERFORM] requested shared memory size overflows size_t
> From: robertmh...@gmail.com
> To: alvhe...@commandprompt.com
> CC: craig_ja...@emolecules.com; pgsql-performance@postgresql.org
>
On Thu, Jun 24, 2010 at 7:19 PM, Alvaro Herrera
wrote:
> Excerpts from Craig James's message of jue jun 24 19:03:00 -0400 2010:
>
>> select relname, pg_relation_size(relname) from pg_class
>> where pg_get_userbyid(relowner) = 'emol_warehouse_1'
>> and relname not like 'pg_%'
>>
Excerpts from Craig James's message of jue jun 24 19:03:00 -0400 2010:
> select relname, pg_relation_size(relname) from pg_class
> where pg_get_userbyid(relowner) = 'emol_warehouse_1'
> and relname not like 'pg_%'
> order by pg_relation_size(relname) desc;
> ERROR: rela
Can anyone tell me what's going on here? I hope this doesn't mean my system
tables are corrupt...
Thanks,
Craig
select relname, pg_relation_size(relname) from pg_class
where pg_get_userbyid(relowner) = 'emol_warehouse_1'
and relname not like 'pg_%'
order by pg_relation
On Jun 16, 2010, at 1:53 PM, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of lun jun 14 23:57:11 -0400 2010:
>> Scott Carey writes:
>>> Great points. There is one other option that is decent for the WAL:
>>> If splitting out a volume is not acceptable for the OS and WAL --
>>> abso
Kenneth Marshall wrote:
Zabbix-1.8+ is also worth taking a look at and it can run off our
favorite database. It allows for some very flexible monitoring and
trending data collection.
Note that while Zabbix is perfectly reasonable general solution, the
number of things it monitors out of the
On Fri, Jun 18, 2010 at 12:46:11AM +0100, Tom Wilcox wrote:
> On 17/06/2010 22:41, Greg Smith wrote:
>> Tom Wilcox wrote:
>>> Any suggestions for good monitoring software for linux?
>>
>> By monitoring, do you mean for alerting purposes or for graphing purposes?
>> Nagios is the only reasonable c
On 17/06/2010 22:41, Greg Smith wrote:
Tom Wilcox wrote:
Any suggestions for good monitoring software for linux?
By monitoring, do you mean for alerting purposes or for graphing
purposes? Nagios is the only reasonable choice for the former, while
doing at best a mediocre job at the latter.
Tom Wilcox wrote:
Any suggestions for good monitoring software for linux?
By monitoring, do you mean for alerting purposes or for graphing
purposes? Nagios is the only reasonable choice for the former, while
doing at best a mediocre job at the latter. For the later, I've found
that Munin d
Thanks. I will try with a more sensible value of wal_buffers.. I was
hoping to keep more in memory and therefore reduce the frequency of disk
IOs..
Any suggestions for good monitoring software for linux?
On 15/06/2010 00:08, Robert Haas wrote:
On Mon, Jun 14, 2010 at 2:53 PM, Tom Wilcox wrot
Excerpts from Tom Lane's message of lun jun 14 23:57:11 -0400 2010:
> Scott Carey writes:
> > Great points. There is one other option that is decent for the WAL:
> > If splitting out a volume is not acceptable for the OS and WAL --
> > absolutely split those two out into their own partitions. I
Scott Carey writes:
> Great points. There is one other option that is decent for the WAL:
> If splitting out a volume is not acceptable for the OS and WAL -- absolutely
> split those two out into their own partitions. It is most important to make
> sure that WAL and data are not on the same fi
On Jun 14, 2010, at 7:06 PM, Greg Smith wrote:
> I really cannot imagine taking a system as powerful as you're using here
> and crippling it by running through a VM. You should be running Ubuntu
> directly on the hardware, ext3 filesystem without LVM, split off RAID-1
> drive pairs dedicated
On Jun 14, 2010, at 11:53 AM, Tom Wilcox wrote:
>
>
> max_connections=3
> effective_cache_size=15GB
> maintenance_work_mem=5GB
> shared_buffers=7000MB
> work_mem=5GB
>
maintenance_work_mem doesn't need to be so high, it certainly has no effect on
your queries below. It would affect vacuum,
Tom Wilcox wrote:
default_statistics_target=1
wal_buffers=1GB
max_connections=3
effective_cache_size=15GB
maintenance_work_mem=5GB
shared_buffers=7000MB
work_mem=5GB
That value for default_statistics_target means that every single query
you ever run will take a seriously long time to gener
software, setting a couple of GUCs and running it.
Bob
--- On Thu, 6/10/10, Tom Wilcox mailto:hungry...@gmail.com>
<mailto:hungry...@gmail.com
<mailto:hungry...@gmail.com>>> wrote:
Fro
would still appreciate any suggestions.
>>
>>Cheers,
>>Tom
>>
>>
>>On 11/06/2010 07:25, Bob Lunney wrote:
>>
>>Tom,
>>
>> First off, I wouldn't use a VM if I could help it, however,
>>sometimes you ha
performance than simply installing the
software, setting a couple of GUCs and running it.
Bob
--- On Thu, 6/10/10, Tom Wilcox mailto:hungry...@gmail.com>> wrote:
From: Tom Wilcox mailto:hungry...@gmail.com>>
Subject: Re: [PERFORM
leave more than enough room for the OS and file system cache. Then
>> I'd begin testing by measuring response times of representative queries with
>> significant amounts of data.
>>
>> Also, what is the disk setup for the box? Filesystem? Can WAL files have
>>
On Mon, Jun 14, 2010 at 2:53 PM, Tom Wilcox wrote:
> maintenance_work_mem=4GB
> work_mem=4GB
> shared_buffers=4GB
> effective_cache_size=4GB
> wal_buffers=1GB
It's pretty easy to drive your system into swap with such a large
value for work_mem - you'd better monitor that carefully.
The default v
Can WAL files have
their own disk? Is the workload OLTP or OLAP, or a mixture of both? There is
more that goes into tuning a PG server for good performance than simply
installing the software, setting a couple of GUCs and running it.
Bob
--- On Thu, 6/10/10, Tom Wilcox wrote:
From: Tom
s into tuning a PG server for good performance than simply
installing the software, setting a couple of GUCs and running it.
Bob
--- On Thu, 6/10/10, Tom Wilcox wrote:
> From: Tom Wilcox
> Subject: Re: [PERFORM] requested shared memory size overflows size_t
> To: "Bob Lunney&
ERFORM] requested shared memory size overflows size_t
> To: "Bob Lunney"
> Cc: pgsql-performance@postgresql.org, "Tom Wilcox"
> Date: Wednesday, June 9, 2010, 9:49 PM
> On Wed, Jun 2, 2010 at 9:26 PM, Bob
> Lunney
> wrote:
> > Your other option, of course,
On Wed, Jun 2, 2010 at 9:26 PM, Bob Lunney wrote:
> Your other option, of course, is a nice 64-bit linux variant, which won't
> have this problem at all.
Although, even there, I think I've heard that after 10GB you don't get
much benefit from raising it further. Not sure if that's accurate or
n
On Wed, Jun 02, 2010 at 11:58:47AM +0100, Tom Wilcox wrote:
> Hi,
>
> Sorry to revive an old thread but I have had this error whilst trying to
> configure my 32-bit build of postgres to run on a 64-bit Windows Server
> 2008 machine with 96GB of RAM (that I would very much like to use with
> p
riant, which won't have
this problem at all.
Good luck!
Bob Lunney
--- On Wed, 6/2/10, Tom Wilcox wrote:
> From: Tom Wilcox
> Subject: Re: [PERFORM] requested shared memory size overflows size_t
> To: pgsql-performance@postgresql.org
> Date: Wednesday, June 2, 2010, 6:58
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> Tom Wilcox wrote:
> > Is it possible to get postgres to make use of the available 96GB
> > RAM on a Windows 32-bit build?
>
> I would try setting shared_memory to somewhere between 200MB and 1GB
> and set effective_cache_size = 90GB or so.
Tom Wilcox wrote:
> Is it possible to get postgres to make use of the available 96GB
> RAM on a Windows 32-bit build?
I would try setting shared_memory to somewhere between 200MB and 1GB
and set effective_cache_size = 90GB or so. The default behavior of
Windows was to use otherwise idle RAM f
Hi,
Sorry to revive an old thread but I have had this error whilst trying to
configure my 32-bit build of postgres to run on a 64-bit Windows Server
2008 machine with 96GB of RAM (that I would very much like to use with
postgres).
I am getting:
2010-06-02 11:34:09 BSTFATAL: requested share
Hey there;
As Tom notes before maybe you're not using the right postgres. Solaris 10
comes with a postgres, but on SPARC it's 32 bit compiled (I can't speak to
x86 Solaris though).
Assuming that's not the problem, you can be 100% sure if your Postgres
binary is actually 64 bit by using the file
"Uwe Bartels" <[EMAIL PROTECTED]> writes:
> When trying to to set shared_buffers greater then 3,5 GB on 32 GB x86
> machine with solaris 10 I running in this error:
> FATAL: requested shared memory size overflows size_t
> The solaris x86 ist 64-bit and the compiled postgres is as well 64-bit.
Eit
Hi,
When trying to to set shared_buffers greater then 3,5 GB on 32 GB x86
machine with solaris 10 I running in this error:
FATAL: requested shared memory size overflows size_t
The solaris x86 ist 64-bit and the compiled postgres is as well 64-bit.
Postgresql 8.2.5.
max-shm ist allowed to 8GB.
pr
32 matches
Mail list logo
