Re: R: [GENERAL] DB on mSATA SSD

Additional things to consider for decreasing pressure on the cheap drives: - Another configuration parameter to look into is effective_io_concurrency. For SSD we typically set it to 1 io per channel of controller card not including the RAID parity drives. If you decrease this value Po

Re: R: [GENERAL] DB on mSATA SSD

On 4/23/15 8:36 AM, Job wrote: Hello, thank you first of all for your wonder help! Tomas, regarding: There are ways to make the writes less frequent, both at the database and OS level. We don't know what's your PostgreSQL config, but making the checkpoints less frequent and tuning the kernel/m

Re: R: [GENERAL] DB on mSATA SSD

On 04/23/15 15:36, Job wrote: Hello, thank you first of all for your wonder help! Tomas, regarding: There are ways to make the writes less frequent, both at the database and OS level. We don't know what's your PostgreSQL config, but making the checkpoints less frequent and tuning the kernel/

Re: [GENERAL] DB on mSATA SSD

On Thu, Apr 23, 2015 at 9:36 AM, Job wrote: > We have a table, about 500Mb, that is updated and written every day. > When machines updates, table is truncated and then re-populated with > pg_bulk. > But i think we strongly writes when importing new data tables.. > so this is static data you upda

R: [GENERAL] DB on mSATA SSD

Hello, thank you first of all for your wonder help! Tomas, regarding: >There are ways to make the writes less frequent, both at the database >and OS level. We don't know what's your PostgreSQL config, but making >the checkpoints less frequent and tuning the kernel/mount options may >help a lot.

Re: [GENERAL] DB on mSATA SSD

On 04/23/15 13:07, Job wrote: Dear Postgresql mailing list, we use Postgresql 8.4.x on our Linux firewall distribution. Actually, we are moving from standard SATA disk to mSATA SSD solid drive, and we noticed that the DB, using lots of indexes, is writing a lot. In some monthes, two test machin

Re: [GENERAL] DB on mSATA SSD

Hi On 04/23/15 14:50, Chris Mair wrote: Dear Postgresql mailing list, we use Postgresql 8.4.x on our Linux firewall distribution. Actually, we are moving from standard SATA disk to mSATA SSD solid drive, and we noticed that the DB, using lots of indexes, is writing a lot. In some monthes, tw

Re: [GENERAL] DB on mSATA SSD

On 23/04/2015 15:28, Vick Khera wrote: On Thu, Apr 23, 2015 at 7:07 AM, Job mailto:j...@colliniconsulting.it>> wrote: Are there some suggestions with SSD drives? Putting the DB into RAM and backing up periodically to disk is a valid solutions? I have some very busy databases on SSD-o

Re: [GENERAL] DB on mSATA SSD

Hi, On 04/23/15 14:33, John McKown wrote: ​That's a really old release. But I finally found some doc on it. And 8.4 does appear to have TABLESPACEs in it. http://www.postgresql.org/docs/8.4/static/manage-ag-tablespaces.html To define a tablespace, use the CREATE TABLESPACE

Re: [GENERAL] DB on mSATA SSD

> Dear Postgresql mailing list, > > we use Postgresql 8.4.x on our Linux firewall distribution. > Actually, we are moving from standard SATA disk to mSATA SSD solid drive, and > we noticed that the DB, using lots of indexes, is writing a lot. > > In some monthes, two test machine got SSD broken,

Re: [GENERAL] DB on mSATA SSD

On Thu, Apr 23, 2015 at 6:07 AM, Job wrote: > Dear Postgresql mailing list, > > we use Postgresql 8.4.x on our Linux firewall distribution. > Actually, we are moving from standard SATA disk to mSATA SSD solid drive, > and we noticed that the DB, using lots of indexes, is writing a lot. > > In som

Re: [GENERAL] DB on mSATA SSD

On Thu, Apr 23, 2015 at 7:07 AM, Job wrote: > Are there some suggestions with SSD drives? > Putting the DB into RAM and backing up periodically to disk is a valid > solutions? > I have some very busy databases on SSD-only systems. I think you're using SSDs that are not rated for server use. You

[GENERAL] DB on mSATA SSD

Dear Postgresql mailing list, we use Postgresql 8.4.x on our Linux firewall distribution. Actually, we are moving from standard SATA disk to mSATA SSD solid drive, and we noticed that the DB, using lots of indexes, is writing a lot. In some monthes, two test machine got SSD broken, and we are st