SSD mint swap

Linux-kezdő

Hello

lehet hogy csak hülye ötlet...
Be lehet e állítani úgy a swap -ot hogy csak file rendszert kesseljen
és ne akarjon oda futó programokat is kimenteni

arra gondoltam hogy egy ssd hdd -t alkalmazni
linux swap területnek (vagy második swap -nek),
így a file rendszer sebessége megnőhetne
a sima winyók használtsága meg jelentősen csökkenne
ezek az új ssd -k már 160 mb -al tudnak olvasni így
majdnem olyan lenne mintha ugyanannyi ram lenne benne

szerintetek hülye ötlet ?

  • 3383 megtekintés

( Frantique v | 2009. 04. 15., sze – 08:28 )

Ki kell próbálni. :) Elméletileg mehet a dolog, miért ne? Oda csinálod a swapot, ahova akarod. Elvileg még ramdiskre is, ha nem lenne nonszensz. :D
--
Coding for fun. ;)

( zwei | 2009. 04. 15., sze – 08:34 )

Alapjában vévle nem hülye ötlet, vannak olyan storage appliance-ok, amik hasonlóan működnek, pl. a Sun "unified Storage" rendszere. Igaz, ott nem swap terület van SSD-n, hanem a file rendszer (zfs) intent logja, illetve olvasásra vagy írásra optimalizált SSD-k vannak benne cache-nek.

Viszont a swap kihelyezése ssd-re önmagában szerintem nem gyorsít semmit, max. akkor, ha túl kevés RAM van a gépben és intenzíven page-el az oprendszer. Ez esetben viszont pár GB extra ram sokkal olcsóbb, és jobb hatásfokú, mint az SSD.

Egyébként ha már swap-el a rendszer (nem összekeverendő a pageing-el), az rég rossz, és a memória bővítése az egyetlen használható megoldás.

Köszi a válaszokat

örülök hogy nem is hülyeség :)
ezért ha lehet le akarom harcolni ezt a kérdést
bármilyen megoldás érdekelne

Valahogy rá lehet venni a linux ot hogy egy ssd re kesselje a file rendszert?
Nem biztos hogy a swap a megoldás, lehet bármilyen más trükk is
kb olyan lenne mint egy proxy, vagy egy apache disk cache.

Szerintem meg az lenne a jó, ha nem a szakszavakat dobálnád egymás után véletlen sorrendben, hanem terminus technicusok nélkül megfogalmaznád, hogy mit akarsz. Ha fájlrendszer műveleteket akarsz gyorsítani, akkor
- csinálj RAM-diszket
- konfigurálj nagyon buffer cache-t a kernelbe
(ez a kettő kb egymás ellentéte :-) )

Ha meg a swap-pelést akarod gyorsítani, akkor természetesen rakhatod SSD-re is akár a swap-et. Felteszem diszknek látszik, akkor semmi akadálya "mkswap /dev/SSD" -t és "swapon /dev/SSD" -t mondani.

És vedd figyelembe zwei két utolsó bekezdését is, ne csak az elsőt!

( Foltos | 2009. 04. 15., sze – 09:17 )

Hali!

Azert en utanan neznek hany iras utan megy tonkre egy szektor az SSD -ben. Pl. SD kartyaknal szoktak eloadni, hogy csak az elejen van rendes wear leveling mondvan, hogy a FAT ugy is gyakrabban irodik mint mas teruletek, es wear leveling nelkul gyorsabb a mukodes. Ja, ha esetleg nem FAT -et teszel ra es nem a kartya elejere esnek a gyakran irt szektorok akkor szivacs. Sokkal hamarabb megy tonkre a kartya mint FAT -tal.
Szoval erdemes megnezni milyen FLASH alapu cuccot veszel mielott iras igenyes feladatra kezdened hasznalni.

Jelenleg, ha jól tudom kb 10 000 írás-törlés cikus egy átlagos SSD cella élettartama.
A modern ssd-kben beépítenek olyan eljárást, ami a cellák egyenletes használatát teszi lehetővé.

