Milyen SSD xen dom0 alá?

 ( Proci85 | 2017. január 11., szerda - 13:20 )

Sziasztok

Eddig 250-320GB-s WD RE2, RE3 diszkeket használtam XenServer rendszer alá RAID1-ben. Kezdenek kiöregedni, szép 50-60 ezer üzemórát megéltek.
Feleslegesnek érzem, hogy 1TB WD RE4-re cseréljem, mivel default install 4GB a root, ezt szoktam 20GB-re felhúzni és bőven elég.
Kinek mi a tapasztalata? SSD-k elmennek már ennyi ideig? Korábban Kingstonnál láttam kis ~30GB-s méretű MLC-s SSD-ket ~10.000 Ft-ért. Ezek kifejezetten ilyen céllal léteznek? Na ezekből már csak mSATA-t látok.
Esetleg más alternatíva?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Az új xenserver 7 ben már 64G vagy több a root defaultban :>

Fedora 25, Thinkpad x220

Köszi, ez hasznos infó. És ki is használja? :) Jobbára a logok miatt kellett a 4GB-t növelnem.

Nem tudom, eddig fontos helyeken 6.5 megy, egy test 7-es fut, az 6.5 ből lett upgradelve, így maradtak a partícíók.

Fedora 25, Thinkpad x220

FYI: tudsz ugy upgradelni, hogy az uj particiokiosztast kapja

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Jó kérdés, nem foglalkoztam vele, mivel logszerverre mennek a logok, elég az az 1-2G is :>

Fedora 25, Thinkpad x220

ja nem kerdes, kijelentes, lehet ugy :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Samsung 850 Pro, jelenleg a legstrapabirobb elerheto aru SSD a piacon szerintem.

+1

-1. Bár papíron 0,3 drive write/day-t tud, valójában ennek a felénél is képes durván lelassulni, még akkor is, ha fenntartasz rajta 7-10%-ot overprovisionnek. Mi annakidején vettünk egy csomót, aztán megváltás volt lecserélni őket Intelre.
(DC S35xx sorozat: 0,3 DWPD, DC S36xx sorozat: 3 DWPD, DC S37xx sorozat: 10 DWPD)

a 3500-as szériát nem is mondanám drágának

ezt hogy kell érteni? ha sokat írsz rá akkor belassul attól függetlenül hogy mennyi adat van rajta?

Az SSD csak akkor tudja, hogy mennyi hasznos adat van rajta, ha törléskor trimmeled a felszabaduló területet. A trim nem minden szoftver/hardver környezetben lehetséges. Ekkor az első teleírástól számítva az SSD mindig "tele van", akkor is, ha számodra nincs rajta hasznos adat.

Az SSD firmware próbálja optimalizálni az írást, és a cellák írásciklusát. Ezen segít a trim, az overprovisioning, és persze a firmware "minősége".

Nálunk a fejlesztőknek némi SQL bazgerálással, automatizált build projektekkel nagyjából 2 hét alatt sikerült úgy leültetni a 850 Pro-kat, hogy utána kb. 20 MByte/sec-kel volt hajlandó írni, és egy sima 500 MByte-os fájl átmásolása 20-as loadot okozott az iowait miatt. Ilyenkor, ha teljesen kiürítettük az SSD-t, és Samsung magician-ból toltunk rá egy teljes trim-et, akkor utána ismét ment az eredeti sebességével - kb. újabb két hétig.

Aztán meguntuk, és vettünk Intel DC S3610-eket, és darab-darab kicseréltük őket. Azóta közel két éve mennek, és _semmi_ észrevehető lassulás sincs azóta sem, az írási teljesítmény megegyezik a nullkilométeres korukkal.

A 850 Pro mezei desktop gépbe jó, ahol elenyésző írási mennyiség van.

és mi a helyzet ha a particiókat már alapból úgy hozod létre hogy hagysz az ssd-n 10%-ot?

Mi az 512GB-os 850 Pro-kból készített RAID1-re 480GB-os partíciót hoztunk létre. Lehet, hogy 400GB fölé nem lett volna szabad menni.

Mindegy, nem személyautóval kell aratni, és kombájnnal közértbe menni. A 850 Pro remek desktopba, viszont munkaállomásba és szerverbe pedig meg kell venni legalább az S3510-et. Annyival nem drágább, mint amennyivel többet ad.

az intelek még így is 2x annyiba kerülnek:) én amúgy evokat használok raid10-ben, de nincs performancia gondom velük, mondjuk annyira nincs is sok írás rajtuk. nem lehet amúgy hogy amit te mondasz az valamilyen firmware gond volt?

Az akkor elérhető legújabb firmware volt benne. Nem álltunk neki reverse engineering-gel megfejteni, vagy új firmware-t írni bele. A használati értéke akkor és ott nem ütötte meg a feladathoz szükséges, elvárt mértéket.

+1
Teljesen ismerősek a szimptómák. Mi 840 Pro-val tapasztaltuk ugyanezt, IBM blade-ekben, ahol az LSI SAS controllerre (SATA compatibility módban) voltak rákötve. Az LSI-n valamiért a trim nem ment át, viszonylag sokféle ötletet kipróbáltunk, de nem segített. Jenkins slave-ek voltak rárakva, buildelés nyilván eléggé megtekeri random írással. 25% overprovisioning-et állítottunk be (particionálással, a címtartomány végére így soha nem került egyetlen írásművelet sem).

Eleinte nagyon jó volt a teljesítményük, de idővel vállalhatatlan szintre belassultak és hatalmas load-ot csináltak a szerveren. Ha kivettük a szerverből és desktop gépben megtrimmeltük (hdparm-mal), akkor egy darabig megint jó volt, aztán idővel újra leromlott. Másrészt write amplification is az egekig felment, volt olyan példány, ami 2 hét alatt kb 2000 teljes írási ciklust szedett össze - közel sem volt ennyire meghajtva. Ez a SMART szerint a névleges élettartam kb 40%-a.

Mikor kínunkban visszaraktuk a mechanikus SAS diszkeket, nagyságrendeket gyorsultak a build futások és rögtön eltűntek a nagy load-ok.

Annyi bizonyos, hogy a Samsungok nagyon rosszul viselik a trim hiányát és ezen az overprovisioning sem segít, talán max késlelteti a probléma megjelenését.
---
Régóta vágyok én, az androidok mezonkincsére már!

Nálunk 850 Evo raid1 és btrfs esetén lassult be nagyon és nagyon magas volt az io is.
Visszaállítottam raid1 és ext4 és se lassulás, se magas io azóta nincs.
Virtuális gépek mennek rajta és adatbázis is van.

Nalam 2db regebbi (emlekeim szerint) evo, megy raid1-ben egy postgres alatt, tobb mint 1 eve, no problem :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Meglátjuk. Tavaly májusban 2db 850 EVO-t raktunk a monitorozó szerverbe, kb júluisban mindkettő kihalt.
Azóta 850 PRO-k mennek benne. Eddig jónak tűnik. A szerveren nagyrészt csak írás történik.

Fedora 25, Thinkpad x220

EVO meg a PRO tök más cuccokat használ, semmi közük egymáshoz.