Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread John R Pierce
On 4/13/2016 9:12 PM, drum.lu...@gmail.com wrote: I know.. but unfortunately the bosses don't want to spend money :( Time Actually Is Money. -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscr

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread drum.lu...@gmail.com
I'm using a MASTER server and a SLAVE as read-only as well. The results I'm posting here is related to the *master* server. > We're gonna need better stats. iostat, iotop, vmstat etc will all break > down your io between reads and writes, random vs sequential etc. > I'll try to get more data du

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread Scott Marlowe
On Wed, Apr 13, 2016 at 2:43 PM, drum.lu...@gmail.com wrote: > > Hi all, > > At the moment I'm having 100% I/O during the day. My server has SATA HDs, > and it can't be changed now. > So, to solve the problem (or at least try) I was thinking about double the > RAM, and by doing that, increasing t

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread FarjadFarid(ChkNet)
/O - Increase RAM Hi all, At the moment I'm having 100% I/O during the day. My server has SATA HDs, and it can't be changed now. So, to solve the problem (or at least try) I was thinking about double the RAM, and by doing that, increasing the cache. Inline images 1 The

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread FarjadFarid(ChkNet)
: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of drum.lu...@gmail.com Sent: 13 April 2016 21:44 To: Postgres General Subject: [GENERAL] I/O - Increase RAM Hi all, At the moment I'm having 100% I/O during the day. My server has SATA HDs, and it

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread Mike Sofen
|From: John R Pierce Sent: Wednesday, April 13, 2016 1:53 PM | |On 4/13/2016 1:43 PM, drum.lu...@gmail.com wrote: |> At the moment I'm having 100% I/O during the day. My server has SATA |> HDs, and it can't be changed now. |> So, to solve the problem (or at least try) I was thinking about double |

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread Joshua D. Drake
On 04/13/2016 01:59 PM, drum.lu...@gmail.com wrote: On 14 April 2016 at 08:52, Joshua D. Drake mailto:j...@commandprompt.com>> wrote: On 04/13/2016 01:43 PM, drum.lu...@gmail.com wrote: Question: I know that might not be the best option,

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread drum.lu...@gmail.com
On 14 April 2016 at 08:52, Joshua D. Drake wrote: > On 04/13/2016 01:43 PM, drum.lu...@gmail.com wrote: > > Question: >> >> I know that might not be the best option, but by increasing the RAM and >> the CACHE would help, right? >> > > might, not necessarily would. > > > Would be nice if you could

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread John R Pierce
On 4/13/2016 1:52 PM, John R Pierce wrote: ... will speed that up is faster disks I left out faster RPM disks... faster sequential transfer speeds are generally of little impact to write-bound database servers as most of the writes are random, so its an issue of IOPS rather than MB/se

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread John R Pierce
On 4/13/2016 1:43 PM, drum.lu...@gmail.com wrote: At the moment I'm having 100% I/O during the day. My server has SATA HDs, and it can't be changed now. So, to solve the problem (or at least try) I was thinking about double the RAM, and by doing that, increasing the cache. depends on if its r

Re: [GENERAL] I/O - Increase RAM

2016-04-13 Thread Joshua D. Drake
On 04/13/2016 01:43 PM, drum.lu...@gmail.com wrote: Question: I know that might not be the best option, but by increasing the RAM and the CACHE would help, right? might, not necessarily would. JD -- Command Prompt, Inc. http://the.postgres.company/ +

[GENERAL] I/O - Increase RAM

2016-04-13 Thread drum.lu...@gmail.com
Hi all, At the moment I'm having 100% I/O during the day. My server has SATA HDs, and it can't be changed now. So, to solve the problem (or at least try) I was thinking about double the RAM, and by doing that, increasing the cache. [image: Inline images 1] The server has 128GB today: shared_buf