Egy konkrét példa: az Intel X25-M tipusú SSD-jének napi kb 100GB írása mellett is több mint 5 év az élettartama. Ennyi idő alatt meg álltalában az egész gépet lecserélik.

Hát ezaz, csak sajnos nem minden SSD Intel. Sokkal ocsmányabb SSD kontrollerek is vannak forgalomban nagy számban. Lásd: rant a JMicron vezérlőkről: http://anandtech.com/storage/showdoc.aspx?i=3531 És ez itt csak teljesítményprobléma, a megbízhatóságot még senki sem tesztelte le komolyan, de az Intel valamiért elég nagy pofával hirdeti, hogy az ő wear levellingje hány nagyságrenddel jobb a többiekéhez képest. Ha jmicron vezérlője a wear levellinget is olyan jól oldja meg, mint a random írásokat (és az a baj, hogy van rá esély, hogy a random írások pont a buta wear levelling miatt olyan lassúak), akkor én azért félnék tőle.
---
Linux is bad juju.

Ebből ugyanúgy, mint bármi másból lehet venni minőséget és szart is.
Ha fontos, hogy a tervezett élettartamig tuti kibírja, akkor lehet venni jót. Komolyabb storage cuccokba épített SSD-k kicsit drágábbak (5-10x) mint a legolcsóbb notebookba valók. Talán az élettartam az egyik oka.

Szerintem egyébként nincs probléma azzal, ha pl. egy gyártó csak 1 éves élettartamot garantál. A probléma ott van, ha valaki lelkes amatőr ezt 5 évig "tervezi" használni.

( LGee | 2009. 04. 15., sze – 09:23 )

Kicsit mas: szerintem meg az lenne kiraly, ha a laptopokban az expresscard slot bootolhato lenne, es oda be lehetne tenni egy kisebb ssd-t (4-8GB) csak az os-nek, a tobbi meg opcionalisan lehetne egy nagyobb diszken.

( barii | 2009. 04. 15., sze – 09:32 )

de nem is értem. a swap akkor kerül használatba, ha elfogy a RAM. Mennyi ram van abban a gépben? mert hát a ram olcsobb mint az SSD

Nem csak.
A kernel különféle algoritmusok alapján folyamatosan ellenörzi a memóriát, és a régebben használt lapokat kirakja a swap területre. (Ezt nevezik page-ingnek.)
Ha elfogy a RAM, akkor először csak felgyorsul a szabad lap keresése, és egyre aggresszívebben kerülnek ki a lapok a swap-re.
A legvégső eset a swap-ing, amikor komplett processzek teljes memóriaterülete megy ki swap-ra.
Ilyenkor az oprendszer álltalában már használhatatlanul belassul.

Tévedés, hogy az SSD drágább mint a RAM.
Egy 60GB-s SSDt kicsit több mint 50000Ft-ért megkapsz. Ugyanez DDRII memóriából több mint 100,000 Ft-ba kerülne. Tény, hogy a memóriát kisebb egységekben lehet vásárolni, mint az SSD-t, de ettől még nem olcsóbb a GB-nkénti költsége.

Persze egy átlagos otthoni szerver esetén abszolute igazad van, már 4GB memória is nagyon jó cache gyorsító.
Viszont, ha pl. egy file szervert nézel, 10-20TB kapacitással, akkor ott már 100Gb-s nagyságrendű cache szükséges az észrevehető gyorsításhoz. Ekkora méretben az SSD viszont jóval olcsóbb. Arról nem is beszélve, hogy amíg a memória DIMM-ek száma korlátozott, az SSD-ből annyit tudsz beletolni, amennyit csak meg tud címezni az oprendszered.

Hello

pontosan rávilágítottál a problémámra
sajnos nem tudok 100gb memóriát beledugni egy alaplapba sem,
vagy csak abba ami annyiba kerül hogy nem is tudok addig elszámolni

valóban file szerver lenne
igazából egy központi storage
ami nfs el fel mountolva 3 másik szerverre
kb 10-20 mb/sec el töltenének róla reggel 8 tol éjfélig
ez már az amit egy sima sata2 raid1 0-24 ben nem bír ki hosszú távon (tapasztalat)
de egy 64 mb os falsh al megspékelve már szerintem elég tűrhető lenne

jelenleg úgy üzemel hogy egy raid1 tömbben 4 winyó van tükörben
így a processzor iowait már nem vészes
két winyónál közel 100% volt az iowait és
5mb/sec nél nem tudtunk többet kipréselni
a sok random olvasás miatt
plusz 6 hónap alatt kipusztultak a winyók

na ez ügyben kellene okosítani valamit

Sokkal nagyobb I/O teljesítményt kapsz, ha minnél több diszkre kened szét az adataidat.
Ha az olvasás dominál, akkor lehet, hogy jobban jársz 5-10 db. RAID5-be szervezett diszkkel.
Ha a RAID5 tömb ép, akkor nagyon jó olvasási teljesítményt ad. Viszont ha elhal benne egy diszk, akkor a teljesítmény romlik. (Ezért célszerű hot spare-t is konfigurálni, hogy minnél rövidebb ideig legyen a tömb sérült.)

Vagy egy 4 lábú raid1 helyett egy 4 diszkes raid1+0-val is próbálkozhatsz. (Összetükrözöl 2-2 diszket, és ezeket stripe-ba fűzöd). Az olvasáson kevésbé segít, viszont ha néha írás is van, az nem fogja meg egyszerre a 4 diszket.

Némi gyorsítást lehet elérni, pl. 10 000RPM-es diszkek használatával is.

Ha már ekkora I/O igénye van a környezetnek, akkor nem biztos, hogy a saját gyártású "diszkalrendszer" túl jó megoldás.
Viszonylag olcsón (pár 100 000 Ft-ért) már kaphatók JBOD storage-ek, amikbe 10-15 diszk (SATA/SAS) belepakolható. Ezek host oldali BBWC-vel kombinálva már tűrhető teljesítményt adnak.

ez a majdnem ugyanolyan jo olvasasra jol hangzik csak mondjuk irasra mar eleg gyaszos. Netto kapacitas problemat sztem nem azzal fogjuk megoldani h raid5ot hasznalunk.

a tapasztalat az h mivel a gyartok az olcsobb termekvonalon elmentek szoftverraid iranyba ezert nem szivesen hasznalok raid5ot hacsak nem szeretnem h ezen matekozzon mikozben adatabazis muveletek vannak

nyilvan a felsokategorias eszkozoknel mashogy van de ott mar nem ritka a 50-100 hdd se, nemtom mennyit lehet 1 tombbe fuzni max, ahol ugye kicsit mas raid5olni mint az alant hupperkedo altal emlitett 3 vinyos megoldas

--
.

"Netto kapacitas problemat sztem nem azzal fogjuk megoldani h raid5ot hasznalunk."

Hát sok helyen ez a kb +30% hely több százezer (néha millió) forintot jelent.

"a tapasztalat az h mivel a gyartok az olcsobb termekvonalon elmentek szoftverraid iranyba ezert nem szivesen hasznalok raid5ot hacsak nem szeretnem h ezen matekozzon mikozben adatabazis muveletek vannak"

Amit írsz,abban igazad van, de egy technológia attól még nem szar, hogy a megvalósítására használt eszközök azok.
Asszem valahol írtam én is, hogy raid5-öt szoftver raidként nem
érdemes használni.

Akinek nagyobb teljesítmény kell, az nyúljon a zsebébe, vegyen normális vasat, és ne sufnituning szarokban gondolkodjon.

hat nem tom valahogy nem all ossze a kep.

1M huf az nem tul nagy osszeg egy kozepes meretu ceg eleteben.

de meg mindig alitom h nem a konyvelo fogja megmondani h mi mehet adott szerver ala hanem a mernok, nem tom nalatok hogy van :)

(raid 5 normalis vezerlovel es sok vinyovel is alkalmatlan lehet adott feladatra, problema -> megoldas iranyba erdemes gondolkodni sztem)

--
.

En ilyent nem allitottam, de azert olyan jo, hogy ilyen orakulumok mint te, azt is beleolvasnak egy kommentbe, ami sosem volt benne.

