On 26/06/2010 3:36 AM, t...@exquisiteimages.com wrote:
I am in the process of moving a system that has been built around FoxPro
tables for the last 18 years into a PostgreSQL based system.
Over time I came up with decent strategies for making the FoxPro tables
work well with the workload that wa
Dear Greg/Kevin/List ,
Many thanks for the comments regarding the params, I am however able to
change an
experiment on production in a certain time window , when that arrives i
shall post
my observations.
Rajesh Kumar Mallah.
Tradeindia.com - India's Largest B2B eMarketPlace.
Interesting point you made about the read to write ratio of 1 to 15.
How frequently will you be adding new entities or in the case of storing the
customers in one database table, how frequently will you be adding new
objects of a certain entity type. How many entity types do you foresee
existing? i
On Thu, Jun 24, 2010 at 10:55 AM, Anj Adu wrote:
> What would you recommend to do a quick test for this? (i.e WAL on
> internal disk vs WALon the 12 disk raid array )?
Maybe just pgbench?
http://archives.postgresql.org/pgsql-performance/2010-06/msg00223.php
--
Robert Haas
EnterpriseDB: http://
Kevin Grittner wrote:
A schema is a logical separation within a database. Table
client1.account is a different table from client2.account. While a
user can be limited to tables within a single schema, a user with
rights to all the tables can join between them as needed. You could
put common re
On 6/25/10 3:28 PM, Kevin Grittner wrote:
wrote:
With the PostgreSQL type tables I am not so certain how the data
is arranged within the one file. Does having the data all in one
database allow PostgreSQL to better utilize indexes and caches or
does having a number of smaller databases provide
wrote:
> With the dBase and ISAM tables I have a good idea of how to handle
> them since I have been working with them since dBASE originally
> came out.
Ah, someone with whom I can reminisce about CP/M and WordStar? :-)
> With the PostgreSQL type tables I am not so certain how the data
> i
On 25/06/10 20:00, Rajesh Kumar Mallah wrote:
Dear tom, we have autocommit off in dbi. Any commit or rollback from
the persistent modperl process immediately issues begin work; if the
modperl process is waiting for request the database backend remains in
idle in transaction state. Unless we modif
I am in the process of moving a system that has been built around FoxPro
tables for the last 18 years into a PostgreSQL based system.
Over time I came up with decent strategies for making the FoxPro tables
work well with the workload that was placed on them, but we are getting to
the point that th
Craig James wrote:
I've got a new server and want to make sure it's running well.
Any changes to the postgresql.conf file? Generally you need at least a
moderate shared_buffers (1GB or so at a minimum) and checkpoint_segments
(32 or higher) in order for the standard pgbench test to give good
On Fri, Jun 25, 2010 at 2:53 PM, Craig James wrote:
> I've got a new server and want to make sure it's running well. Are these
> pretty decent numbers?
>
> 8 cores (2x4 Intel Nehalem 2 GHz)
> 12 GB memory
> 12 x 7200 SATA 500 GB disks
> 3WARE 9650SE-12ML RAID controller with BBU
> WAL on ext2, 2
Dear tom, we have autocommit off in dbi. Any commit or rollback from
the persistent modperl process immediately issues begin work; if the
modperl process is waiting for request the database backend remains in
idle in transaction state. Unless we modify data in a http request we
neighter issue a com
I've got a new server and want to make sure it's running well. Are these
pretty decent numbers?
8 cores (2x4 Intel Nehalem 2 GHz)
12 GB memory
12 x 7200 SATA 500 GB disks
3WARE 9650SE-12ML RAID controller with BBU
WAL on ext2, 2 disks: RAID1 500GB, blocksize=4096
Database on ext4, 8 disks:
I'm trying to find someone who has a system with an AMD "Magny Cours"
6100 series processor in it, like the Opteron 6174 or 6176 SE, who'd be
willing to run a short test for me during an idle period to collect some
performance data about it. Can't be running Windows, probably easiest
to compil
On Jun 24, 2010, at 6:16 AM, Janning wrote:
> On Thursday 24 June 2010 14:53:57 Matthew Wakeling wrote:
>> On Thu, 24 Jun 2010, Janning wrote:
>>> We have a 12 GB RAM machine with intel i7-975 and using
>>> 3 disks "Seagate Barracuda 7200.11, ST31500341AS (1.5 GB)"
>>
>> Those discs are 1.5TB, n
On 6/25/10 9:41 AM, Kevin Grittner wrote:
Craig James wrote:
I always just assumed that lots of backends that would be harmless
if each one was doing very little.
Even if each is doing very little, if a large number of them happen
to make a request at the same time, you can have problems. T
Rajesh Kumar Mallah wrote:
default_statistics_target = 50 # pgtune wizard 2010-06-25
(current 100 via default)
(*) effective_cache_size = 22GB # pgtune wizard 2010-06-25 (18GB ,
specified)
checkpoint_segments = 16 # pgtune wizard 2010-06-25 (30 , specified)
You probably want to kee
Craig James writes:
> On 6/25/10 7:47 AM, Tom Lane wrote:
>> Any chance of going to 8.4? If this is what I suspect, you really need
>> this 8.4 fix:
>> http://archives.postgresql.org/pgsql-committers/2008-06/msg00227.php
>> which eliminated the thundering-herd behavior that previous releases
>> e
Craig James wrote:
if I upgrade a bloated database using the upgrade-in-place feature,
will 8.4.4 recover the bloat and return it to the OS, or do I still
have to recover the space manually (like vacuum-full/reindex, or
cluster, or copy/drop a table)?
There's no way for an upgrade in place to
Rajesh Kumar Mallah wrote:
> pgtune suggests the following:
> (current value are in braces via reason) , (*) indicates
> significant difference from current value.
Different people have come to different conclusions on some of these
settings. I believe that's probably because differences in h
Craig James wrote:
> I always just assumed that lots of backends that would be harmless
> if each one was doing very little.
Even if each is doing very little, if a large number of them happen
to make a request at the same time, you can have problems. This is
exactly where a connection pool c
On 25/06/10 16:59, Rajesh Kumar Mallah wrote:
when i reduce max_connections i start getting errors, i will see again
concurrent connections
during business hours. lot of our connections are in transaction state> during business
this peculiar behavior of mod_perl servers have been discussed in
On 6/25/10 7:47 AM, Tom Lane wrote:
Craig James writes:
On 6/24/10 9:04 PM, Tom Lane wrote:
sinval queue overflow comes to mind ... although that really shouldn't
happen if there's "no real load" on the server. What PG version is
this?
8.3.10. Upgraded based on your advice when I first as
Dear Criag,
also check for the possibility of installing sysstat in our system.
it goes a long way in collecting the system stats. you may
consider increasing the frequency of data collection by
changing the interval of cron job manually in /etc/cron.d/
normally its */10 , you may make it */2 for
Dear List,
pgtune suggests the following:
(current value are in braces via reason) , (*) indicates significant
difference from current value.
default_statistics_target = 50 # pgtune wizard 2010-06-25 (current 100
via default)
(*) maintenance_work_mem = 1GB # pgtune wizard 2010-06-25 (16MB v
I changed shared_buffers from 10G to 4G ,
swap usage has almost become nil.
# free
total used free sharedbuffers cached
Mem: 32871276 245758248295452 0 11064 22167324
-/+ buffers/cache:2397436 30473840
Swap: 4192912
Craig James writes:
> On 6/24/10 9:04 PM, Tom Lane wrote:
>> sinval queue overflow comes to mind ... although that really shouldn't
>> happen if there's "no real load" on the server. What PG version is
>> this?
> 8.3.10. Upgraded based on your advice when I first asked this question.
Any chanc
Rajesh Kumar Mallah wrote:
> its now non business hours and
> SELECT procpid,current_query from pg_stat_activity where
> current_query not ilike '%idle%' ;
> is just 5-10, i am yet to measure it during business hours.
Be careful about ' in transaction' status. Those are a
problem if the tra
Dear List,
Hmmm , lemme test efficacy of pg_tune.
I would reduce shared buffers also.
regarding concurrent queries:
its now non business hours and
SELECT procpid,current_query from pg_stat_activity where
current_query not ilike '%idle%' ;
is just 5-10, i am yet to measure it during business ho
On 6/24/10 9:04 PM, Tom Lane wrote:
Craig James writes:
So what is it that will cause every single Postgres backend to come to life at
the same moment, when there's no real load on the server? Maybe if a backend
crashes? Some other problem?
sinval queue overflow comes to mind ... although
Rajesh Kumar Mallah wrote:
A scary phenomenon is being exhibited by the server , which is the server
is slurping all the swap suddenly
8 1 4192912 906164 6100 2787364000 2277 858 13440 16235
63 8 19 10 0
I reduced work_mem from 4GB to 2GB to 512MB (now). I clearly remember t
On Fri, 2010-06-25 at 15:25 +0530, Rajesh Kumar Mallah wrote:
> shared_buffers = 10GB # min 128kB
> work_mem = 512MB# min 64kB
These are still pretty high IMHO. How many *concurrent* connections do
you have?
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consulta
A scary phenomenon is being exhibited by the server , which is the server
is slurping all the swap suddenly , some of the relevant sar -r output are:
10:30:01 AM kbmemfree kbmemused %memused kbbuffers kbcached
kbswpfree kbswpused %swpused kbswpcad
10:40:01 AM979068 31892208 97.02
33 matches
Mail list logo
