Re: [PERFORM] Poor performance on HP Package Cluster
Hi ! Sorry, for my late answer. I was unavailable for a few days... Yes, I'm using the build-in HP Smart Array Controller. Both, the internal disks, and the external storrage are using the controller. Can you send me your test results? I'm interested in it. I've done some testing now. I've imported the data again and tuned the DB like I was told in some performance howtos. Now, the database has a good performance - until it has to read from the disks. Greetings Ernst Am Donnerstag, den 01.09.2005, 21:54 -0700 schrieb Luke Lonergan: Dan, On 9/1/05 4:02 PM, "Dan Harris" <[EMAIL PROTECTED]> wrote: > Do you have any sources for that information? I am running dual > SmartArray 6402's in my DL585 and haven't noticed anything poor about > their performance. I've previously posted comprehensive results using the 5i and 6xxx series smart arrays using software RAID, HW RAID on 3 different kernels, alongside LSI and Adaptec SCSI controllers, and an Adaptec 24xx HW RAID adapter. Results with bonnie++ and simple sequential read/write with dd. I'll post them again here for reference in the next message. Yes, the performance of the SmartArray controllers under Linux was abysmal, even when run by the labs at HP. - Luke ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Ernst Einstein <[EMAIL PROTECTED]>
Re: [PERFORM] poor VACUUM performance on large tables
On Sep 4, 2005, at 1:16 AM, Jan Peterson wrote: Hello, We have been experiencing poor performance of VACUUM in our production database. Relevant details of our implementation are as follows: 1. We have a database that grows to about 100GB. 2. The database is a mixture of large and small tables. 3. Bulk data (stored primarily in pg_largeobject, but also in various TOAST tables) comprises about 45% of our data. 4. Some of our small tables are very active, with several hundred updates per hour. 5. We have a "rolling delete" function that purges older data on a periodic basis to keep our maximum database size at or near 100GB. Everything works great until our rolling delete kicks in. Of course, we are doing periodic VACUUMS on all tables, with frequent VACUUMs on the more active tables. The problem arises when we start deleting the bulk data and have to VACUUM pg_largeobject and our other larger tables. We have seen VACUUM run for several hours (even tens of hours). During this VACUUM process, our smaller tables accumulate dead rows (we assume because of the transactional nature of the VACUUM) at a very rapid rate. Statistics are also skewed during this process and we have observed the planner choosing sequential scans on tables where it is obvious that an index scan would be more efficient. We're looking for ways to improve the performance of VACUUM. We are already experimenting with Hannu Krosing's patch for VACUUM, but it's not really helping (we are still faced with doing a database wide VACUUM about once every three weeks or so as we approach the transaction id rollover point... this VACUUM has been measured at 28 hours in an active environment). Other things we're trying are partitioning tables (rotating the table that updates happen to and using a view to combine the sub-tables for querying). Unfortunately, we are unable to partition the pg_largeobject table, and that table alone can take up 40+% of our database storage. We're also looking at somehow storing our large objects externally (as files in the local file system) and implementing a mechanism similar to Oracle's bfile functionality. Of course, we can't afford to give up the transactional security of being able to roll back if a particular update doesn't succeed. Does anyone have any suggestions to offer on good ways to proceed given our constraints? Thanks in advance for any help you can provide. -jan- Do you have your Free Space Map settings configured appropriately? See section 16.4.3.2 of the docs: http://www.postgresql.org/docs/8.0/static/runtime-config.html#RUNTIME- CONFIG-RESOURCE You'll want to run a VACUUM VERBOSE and note the numbers at the end, which describe how many pages are used and how many are needed. max_fsm_pages should be set according to that, and you can set max_fsm_relations based on it, too, although typically one knows roughly how many relations are in a database. http://www.postgresql.org/docs/8.0/static/sql-vacuum.html Finally, have you experimented with pg_autovacuum, which is located in contrib in the source tarballs (and is integrated into the backend in 8.1 beta and beyond)? You don't really say how often you're running VACUUM, and it might be that you're not vacuuming often enough. -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open Source: Open Your i™ http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-469-5150 615-469-5151 (fax) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] Poor performance on HP Package Cluster
Title: Re: [PERFORM] Poor performance on HP Package Cluster Sure – I posted the excel spreadsheet to the list right after my message, but I think it blocks attachments. I’ll send it to you now privately. I recommend switching to software RAID 10 or 5 using simple SCSI U320 adapter(s) from LSI or Adaptec, which you can buy from HP if you must. Cheers, - Luke On 9/4/05 8:47 AM, "Ernst Einstein" <[EMAIL PROTECTED]> wrote: Hi ! Sorry, for my late answer. I was unavailable for a few days... Yes, I'm using the build-in HP Smart Array Controller. Both, the internal disks, and the external storrage are using the controller. Can you send me your test results? I'm interested in it. I've done some testing now. I've imported the data again and tuned the DB like I was told in some performance howtos. Now, the database has a good performance - until it has to read from the disks. Greetings Ernst Am Donnerstag, den 01.09.2005, 21:54 -0700 schrieb Luke Lonergan: Dan, On 9/1/05 4:02 PM, "Dan Harris" <[EMAIL PROTECTED]> wrote: > Do you have any sources for that information? I am running dual > SmartArray 6402's in my DL585 and haven't noticed anything poor about > their performance. I've previously posted comprehensive results using the 5i and 6xxx series smart arrays using software RAID, HW RAID on 3 different kernels, alongside LSI and Adaptec SCSI controllers, and an Adaptec 24xx HW RAID adapter. Results with bonnie++ and simple sequential read/write with dd. I'll post them again here for reference in the next message. Yes, the performance of the SmartArray controllers under Linux was abysmal, even when run by the labs at HP. - Luke ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] poor VACUUM performance on large tables
Jan Peterson <[EMAIL PROTECTED]> writes: > We have been experiencing poor performance of VACUUM in our production > database. Which PG version, exactly? > Everything works great until our rolling delete kicks in. Of course, > we are doing periodic VACUUMS on all tables, with frequent VACUUMs on > the more active tables. The problem arises when we start deleting the > bulk data and have to VACUUM pg_largeobject and our other larger > tables. We have seen VACUUM run for several hours (even tens of > hours). Plain VACUUM (not FULL) certainly ought not take that long. (If you're using VACUUM FULL, the answer is going to be "don't do that".) What maintenance_work_mem (or vacuum_mem in older releases) are you running it under? Can you get VACUUM VERBOSE output from some of these cases so we can see which phase(s) are eating the time? It'd also be interesting to watch the output of vmstat or local equivalent --- it might just be that your I/O capability is nearly saturated and VACUUM is pushing the system over the knee of the response curve. If so, the vacuum delay options of 8.0 would be worth experimenting with. > Statistics are also skewed during this > process and we have observed the planner choosing sequential scans on > tables where it is obvious that an index scan would be more efficient. That's really pretty hard to believe; VACUUM doesn't affect the statistics until the very end. Can you give some specifics of how the "statistics are skewed"? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
