Prabhjot Sheena prabhjot.she...@rivalwatch.com wrote:
PostgreSQL 8.3.7 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
20060404 (Red Hat 3.4.6-9)
Running anything on that version is insane. Not only has the 8.3
major release been out of support since February of 2013, but
you're
Thanks a lot Kevin. This is what i did to improve query performance. i
recreated all the indexes on work_unit table and have been running vacuum
analyze through cron job 3 times a day on two tables that are in the query.
The query performance is between 2 to 3 seconds now. The strange thing i
On 7/25/2014 5:58 PM, Prabhjot Sheena wrote:
We do have i/o problem during heavy loads because we share mount point
from netapp across different machines which we are getting rid in few
weeks by moving stuff to Amazon aws and than IO issues will go away
with fast iops
Netapp has to be some
Prabhjot Sheena prabhjot.she...@rivalwatch.com wrote:
I m running postgresql 8.3
That is out of support. If you are at all concerned about
performance, you would do well to upgrade to a recent and
supported major release.
http://www.postgresql.org/support/versioning/
Anyway, it is always a
On 7/21/2014 1:51 PM, Kevin Grittner wrote:
The above might help, but I think the biggest problem may be your
VM. You show very low disk I/O numbers, but a pretty significant
fraction of the time waiting for I/O. The previously-suggested
iostat output may help nail it down more specifically,
Hello All
i had a database load issue today and when i was checking logs
i saw this message. I m running postgresql 8.3
db::ts:2014-07-17 09:38:21 PDT::LOG: checkpoints are occurring too
frequently (26 seconds apart)
db::ts:2014-07-17 09:38:21 PDT::HINT: Consider increasing the
On Thu, 17 Jul 2014 10:44:32 -0700
Prabhjot Sheena prabhjot.she...@rivalwatch.com wrote:
Hello All
i had a database load issue today and when i was checking logs
i saw this message. I m running postgresql 8.3
db::ts:2014-07-17 09:38:21 PDT::LOG: checkpoints are occurring too
Potentialtech wmo...@potentialtech.com writes:
If the warning isn't happening too often, I would try increasing it only a
little and see if it helps. If it's not enough you can then increase it some
more. Various sources around the Internet suggest that you don't want to go
much larger than
Thanks i have changed that to 64 and reloaded it.
When i had load issue today there was this exact same query that hits the
db like 50 to 60 times from different machines in 3 to 4 minutes and was
taking long time to execute and was holding up the database. i did recreate
an index and it started
On Thu, 17 Jul 2014 14:06:28 -0400
Tom Lane t...@sss.pgh.pa.us wrote:
Potentialtech wmo...@potentialtech.com writes:
If the warning isn't happening too often, I would try increasing it only a
little and see if it helps. If it's not enough you can then increase it
some
more. Various
On Thu, 17 Jul 2014 11:28:04 -0700
Prabhjot Sheena prabhjot.she...@rivalwatch.com wrote:
Thanks i have changed that to 64 and reloaded it.
When i had load issue today there was this exact same query that hits the
db like 50 to 60 times from different machines in 3 to 4 minutes and was
Here is the explain plan. There query time went backup up to 2 to 3 minutes
from 3 second in just 2 hrs. Can anyone suggest something on how to fix
this or why this is happening
explain SELECT account.id, account.organization_id, run.application_id,
work_unit.script, work_unit.id,
even though the explain plan suggests differently but its taking long long
time
On Thu, Jul 17, 2014 at 4:26 PM, Prabhjot Sheena
prabhjot.she...@rivalwatch.com wrote:
Here is the explain plan. There query time went backup up to 2 to 3
minutes from 3 second in just 2 hrs. Can anyone
On 7/17/2014 4:26 PM, Prabhjot Sheena wrote:
Here is the explain plan. There query time went backup up to 2 to 3
minutes from 3 second in just 2 hrs. Can anyone suggest something on
how to fix this or why this is happening
explain SELECT account.id http://account.id,
On 7/17/2014 11:28 AM, Prabhjot Sheena wrote:
SELECT account.id http://account.id, account.organization_id,
run.application_id, work_unit.script, work_unit.id
http://work_unit.id, work_unit.start_time, run.id http://run.id,
work_unit.priority FROM work_unit, run, account WHERE
i just did explain analyze and currently database is running slow coz of
the query
explain ANALYZE SELECT account.id, account.organization_id,
run.application_id, work_unit.script, work_unit.id, work_unit.start_time,
run.id, work_unit.priority FROM work_unit, run, account WHERE
work_unit.status
On 7/17/2014 5:01 PM, Prabhjot Sheena wrote:
i just did explain analyze and currently database is running slow coz
of the query
explain ANALYZE SELECT account.id http://account.id,
account.organization_id, run.application_id, work_unit.script,
work_unit.id http://work_unit.id,
The overall load of system is good. It is a vm but the other database is
running normal and not doing much activity
vmstat 5 10
procs ---memory-- ---swap-- -io --system--
-cpu--
r b swpd free buff cache si sobibo in cs us sy id
wa st
0 2
On 7/17/2014 5:36 PM, Prabhjot Sheena wrote:
The overall load of system is good. It is a vm but the other database
is running normal and not doing much activity
other database? is that on the same postgresql cluster? or on a
seperate instance of the postgres server on the same VM? or on
19 matches
Mail list logo
