Re: [PERFORM] Bad RAID1 read performance
As you suggested with two threads I get 42.39 Mb/s in one and 40.70 Mb/s in the other one, so that's more than 80Mb/s. That's what I expected with a single thread, so thanks for the information. It seems I will have to buy better hard drives if I want increased performance... A Dimecres 30 Maig 2007 22:13, Luke Lonergan va escriure: Not for one thread/process of I/O. Mirror sets can nearly double the read performance on most RAID adapters or SW RAID when using two or more thread/processes, but a single thread will get one drive worth of performance. You should try running two simultaneous processes during reading and see what you get. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PERFORM] DB cluster sharing between 32 and 64 bit software versions
Hello, I am going to build a new PostgreSQL dedicated server, on FreeBSD. Before it goes to production service I need to make some tests and take configuration decisions, focused on my application needs. Usual thing. One of them is selection of one of 32 or 64 bit versions of both OS and PG. What I am going to do is to install both versions on different filesystems of the same machine. As a consequence I would also have to deal with two independent copies of my real databases on which I want to perfrom my tests. However, the databases are rather large, so I am thinking about possibilities of not to have to restore two copies of my data, but use just one instead, and sharing it between the 32 and 64 versions, across reboots. Would that scenario work, or I am simply too naive considering it? Thanks Ireneusz Pluta PS. Or rather, instead of testing 32/64 bit, I would just simply go with 64 bit, considering that the server has quad core X5355 Xeon and 16GB RAM? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] DB cluster sharing between 32 and 64 bit software versions
In response to Ireneusz Pluta [EMAIL PROTECTED]: Hello, I am going to build a new PostgreSQL dedicated server, on FreeBSD. Before it goes to production service I need to make some tests and take configuration decisions, focused on my application needs. Usual thing. One of them is selection of one of 32 or 64 bit versions of both OS and PG. What I am going to do is to install both versions on different filesystems of the same machine. As a consequence I would also have to deal with two independent copies of my real databases on which I want to perfrom my tests. However, the databases are rather large, so I am thinking about possibilities of not to have to restore two copies of my data, but use just one instead, and sharing it between the 32 and 64 versions, across reboots. Would that scenario work, or I am simply too naive considering it? It won't work, unfortunately. The on-disk representation of the data is different between ia32 and amd64. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PERFORM] Some info to share: db_STRESS Benchmark results
Folks, just wanted to share some benchmark results from one long performance study comparing MySQL, PostgreSQL and Oracle transactions throughput and engine scalability on T2000 and V890 (under Solaris). Oracle results are removed (of course :), but other are quite interesting... Findings are presented as it, following step by step learning and tuning curve :) So well, you may find: - http://dimitrik.free.fr/db_STRESS.html - Benchmark kit description - http://dimitrik.free.fr/db_STRESS_BMK_Part1.html -- first main part - http://dimitrik.free.fr/db_STRESS_BMK_Part2_ZFS.html -- second part including ZFS specific tuning Tests were executed in Mar/Apr.2007 with latest v8.2.3 on that time. Due limited spare time I was able to publish results only now... Any comments are welcome! :) Best regards! -Dimitri ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] Some info to share: db_STRESS Benchmark results
On 5/31/07, Dimitri [EMAIL PROTECTED] wrote: just wanted to share some benchmark results from one long performance study comparing MySQL, PostgreSQL and Oracle transactions throughput and engine scalability on T2000 and V890 (under Solaris). Interesting, if awfully cryptic. The lack of axis labels, the lack of axis normalization, and the fact that you put the graphs for different databases and parameters on separate pages makes it rather hard to compare the various results. Alexander. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] Some info to share: db_STRESS Benchmark results
Well, let's say I want to have compact graphs :) So, few comments on graphs: - Title: compact name of test and execution conditions - X-axis: is always representing time scale - Y-axis: is showing a value level (whatever) - Legend: gives you a value Name and its metric (KB/s, Op/s, TPS, etc) TPS: (transactions per second) - ALL-tps TR_all: all transactions (READ+WRITE) per second level - ALL-tps TR_Read: only READ tps level - ALL-tps TR_Write: only WRITE tps level I must say I was more intrested by databases tuning rather documenting each my step... But well, without documenting there is no result :) As well I did not think to compare database initially (don't know why but it's always starting a small war between DB vendors :)), but results were so surprising so I just continued until it was possible :)) Rgds, -Dimitri On 5/31/07, Alexander Staubo [EMAIL PROTECTED] wrote: On 5/31/07, Dimitri [EMAIL PROTECTED] wrote: just wanted to share some benchmark results from one long performance study comparing MySQL, PostgreSQL and Oracle transactions throughput and engine scalability on T2000 and V890 (under Solaris). Interesting, if awfully cryptic. The lack of axis labels, the lack of axis normalization, and the fact that you put the graphs for different databases and parameters on separate pages makes it rather hard to compare the various results. Alexander. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] max_fsm_pages, shared_buffers and checkpoint_segments
On May 23, 2007, at 4:40 PM, Peter Schuller wrote: Sounds like you need to increase your shared memory limits. Unfortunately this will require a reboot on FreeBSD :( No, it does not. You can tune some of the sysv IPC parameters at runtime. the shmmax and shmall are such parameters. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] setting up raid10 with more than 4 drives
On Wed, May 30, 2007 at 12:41:46AM -0400, Jonah H. Harris wrote: Yeah, I've never seen a way to RAID-1 more than 2 drives either. pannekake:~ grep -A 1 md0 /proc/mdstat md0 : active raid1 dm-20[2] dm-19[1] dm-18[0] 64128 blocks [3/3] [UUU] It's not a big device, but I can ensure you it exists :-) /* Steinar */ -- Homepage: http://www.sesse.net/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] setting up raid10 with more than 4 drives
Hi, Op 1-jun-2007, om 1:39 heeft Steinar H. Gunderson het volgende geschreven: On Wed, May 30, 2007 at 12:41:46AM -0400, Jonah H. Harris wrote: Yeah, I've never seen a way to RAID-1 more than 2 drives either. pannekake:~ grep -A 1 md0 /proc/mdstat md0 : active raid1 dm-20[2] dm-19[1] dm-18[0] 64128 blocks [3/3] [UUU] It's not a big device, but I can ensure you it exists :-) I talked to someone yesterday who did a 10 or 11 way RAID1 with Linux MD for high performance video streaming. Seemed to work very well. - Sander ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
