Re: [PERFORM] [JDBC] Performance problem using V3 protocol in jdbc driver

2005-08-16 Thread Barry Lind
That was my suspicion as well, which is why I tried the V2 protocol. I do not know of any specific queries that are causing the problem. As I monitor 'top' I see processes utilizing a significant amount of CPU running SELECT, UPDATE and DELETE, which would lead me to believe that it isn't any o

Re: [PERFORM] [JDBC] Performance problem using V3 protocol in jdbc driver

2005-08-16 Thread Tom Lane
"Barry Lind" <[EMAIL PROTECTED]> writes: > ... On a hunch I switched the jdbc driver to using the V2 protocol > and the load on the machine dropped down to what it was when using > Oracle and everything was fine. First knee-jerk reaction is that it's an optimization problem stemming from V3 proto

Re: [PERFORM] Finding bottleneck

2005-08-16 Thread Ron
I think I have a solution for you. You have posted that you presently have these RAID volumes and behaviors: sda: data (10 spindles, raid10) sdb: xlog & clog (2 spindles, raid1) sdc: os and other stuff Usually iostat (2 second interval) says: avg-cpu: %user %nice %sys %iowait %idle

[PERFORM] Performance problem using V3 protocol in jdbc driver

2005-08-16 Thread Barry Lind
We just moved a large production instance of ours from Oracle to Postgres 8.0.3 on linux.  When running on Oracle the machine hummed along using about 5% of the CPU easily handling the fairly constant load, after moving the data to Postgres the machine was pretty much maxed out on CPU and c

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread Alex Turner
The other point that is well made is that with enough drives you will max out the PCI bus before you max out the drives. 64-bit 66Mhz can do about 400MB/sec, which can be acheived by two 3 drive stripes (6 drive in RAID 10). A true PCI-X card can do better, but can your controller? Remember, U32

Re: [PERFORM] PG8 Tuning

2005-08-16 Thread Tom Lane
John A Meinel <[EMAIL PROTECTED]> writes: > So pg_xlog is really only needed for a dirty shutdown. So what about the > idea of having pg_xlog on a ramdisk that is syncronized periodically to > a real disk. Well, if "periodically" means "at every transaction commit", that's pretty much what we do n

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread Anjan Dave
Thanks, everyone. I got some excellent replies, including some long explanations. Appreciate the time you guys took out for the responses. The gist of it i take, is to use RAID10. I have 400MB+ of write cache on the controller(s), that the RAID5 LUN(s) could benefit from by filling it up and w

Re: [PERFORM] PG8 Tuning

2005-08-16 Thread John A Meinel
Tom Lane wrote: > John A Meinel <[EMAIL PROTECTED]> writes: > >>Alvaro Herrera wrote: >> >>>I've been asked this a couple of times and I don't know the answer: what >>>happens if you give XLog a single drive (unmirrored single spindle), and >>>that drive dies? So the question really is, should you

Re: [PERFORM] PG8 Tuning

2005-08-16 Thread Tom Lane
John A Meinel <[EMAIL PROTECTED]> writes: > Alvaro Herrera wrote: >> I've been asked this a couple of times and I don't know the answer: what >> happens if you give XLog a single drive (unmirrored single spindle), and >> that drive dies? So the question really is, should you be giving two >> disks

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread Gregory S. Williamson
I would be very cautious about ever using RAID5, despite manufacturers' claims to the contrary. The link below is authored by a very knowledgable fellow whose posts I know (and trust) from Informix land. Greg Williamson DBA GlobeXplorer L

Re: [PERFORM] Looking for a large database for testing

2005-08-16 Thread Sebastian Hennebrueder
Sebastian Hennebrueder schrieb: >Tino Wildenhain schrieb: > > > > >>You can download the wikipedia content. Just browse the wikimedia site. >>Its some work to change the data to be able to import into postgres, >>but at least you have a lot real world data - in many languages. >> >> > >I hav

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread Alex Turner
Don't forget that often controlers don't obey fsyncs like a plain drive does. thats the point of having a BBU ;) Alex Turner NetEconomist On 8/16/05, John A Meinel <[EMAIL PROTECTED]> wrote: > Anjan Dave wrote: > > Yes, that's true, though, I am a bit confused because the Clariion array > > docu

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread Alex Turner
Theoretically RAID 5 can perform better than RAID 10 over the same number of drives (more members form the stripe in RAID 5 than in RAID 10). All you have to do is calculate parity faster than the drives can write. Doesn't seem like a hard task really, although most RAID controllers seem incapabl

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread John A Meinel
Anjan Dave wrote: > Yes, that's true, though, I am a bit confused because the Clariion array > document I am reading talks about how the write cache can eliminate the > RAID5 Write Penalty for sequential and large IOs...resulting in better > sequential write performance than RAID10. > > anjan > To

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread John A Meinel
Anjan Dave wrote: > Yes, that's true, though, I am a bit confused because the Clariion array > document I am reading talks about how the write cache can eliminate the > RAID5 Write Penalty for sequential and large IOs...resulting in better > sequential write performance than RAID10. > > anjan > We

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread Vivek Khera
On Aug 16, 2005, at 2:37 PM, Anjan Dave wrote: Yes, that's true, though, I am a bit confused because the Clariion array document I am reading talks about how the write cache can eliminate the RAID5 Write Penalty for sequential and large IOs...resulting in better sequential write performance

Re: [PERFORM] Need for speed

2005-08-16 Thread Dennis Bjorklund
On Tue, 16 Aug 2005, Ulrich Wisser wrote: > Still when several users are on line the reporting gets very slow. > Queries can take more then 2 min. Could you show an exampleof such a query and the output of EXPLAIN ANALYZE on that query (preferably done when the database is slow). It's hard to s

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread Anjan Dave
Yes, that's true, though, I am a bit confused because the Clariion array document I am reading talks about how the write cache can eliminate the RAID5 Write Penalty for sequential and large IOs...resulting in better sequential write performance than RAID10. anjan -Original Message- From:

Re: [PERFORM] Need for speed

2005-08-16 Thread Alex Turner
Are you calculating aggregates, and if so, how are you doing it (I ask the question from experience of a similar application where I found that my aggregating PGPLSQL triggers were bogging the system down, and changed them so scheduled jobs instead). Alex Turner NetEconomist On 8/16/05, Ulrich Wi

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread mudfoot
Quoting Anjan Dave <[EMAIL PROTECTED]>: > Hi, > > > > One simple question. For 125 or more checkpoint segments > (checkpoint_timeout is 600 seconds, shared_buffers are at 21760 or > 170MB) on a very busy database, what is more suitable, a separate 6 disk > RAID5 volume, or a RAID10 volume? Dat

Re: [SPAM?] Re: [PERFORM] PG8 Tuning

2005-08-16 Thread Michael Stone
On Tue, Aug 16, 2005 at 09:12:31AM -0700, Josh Berkus wrote: However, you are absolutely correct in that it's *relative* advice, not absolute advice. If, for example, you're using a $100,000 EMC SAN as your storage you'll probably be better off giving it everything and letting its controller

Re: [PERFORM] PG8 Tuning

2005-08-16 Thread John A Meinel
Alvaro Herrera wrote: > On Tue, Aug 16, 2005 at 09:12:31AM -0700, Josh Berkus wrote: > > >>However, you are absolutely correct in that it's *relative* advice, not >>absolute advice. If, for example, you're using a $100,000 EMC SAN as your >>storage you'll probably be better off giving it everythi

Re: [PERFORM] Need for speed

2005-08-16 Thread Jeffrey W. Baker
On Tue, 2005-08-16 at 17:39 +0200, Ulrich Wisser wrote: > Hello, > > one of our services is click counting for on line advertising. We do > this by importing Apache log files every five minutes. This results in a > lot of insert and delete statements. At the same time our customers > shall be a

Re: [SPAM?] Re: [PERFORM] PG8 Tuning

2005-08-16 Thread Joshua D. Drake
I've been asked this a couple of times and I don't know the answer: what happens if you give XLog a single drive (unmirrored single spindle), and that drive dies? So the question really is, should you be giving two disks to XLog? If that drive dies your restoring from backup. You would need t

Re: [SPAM?] Re: [PERFORM] PG8 Tuning

2005-08-16 Thread Alvaro Herrera
On Tue, Aug 16, 2005 at 09:12:31AM -0700, Josh Berkus wrote: > However, you are absolutely correct in that it's *relative* advice, not > absolute advice. If, for example, you're using a $100,000 EMC SAN as your > storage you'll probably be better off giving it everything and letting its > con

