Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 20/12/12 23:43, Felix Frank wrote: > Thanks, James, you seem to keep forgetting the list CC though ;) > > -------- Original Message -------- > Subject: Re: [DRBD-user] Secondary Performance > Date: Thu, 20 Dec 2012 11:40:27 +0000 > From: Prater, James K. <jprater at draper.com> > To: 'ff at mpexnet.de' <ff at mpexnet.de> > > What Felix suggested (switching roles) should work. Personally, I > would not use SSDs for that type of deploy. It is best placed to speed > up certain processes (swap, scratch pad database location used for > indexes or anythi > I think your message was truncated, but I was of the understanding that SSD's were perfect for random I/O performance, which essentially is what a bunch of VM's do. With the performance I was getting when the primary was using a 2 disk RAID1, I either needed to move to a 6 or even 8 disk RAID10, or else move to SSD's. The linux-raid list seemed to agree that SSD would provide the best performance/etc, the trade-off was of course, cost. Also the suggestion against "consumer grade" SSD's (which I did ignore). So far, the SSD solution on the primary has produced the desired result and is working well, but spending the same cash on the secondary isn't an option at the moment, so I'm doing my best to find a low-cost solution. Currently, with the secondary "falling behind" about 40 or so times per day, it could be considered "acceptable", but I'm a little concerned about reliability. If that's the best I can get, then so be it, but if I can reduce that to less than 5 times per day by increasing some buffering/value somewhere, then I'd be a lot happier. Regards, Adam -- Adam Goryachev Website Managers www.websitemanagers.com.au