Re: [PERFORM] FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950
Joseph wrote: > We just got a DELL POWEREDGE 2950. So I was tasked with putting > Linux Redhat and dumped our software/packages on it. Contrary to > common sense, I didn't bother reading the manuals that came with te > 2950. I went right ahead and installed Redhat server on it, then went > and loaded the backups software/data etc onto it and started having > the team use it. And this has to do with pgsql.performance exactly what? Anyway, as someone who seems to administrates a PostgreSQL production box, you sure have a good backup plan. So just call DELL's support, fix you RAID and restore form backup. >From the DELL site it seems this `PERC 5/i' on board controller (assuming that's what you have) doesn't even have a BBU. If you don't plan to post here in a few weeks again about data corruption, go out and shop a serious controller. And before you move that box in production, check: Is my hardware and software setup fsync/fua clean? Is my backup plan working? -- Best regards, Hannes Dorbath ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950
On Sat, Jul 14, 2007 at 10:29:05AM +0200, Hannes Dorbath wrote: > From the DELL site it seems this `PERC 5/i' on board controller > (assuming that's what you have) doesn't even have a BBU. If you don't > plan to post here in a few weeks again about data corruption, go out and > shop a serious controller. We have a 2950 with a PERC, and it has a BBU. /* Steinar */ -- Homepage: http://www.sesse.net/ ---(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] FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950
"Hannes Dorbath" <[EMAIL PROTECTED]> writes: > From the DELL site it seems this `PERC 5/i' on board controller > (assuming that's what you have) doesn't even have a BBU. If you don't > plan to post here in a few weeks again about data corruption, go out and > shop a serious controller. This is a bit of a strange comment. A BBU will improve performance but Postgres doesn't require one to guarantee data integrity. If your drives have write caching disabled (ie write-through) and your controller does write-through caching and you leave fsync=on and full_page_writes=on which is the default then you shouldn't have any data integrity issues. Note that many drives, especially IDE drives ship with write caching enabled (ie, write-back). And without a BBU many people are tempted to set fsync=off which improves performance at the cost of data loss on a system crash or power failure. With a BBU there's no advantage to fsync=off so that temptation to risk data loss is removed. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(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] FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950
Gregory Stark wrote: >> From the DELL site it seems this `PERC 5/i' on board controller >> (assuming that's what you have) doesn't even have a BBU. If you don't >> plan to post here in a few weeks again about data corruption, go out and >> shop a serious controller. > > This is a bit of a strange comment. A BBU will improve performance but > Postgres doesn't require one to guarantee data integrity. > > If your drives have write caching disabled (ie write-through) and your > controller does write-through caching and you leave fsync=on and > full_page_writes=on which is the default then you shouldn't have any data > integrity issues. That was my point, controllers without BBU usually leave drive caches turned on, as with drive caches off performance would be unbearable bad. -- Best regards, Hannes Dorbath ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PERFORM] Vacuum full considered useful ;)
Hi, Something I'd like to share. I switched to postgres about 4 months ago. The perfomance after a while got worse. I posted a message here, where the result was that my IO was the problem. I run vacuum every night. I never used vacuum full because it is not explicitly recommended and I read somewhere in the archives a mail that the consistency of the db suffered after a vacuum full run. Yesterday I switched from 8.1 to 8.2. So I needed to dump the dbase and reimport it. The dbase after 4 months of running without "vacuum full" reached 60 gigabyte of diskspace. Now after a fresh import it only has 5 gigabyte! No wonder, I got IO problems with such a fragmentation. For people not very familiar with postgres especially those coming from mysql, i'd recommend paying attention to this. regards, patric de waha ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] Vacuum full considered useful ;)
No wonder, I got IO problems with such a fragmentation. For people not very familiar with postgres especially those coming from mysql, i'd recommend paying attention to this. Definitely. The problem here is that you just aren't vacuuming enough, not that you didn't vacuum full. I would suggest reviewing autovacuum and seeing if that will help you. Joshua D. Drake regards, patric de waha ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] Vacuum full considered useful ;)
Patric de Waha <[EMAIL PROTECTED]> writes: > Yesterday I switched from 8.1 to 8.2. So I needed to dump the dbase > and reimport it. The dbase after 4 months of running without "vacuum > full" > reached 60 gigabyte of diskspace. Now after a fresh import it only > has 5 gigabyte! > No wonder, I got IO problems with such a fragmentation. Indeed, but routine VACUUM FULL is not the best answer. What this suggests is that you don't have the FSM size (max_fsm_pages and possibly max_fsm_relations) set high enough for your DB size. If it isn't big enough then you'll "leak" reusable space over time. Also, if you are using manual rather than autovacuum you might need to be vacuuming more often. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] Vacuum full considered useful ;)
Joshua D. Drake a écrit : No wonder, I got IO problems with such a fragmentation. For people not very familiar with postgres especially those coming from mysql, i'd recommend paying attention to this. Definitely. The problem here is that you just aren't vacuuming enough, not that you didn't vacuum full. I would suggest reviewing autovacuum and seeing if that will help you. And paying attention to the max_fsm_pages setting. A value too low won't help vacuum's work. Regards. -- Guillaume. http://www.postgresqlfr.org http://docs.postgresqlfr.org ---(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] Vacuum full considered useful ;)
On Jul 14, 2007, at 11:50 AM, Patric de Waha wrote: Yesterday I switched from 8.1 to 8.2. So I needed to dump the dbase and reimport it. The dbase after 4 months of running without "vacuum full" reached 60 gigabyte of diskspace. Now after a fresh import it only has 5 gigabyte! After a couple more months running 8.2, compare your index sizes to what they are now relative to the table sizes. My bet is that if you just reindexed some of your tables that would have cleared out much of that bloat. A short while back I reindexed some tables on my primary production server and shaved off about 20Gb of disk space. The table itself was not bloated. A dump/reload to another server resulted in a table of roughly the same size. ---(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