Re: [PERFORM] Need for speed

2005-08-16 Thread John A Meinel
Ulrich Wisser wrote: > Hello, > > one of our services is click counting for on line advertising. We do > this by importing Apache log files every five minutes. This results in a > lot of insert and delete statements. At the same time our customers > shall be able to do on line reporting. What are

Re: [SPAM?] Re: [PERFORM] PG8 Tuning

2005-08-16 Thread Josh Berkus
Jeff, > > 4) pg_xlog: If you're pg_xlog is on a spindle is *only* for pg_xlog > > you're better off. > > Like Mr. Stone said earlier, this is pure dogma.  In my experience, > xlogs on the same volume with data is much faster if both are on > battery-backed write-back RAID controller memory.  Movin

Re. : [PERFORM] Need for speed

2005-08-16 Thread bsimon
Hi, How much Ram do you have ? Could you give us your postgresql.conf ? (shared buffer parameter) If you do lots of deletes/inserts operations you HAVE to vacuum analyze your table (especially if you have indexes). I'm not sure if vacuuming locks your table with pg 7.4.2 (it doesn't with 8.0

Re: [PERFORM] Need for speed

2005-08-16 Thread Richard Huxton
Ulrich Wisser wrote: Hello, one of our services is click counting for on line advertising. We do this by importing Apache log files every five minutes. This results in a lot of insert and delete statements. At the same time our customers shall be able to do on line reporting. I need some id

[PERFORM] Need for speed

2005-08-16 Thread Ulrich Wisser
Hello, one of our services is click counting for on line advertising. We do this by importing Apache log files every five minutes. This results in a lot of insert and delete statements. At the same time our customers shall be able to do on line reporting. We have a box with Linux Fedora Core

Re: [PERFORM] Looking for a large database for testing

2005-08-16 Thread Oleg Bartunov
Sebastian, you can try document generator. I used http://www.cs.rmit.edu.au/~jz/resources/finnegan.zip yuo can play with freq. of words and document length distribution. Also, I have SentenceGenerator.java which could be used for generation of synthetic texts. Oleg On Tue, 16 Aug 2005,

Re: [PERFORM] Looking for a large database for testing

2005-08-16 Thread Mark Rae
On Tue, Aug 16, 2005 at 09:29:32AM +0200, Sebastian Hennebrueder wrote: > I would like to test the performance of my Java/PostgreSQL applications > especially when making full text searches. > For this I am looking for a database with 50 to 300 MB having text fields. > e.g. A table with books with

Re: [PERFORM] database encoding with index search problem

2005-08-16 Thread Richard Huxton
wisan watcharinporn wrote: problem: how can i configure database that can correct in sorting name and using index scan in like '%' search I think you'll want to read the following then have a quick search of the mailing list archives for "opclass" for some examples. http://www.postgres

Re: [PERFORM] Looking for a large database for testing

2005-08-16 Thread Sebastian Hennebrueder
Tino Wildenhain schrieb: > Sebastian Hennebrueder schrieb: > >> Hello, >> >> I would like to test the performance of my Java/PostgreSQL applications >> especially when making full text searches. >> For this I am looking for a database with 50 to 300 MB having text >> fields. >> e.g. A table with b

Re: [PERFORM] Looking for a large database for testing

2005-08-16 Thread Tino Wildenhain
Sebastian Hennebrueder schrieb: Hello, I would like to test the performance of my Java/PostgreSQL applications especially when making full text searches. For this I am looking for a database with 50 to 300 MB having text fields. e.g. A table with books with fields holding a comment, table of con

[PERFORM] Looking for a large database for testing

2005-08-16 Thread Sebastian Hennebrueder
Hello, I would like to test the performance of my Java/PostgreSQL applications especially when making full text searches. For this I am looking for a database with 50 to 300 MB having text fields. e.g. A table with books with fields holding a comment, table of content or example chapters or what e

[PERFORM] database encoding with index search problem

2005-08-16 Thread wisan watcharinporn
i have problem in database encoding with indexing case :1 when i initdb -E win874 mydb and create database with createdb -E win874 dbname and create table emp with index in empname field i can select sorting name correct in thai alphabet such select empName from emp order by empName; but in s