Re: New server setup
От | John Lister |
---|---|
Тема | Re: New server setup |
Дата | |
Msg-id | 5140A623.20005@kickstone.com обсуждение исходный текст |
Ответ на | Re: New server setup (Greg Jaskiewicz <gryzman@gmail.com>) |
Ответы |
Re: New server setup
|
Список | pgsql-performance |
On 13/03/2013 15:50, Greg Jaskiewicz wrote: > SSDs have much shorter life then spinning drives, so what do you do when one inevitably fails in your system ? Define much shorter? I accept they have a limited no of writes, but that depends on load. You can actively monitor the drives "health" level in terms of wear using smart and it is relatively straightforward to calculate an estimate of life based on average use and for me that works out at about in excess of 5 years. Experience tells me that spinning drives have a habit of failing in that time frame as well :( and in 5 years I'll be replacing the server probably. I also overprovisioned the drives by about an extra 13% giving me 20% spare capacity when adding in the 7% manufacturer spare space - given this currently my drives have written about 4TB of data each and show 0% wear, this is for 160GB drives. I actively monitor the wear level and plan to replace the drives when they get low. For a comparison of write levels see http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm, it shows for the 320series that it reported to have hit the wear limit at 190TB (for a drive 1/4 the size of mine) but actually managed nearer 700TB before the drive failed. I've mixed 2 different manufacturers in my raid 10 pairs to mitigate against both pairs failing at the same time either due to a firmware bug or being full In addition when I was setting the box up I did some performance testing against the drives but with using different combinations for each test - the aim here is to pre-load each drive differently to prevent them failing when full simultaneously. If you do go for raid 10 make sure to have a power fail endurance, ie capacitor or battery on the drive. John
В списке pgsql-performance по дате отправления: