Re: [PERFORM] Tips Tricks for validating hardware/os
You forgot pulling some RAID drives at random times to see how the hardware deals with the fact. And how it deals with the rebuild afterwards. (Many RAID solutions leave you with worst of both worlds, taking longer to rebuild than a restore from backup would take, while at the same ime providing a disc IO performance that is SO bad that the server becomes useless during the rebuild) Andreas -- Ursprüngl. Mitteil. -- Betreff:Re: [PERFORM] Tips Tricks for validating hardware/os Von:Greg Smith [EMAIL PROTECTED] Datum: 23.05.2007 05:15 On Tue, 22 May 2007, Stephane Bailliez wrote: Out of curiosity, can anyone share his tips tricks to validate a machine before labelling it as 'ready to use postgres - you probably won't trash my data today' ? Write a little script that runs pgbench in a loop forever. Set your shared_buffer cache to use at least 50% of the memory in the machine, and adjust the database size and concurrent clients so it's generating a substantial amount of disk I/O and using a fair amount of the CPU. Install the script so that it executes on system startup, like adding it to rc.local Put the machine close to your desk. Every time you walk by it, kill the power and then start it back up. This will give you a mix of long overnight runs with no interruption to stress the overall system, with a nice dose of recovery trauma. Skim the Postgres and OS log files every day. Do that for a week, if it's still running your data should be safe under real conditions. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate ---(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] Tips Tricks for validating hardware/os
On Tue, 22 May 2007, Stephane Bailliez wrote: Out of curiosity, can anyone share his tips tricks to validate a machine before labelling it as 'ready to use postgres - you probably won't trash my data today' ? Write a little script that runs pgbench in a loop forever. Set your shared_buffer cache to use at least 50% of the memory in the machine, and adjust the database size and concurrent clients so it's generating a substantial amount of disk I/O and using a fair amount of the CPU. Install the script so that it executes on system startup, like adding it to rc.local Put the machine close to your desk. Every time you walk by it, kill the power and then start it back up. This will give you a mix of long overnight runs with no interruption to stress the overall system, with a nice dose of recovery trauma. Skim the Postgres and OS log files every day. Do that for a week, if it's still running your data should be safe under real conditions. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PERFORM] Tips Tricks for validating hardware/os
On May 23, 2007, at 2:32 AM, Andreas Kostyrka wrote: You forgot pulling some RAID drives at random times to see how the hardware deals with the fact. And how it deals with the rebuild afterwards. (Many RAID solutions leave you with worst of both worlds, taking longer to rebuild than a restore from backup would take, while at the same ime providing a disc IO performance that is SO bad that the server becomes useless during the rebuild) *cough* adaptec *cough* :-( ---(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
[PERFORM] Tips Tricks for validating hardware/os
Hi, Out of curiosity, can anyone share his tips tricks to validate a machine before labelling it as 'ready to use postgres - you probably won't trash my data today' ? I'm looking for a way to stress test components especially kernel/disk to have confidence 0 that I can use postgres on top of it. Any secret trick is welcome (beside the memtest one :) Thanks ! -- stephane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PERFORM] Tips Tricks for validating hardware/os
On 5/22/07, Stephane Bailliez [EMAIL PROTECTED] wrote: Out of curiosity, can anyone share his tips tricks to validate a machine before labelling it as 'ready to use postgres - you probably won't trash my data today' ? I'm looking for a way to stress test components especially kernel/disk to have confidence 0 that I can use postgres on top of it. Any secret trick is welcome (beside the memtest one :) Compile the Linux kernel -- it's a pretty decent stress test. You could run pgbench, which comes with PostgreSQL (as part of the contrib package). Give a database size that's larger than the amount of physical memory in the box. 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] Tips Tricks for validating hardware/os
Out of curiosity, can anyone share his tips tricks to validate a machine before labelling it as 'ready to use postgres - you probably won't trash my data today' ? I'm looking for a way to stress test components especially kernel/disk to have confidence 0 that I can use postgres on top of it. That would be running a filesystem benchmark, pulling the plug, then counting the dead. http://sr5tech.com/write_back_cache_experiments.htm ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