Kulonben meg a RAID 5 nyujt szerintem akkora adatbiztonsagot 3 winyon, mint a te istenitett RAID10-ed 4 winyon. Az olvasasi teljesitmeny meg legalabb ugyanolyan jo kell legyen, hiszen az olvasashoz nem szukseges feltetlen a paritasbit hasznalata, a XOR muvelet elvegezheto barmely ket winyo bajtjai kozt.

Ja, es baromi jo, hogy a pontos feladat specifikaciojat nelkulozven is tudsz latatlanba sebesseget meg adatbiztonsagot tervezni. Tenyleg egy orakulum veszett el benned. De nagyon.

De koszonom, igazad van, egy hulye okor allat vagyok. Leulhetsz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ez nem buffercache oldalon lesz elsősorban problémás, hanem fizikai diszk I/O-ban. Ahogy előttem is írták, sok diszkre szórd szét az adatokat (raid 10 vagy raid50), azaz lehetőleg kis kapacitású, gyorsan pörgő, esetleg fizikailag is kicsi (2.5") diszkeket használj -- minél több és kisebb diszked lesz, annál jobb. Ja, és persze a normális vezérlő(ke)t se felejtsd ki a számításból -- itt is hirdetett valaki sas/sata raid kártyát kábellel (talán négy diszk/kártya) -- lehetőleg elemmel/aksival védett írási cache-sel (bbwc).

( prygme | 2009. 04. 15., sze – 16:58 )

igen hülye ölet! az SSD driveok általában flash chipeket használnak, ezeknek pedig korlátozott az újraírhatósága.
vannak olyan típusok, amelyeknél ez az érték csak 100ezer, ami saját adatok pl képek/filmek/zenék/dokumentumok esetében bőven elég, de swap esetében már nem. vannak olyan ssdk, amelyik DRam chipeket használnak és csak backupként használnak flash chipeket arra az esetre, ha megszűnik az SSD drive áramellátása, pl kikapcsolják a computert amiben van. ezek használhatóak swapre, a dinamikus ram ugyanis nemcsak gyors, de korlátlan számban írharó/törölhető, mint a hagyományos merevlemez. azonban az ilyen SSDk ára csillagászati. egyes típusok drága SRamokat használnak, ezek ára is csillagászati. pont ezért általában a DRam vagy SRam chipeket használó driveokat nem ssd, hanem RAMdrive névvel szokták illetni.
hagyományos SSDn kockázatos swappelni, még az SSDvel felszerelt netbookoknál is érdemes kikapcsolni a swapet. ha nincs szerencséd pont egy olyan típust fogsz ki, ami csak swapre kevés 100ezerX írható/törölhető. sajnos ezt az értéket nem szokás feltünteni az SSDken. de még a milliószor újraírható SSD is tönkremegy egyszer, főleg heavy swapping mellett.

ha nem elég a 4Gb ram, a legjobb recept,
AMD64 bites mód és még több ram.

( denes | 2009. 04. 15., sze – 19:20 )

szerintem nem lehet azt megmondani a linuxnak (de javitsatok ki ha tevednek), hogy a buffer cache-t ne ram-ban hanem lemezen tarolja - ugyhogy tok mindegy hol a swap, a buffer cache ram-ban lesz, tehat az otleted lenyegeben nem kivitelezheto.

- Use the Source Luke ! -

( saxus | 2009. 04. 15., sze – 19:26 )

Tegyél inkább ramot a gépbe. De szvsz, jobban jársz egy normális IO alrendszerrel.

Ismerősömnek is volt SSD adatbázis alatt, mert kellett a sebesség, aztán szét is ment < fél év alatt. Most 4x74G 15k rpm RAID 10 SAS van alatta.

----------------
Lvl86 Troll

( nangyal | 2009. 04. 15., sze – 20:09 )

Kösz hogy a diszk szerverezési megoldásokat forszírozzátok
de ezt az utat már végigjártam, biztos olvastátok fentebb
hogy most 4 diszk böl álló raid1 van ami tök jól megy,
de azt szeretném ha ez még terhelhetőbb lenne olcsó pénzért
az adat mennyiség nem nagy most kb 500gb de sokáig nem fogja átlépni az 1tb -t
ahhoz hogy jól menjen a rendszer legalább 32 gb ram kellene de inkább több
na most egy ilyen szerver reg-ecc ram -mal együtt 500e alatt nem hiszem hogy megúsznám
(bár nem számoltam utána)

viszont egy 32 gb os ssd winyó az 22e+afa és ha
egy kis okossággal be lehetne vonni a kiszolgálásba
simán legalább 100% os teljesítmény növekedést hozna magával
mivel cache szerepet látna el így az írás szinte elhanyagolható
mivel jellemzően olvasna róla a rendszer

fentebb írta valaki hogy adatbázisnak használt valaki ilyet
na ott viszont nem csoda hogy szétesett mivel
minden adatbázis műveletnél ír a winyóra

Szóval ha van kedve valakinek eszelni a dolgon az jó lenne

másrészről pedig:
"Sun: elérkezett az ideje, hogy SSD kerüljön minden szerverbe"
http://www.hwsw.hu/hirek/38309/sun_microsystems_szerver_flash_ssd_hdd_m…

Köszi az eddigi hozzászólásokat

azok nem 22e+áfa árú SSDk:) a Sun szerverekbe még a scsi hdd is többe kerül, mint a garázsPCkbe.
nem kell különösebb trükk swapként való használathoz. létre kell hozni a swap partíciót, majd
swapon /dev/XXXX
és más swappel is rá.
de nagyon nem ajánlom. ezek az olcsó SSDk sima flash chipekkel vannak szerelve. kemény használat mellett pár hónap alatt tönkremennek. a hibás swap pedig egyáltalán nem használ egy szerver stabilitásának.
statikus, ritkán változó állományokat érdemes kiszolgálni ilyen SSD driveokról. a sokszori olvasással nincs probléma, és abban is gyorsak.

