Re: [PERFORM] tuning questions
If I understand the problem correctly, the issue is that IDE drives signal that data has been written to disk when they actually are holding the data in the write cache. In the case of a power down (and I remember someone showing some test results confirming this, check the list archive) the data in the drive write cache is lost, resulting in corrupted logs. Anyone else have more details? Jord Tanner On Thu, 2003-12-04 at 09:57, Dror Matalon wrote: On Thu, Dec 04, 2003 at 11:59:32AM -0500, Jeff wrote: On Thu, 04 Dec 2003 08:06:23 -0800 Jack Coates [EMAIL PROTECTED] wrote: testbed: dual P3 1.3 GHz box with 2GB RAM two IDE 120G drives on separate channels (DMA on), OS on one, DB on the other, some swap on each (totalling 2.8G). RH Linux 8. Side Note: be sure to turn off write caching on those disks or you may have data corruption in the event of a failure I've seen this comment several times from different people. Would someone care to explain how you would get data corruption? I thought that the whole idea of the log is to provide a journal similar to what you get in a journaling file system. In other words, the db writes a series of transactions to the log and marks that log entry (don't know the right nomeclature) as valid. When the db crashes, it reads the log, and discards the last log entry if it wasn't marked as valid, and replays any transactions that haven't been commited ot the db. The end result being that you might loose your last transaction(s) if the db crashes, but nothing ever gets corrupted. So what am I missing in this picture? Regards, Dror -- Jord Tanner [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] design question: general db performance
[small chuckle] By George, I think he's got it! You are on the right track. Have a look at this link on database normalization for more info: http://databases.about.com/library/weekly/aa080501a.htm On Tue, 2003-11-25 at 10:42, shane hill wrote: Hi folks, Disclaimer: I am relatively new to RDBMSs, so please do not laugh at me too loudly, you can laugh, just not too loudly and please do not point. :) [snip] -- Jord Tanner [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PERFORM] Dual Xeon + HW RAID question
On Tue, 2003-07-22 at 11:50, Bruce Momjian wrote: Jord Tanner wrote: On Tue, 2003-07-22 at 10:39, Bruce Momjian wrote: But CPU affinity isn't realated to hyperthreading, as far as I know. CPU affinity tries to keep processes on the same cpu in case there is still valuable info in the cpu cache. It is true that CPU affinity is designed to prevent the dump of valuable CPU cache. My thought is that if you are trying to prevent CPU contention, you could use CPU affinity to prevent 2 postmaster processes from running simultaneously on the same die. Am I out to lunch here? I've not worked with CPU affinity before, so I'm not familiar with the intimate details. I guess you could but it is the backends that use the cpu. I don't think manually specifying affinity will work for most applications. This is beating a dead horse, but I'll take one more kick at it. CPU affinity is defined by a bit mask, so multiple processors can be selected. It is also inherited by child processes, so assigning CPU 0 and CPU 2 (which I assume would be on different dies in a dual processor hyper-threading system) to the parent postmaster should prevent CPU contention with respect to the postgres backend. I would be very interested to see if any advantage could be gained by a combination of multiple HT processors and cpu affinity over multiple non-HT processors. Yet Another Performance Testing To Do (YAPTTD)! -- Jord Tanner [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] Hardware performance
On Thu, 2003-07-17 at 08:20, Adam Witney wrote: Anybody have any suggestions or experience with other hardware manufacturers for this size of setup? (2U rack, up to 6 disks, 2 processors, ~2GB RAM, if possible) Thanks adam Check out http://www.amaxit.com It is all white box stuff, but they have some really cool gear. -- Jord Tanner [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