es vajon hogy fogja megmondani a linuxnak, hogy a buffer cache-t is irja a lemezre (oda ahol a swap van) es ne a fizikai ramban tarolja?
mert szerintem sehogy, de mindenesetre ez volt a kerdes lenyege, tehat aki tudja irja le mert engem is erdekel :) (a forrasbol persze valoszinuleg aranylag egyszeruen meg lehetne nezni hogy lehet-e ilyet, de en most nem nezem meg).

szerk: megtekinteve a forrast, szerintem csak a kernel memoriaba cache-sel, es azt nem lehet kiswapolni.

- Use the Source Luke ! -

500G, négy diszken, RAID1... Mivel neked három másik gépet kell kiszolgálni, így jó esélyed van arra, hogy a műveletek jelentős része ütközni fog, azaz ugyanazt a fizikai diszket babrálja. Szerintem még két diszkkel, meg egy normális vezérlővel lehetne első körben tuningolnod.

Egyébként meg azokaz fs-ek, amik access time mezőt is nyilvántartanak, azok is elég sokat firkálnak a diszkre, hacsak nem "noatime"-mel csatolod...

Azt megkérdezem, milyen RAID-vezérlőt használsz? Mekkora cache van rajta? Az is tud lökni a teljesítményen...

Volt szerencsém látni azt a prezentációt, amiből a hwsw cikk is vette a slide-okat.
Az egyik slide-on volt egy figyelemreméltó információ:
Enterprise SSD: 35$/GB
Vagyis a 32GB SSD az bizony nem 22eFt hamen kb. 250eFt

Azt a prezentációt ugyan nem leltem meg, de azt hiszem, ez is megteszi helyette:
http://www.sun.com/storage/flash/SSD_datasheet.pdf

( nangyal | 2009. 04. 15., sze – 22:57 )

áááááááá
nem hiszem el hogy mindenki másról beszél
nem kell kioktatni raid vezérlőkből stb....
nem mintha én lennék az aki mindent tud a témában, azért elboldogulok
hanem mert egészen másra voltam kíváncsi, más volt a kérdés
pl.: a swap et eddig is be tudtam kapcsolni

vonatoztassunk el az ssd töl hogy egyértelműbb legyen

az volt az eredeti kérdés hogy be lehet e kapcsolni úgy a
swap et hogy a futó process eket ne akarja oda írni
csak a file cache -t amit a disk röl már egyszer beolvasott
(az apache disk cache hoz hasonlóan)
vagy van e valami hasonló megoldás

Nem. Az ssd _ugyanolyan_ blokkdevice, mint a sima vinyód, ugyanúgy kezeli a Linux. Ha akarod, megoldhatod, hogy ne így legyen, minden esetre én inkább máshogy gyorsítanék -- pl. egy normális céleszközzel, ha annyira durván kell a teljesítmény. Ja, és a storage-szerver(ek) közötti forgalmat dedikált gigás kapcsolatokon/interfészen csinálni természetesen...

"az volt az eredeti kérdés hogy be lehet e kapcsolni úgy a
swap et hogy a futó process eket ne akarja oda írni
csak a file cache -t amit a disk röl már egyszer beolvasott"

Gondold végig logikusan.
Szerinted???

Vegyél RAM-ot, meg normális RAID kártyát, SCSI/SAS lemezekkel (6-8 darabot), tedd őket ízlés szerint RAID10-ba, vagy RAID5-be, RAID6-ba.
Softraiddel is megpróbálkozhatsz, gigabitet avval is simán ki lehet tolni egy c2d ~2Ghz, 2gb ram, 9 sata lemez konfigon.
De inkább normáis RAID vezérlő, 6-8 lemez, és HW RAID. (egy ilyennek akár lehet 4-500MB/sec olvasási sebessége is)

Vagy,mégjobb! Normális RAID vezérlő 256MB cache-val, 6-8 SAS lemez jbod módban, ZFS RAIDZ használata. Állítólag így nagyon durva sebességeket lehet elérni. :)

Hello

igaz hogy egy rendesebb ssd nek rendesebb ára van
de az első működő verzió szerintem elmenne pár hónapig
mezítlábas ssd vel is

Ezekre az új ssd -k re már 50 000 órát garantálnak (kb 5 év)
ha csak 1 évet bír ki már tök jók vagyunk

a ssd nek leginkább az írás a fájó pontja
de mivel cache lenne jellemzően az olvasás menne róla
persze nem kizárt hogy mégis csak kipusztul 1 hónap után
de akkor majd megint elkezdünk gondolkozni.....

( turul16 v | 2009. 04. 18., szo – 13:38 )

Eleg hulyesegnek hangzik.

Normal vinyo 80 Mb-vel olvas, ha azt meg ki is akarod irni a "swapre" akkor 160Mb savszeled mar el is tunt, es meg csak egy vinyonal jarunk.
Linux Nem swappel alapbol chache-t, elso lepesben azt kene megvaltoztatnod.

Inkabb ilyesmivel probalkozz:
http://insights.oetiker.ch/linux/external-journal-on-ssd.html

(Ha nem felsz a power failtol es hasonloktol akkor mindenbol csinalhatsz swapet es ramdiskent hasznalod.)

10-20 Mb/s nem olyan nagy terheles. Raid 10 -el is siman jol jarsz, a legroszabb esetben is. ( Jo esetben ugye egy vinyo is eleg volna :))

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Normal vinyo 80 Mb-vel olvas"
igen ha két winyó között nagy file -okat másolsz

próbáld meg hogy egyszerre (párhuzamosan) 10 file -t másolsz át
meg fogsz lepődni...
pláne ha 50 at vagy 100 at (mintha 100 látogató lenne egy weboldalon egyszerre)

Látszik hogy sok ilyet csináltál már

"Linux Nem swappel alapbol chache-t, elso lepesben azt kene megvaltoztatnod."
igen, az volt a kérdés egyik része hogy ezt hogyan lehet

Bezony... Soksok kicsi random olvasáshoz soksok kicsi diszkre szét kell szórni az adatokat... A nyugodt alvás érdekében persze lehetőleg tükrözve az egészet. Nem véletlen, hogy nagy és gyors storage-okban egy-egy diszk a tárolt adamenyiséghez képest pici. Pár éve a 143G-s diszkeket is csak akkor merte az ember betervezni, ha nagyon szorított a doboz mérete...