[Ramdisk] Ramdisk wil niet boven de 1 GB

[Glimi]

Korte samenvatting: Ik zit hier met Suse Linux 8.0 (wel aardig hoor ) en daar moet een ramdisk op van 1.4 GB. Echter hij loopt gewoon tegen een limiet aan van 1 GB terwijl ik wel genoeg geheugen heb (2 GB, waarvan 1,8 Free)

Waarom moet je een ramdisk?
Daar moet MySQL gaan draaien. Die bak moet namelijk behoorlijk gaan blazen....

Wat is de situatie
Ik heb het volgende tot nu toe gedaan. Let hierbij wel op dat ik wel verschillende dingen door elkaar geprobeerd heb, en dat er daardoor dingen niet met elkaar overeen kunnen komen.

-Eerst large mem support aan in de kernel (4 GB)
-Toen ramdisk support in de kernel
-Loopbackdevice support in de kernel
-Parameter meegeven aan de kernel in lilo(append = "ramdisk_size=1468006")

-een hugeRamdiskDevice aanmaken (mknod /dev/hugeram0 b 126 0)
-mounten van het device als tmpfs (mount -t tmpfs /dev/hugeram0 /mnt/ramdisk)
-schrijven naar die hap (dd if=/dev/zero of=/mnt/ramdisk/bla b=1k count=1468006)

Het probleem
dd schrijft maar tot ong 1 GB (103xxxx kb) en niet 1.4 GB zoals ik hem bevolen heb. Hij loopt dus tegen een limiet op van de kernel (vermoed ik). Echter ik heb geen idee meer hoe over deze liemiet heen te stappen. Ik zag namelijk in de kernel parameters ook helemaal niets wat me daarbij kon helpen Misschien dat iemand hier wat weet?

Waar heb je al die onzin vandaan? Uhm ramdisk.txt, google newsgroups en http://www.linux-vr.org/ramdisk.html

Het is dus niet bedoeld voor bootdisks, maar puur voor MySQL tables.

btw nog wat info:

code:

Mem:       2 GB
OS:     Suse Linux 8.0 Professional

Dank!

[Kees]

Heel vervelend voo jou; maar het heeft weinig tot geen nut om je tables op te slaan in je ram geheugen, hierdoor blijft er minder over voor je mysql ( en berekeningen, temptables, sorteringen etc) waardoor je mysql zal gaan swappen. Ook erg gevaarlijk is een crash. Je bent dan meteen een hele rits data kwijt, dus mijn aanbeveling? NIET doen, het geeft meer nadelen dan het ooit voordelen kan geven.

[Glimi]

Op vrijdag 24 mei 2002 15:42 schreef Kees het volgende:
Heel vervelend voo jou; maar het heeft weinig tot geen nut om je tables op te slaan in je ram geheugen, hierdoor blijft er minder over voor je mysql ( en berekeningen, temptables, sorteringen etc) waardoor je mysql zal gaan swappen. Ook erg gevaarlijk is een crash. Je bent dan meteen een hele rits data kwijt, dus mijn aanbeveling? NIET doen, het geeft meer nadelen dan het ooit voordelen kan geven.

Een reply van kees! Wat een eer

Maar ok. Wat jij zegt heb ik ook al aan gedacht en ben ik het ook zeker mee eens, maar m'n baas dus niet helemaal.
Dit is de reden hiervoor:
In de ramdisk komen alleen temporary tables. Dat wil zeggen, tables die om de zoveel tijd gecleared worden en die om de zoveel tijd verwerkt worden, de rest van MySQL moet gewoon op het ext/3 fs.

Echter op deze tijdelijke tabellen vinden ont!zettend! veel bewerkingen plaats. Denk hierbij aan alle HTTP request in het netwerk van Reuters oid. Precieze getallen weet ik niet, maar het is enorm veel. Om te kijken of dit zo gaat werken (of MySQL het zo wel kan bijhouden), zullen die tijdelijke tabellen in een ramdisk gaan draaien. Het is dus ook nog een proef.

Nu weer terug naar het ramdisk probleem: Jongens zeg het maar

* Glimi is een eikel!

mount krijgt dus ook nog een size optie mee, als die niet gedefinieerd is in het filesystem En aangezien ik een leeg stukje ram geclaimed heb, was dat dus het geval. En rara hoe groot is de size als je de size niet opgeeft? Juist, 1 GB oftewel de helft van je ram.

[easydisk]

Dan kom ik al leek er even tussen door:
Als je meerdere subdirectory's hebt kan je tuurlijk ook
/ramdisk1/ramdisk2/ aanmaken als directory

met ramdisk1 = 1 GB en ramdisk2 = 0.4GB
i.p.v. /een_grote_ramdisk
het enige is dat je dus van te voren moet weten hoe groot zo'n subdir gaat worden.

[deadinspace]

Ik zou hem eigenlijk niet op een ramdisk zetten. Als Mysql die data vaak nodig heeft, dan cached de kernel het wel (in het geheugen dus).
Ik vraag me dus af of een ramdisk sneller is (zou wel interessante test zijn).

Op vrijdag 24 mei 2002 16:17 schreef Glimi het volgende:
* Glimi is een eikel!

mount krijgt dus ook nog een size optie mee, als die niet gedefinieerd is in het filesystem En aangezien ik een leeg stukje ram geclaimed heb, was dat dus het geval. En rara hoe groot is de size als je de size niet opgeeft? Juist, 1 GB oftewel de helft van je ram.

Maar het werkt nu dus?

[Glimi]

Op vrijdag 24 mei 2002 16:50 schreef deadinspace het volgende:
Ik zou hem eigenlijk niet op een ramdisk zetten. Als Mysql die data vaak nodig heeft, dan cached de kernel het wel (in het geheugen dus).
Ik vraag me dus af of een ramdisk sneller is (zou wel interessante test zijn).
[..]

Maar het werkt nu dus?

Jupz is gelukt, de test is nu ook draaiende Probeer nu een file in de db te stampen en dat gaat gewoon echt traag! Hij is al 4 minuten bezig met een txtfile van 26 meg met log data

[Verwijderd]

Voor een snelle mysql-configuratie kun je volgens mij:
- alle debugopties uitzetten
- alle logfuncties uitzetten
- innodb toevoeging gebruiken (ivm tablelocking)
- genoeg geheugen toewijzen aan de mysqld (dit kun je in je configuratie van mysql bepalen)
- hercompileren met -O6, dan voer je zoveel mogelijk optimalisaties uit...het scheelt niet veel, maar alle kleine beetjes zijn meegenomen

[ACM]

Op vrijdag 24 mei 2002 17:18 schreef Glimi het volgende:
Hij is al 4 minuten bezig met een txtfile van 26 meg met log data

Verwijder alle, behalve de prim key, indices en maak die achteraf er weer bij.

Overigens raad ik je aan heap-tables te gebruiken ipv ramfs dingen etc, dan sla je een hele serie stappen over in de kernel.

[deadinspace]

Op vrijdag 24 mei 2002 18:07 schreef Unexplained het volgende:
- hercompileren met -O6, dan voer je zoveel mogelijk optimalisaties uit...het scheelt niet veel, maar alle kleine beetjes zijn meegenomen

Daar zou ik mee oppassen. Boven bepaalde optimalisatie-levels is de code die gcc produceert niet meer 100% betrouwbaar. Bij mijn weten garandeert gcc slechts tot -O2 of -O3 dat de resulterende binary correct is.

Op vrijdag 24 mei 2002 18:23 schreef ACM het volgende:
Overigens raad ik je aan heap-tables te gebruiken ipv ramfs dingen etc, dan sla je een hele serie stappen over in de kernel.

Houdt dat in dat mysql zijn tables in ram opslaat? Zo ja, dan lijkt mij dat inderdaad een veel beter alternatief (maar als je toch gaat testen, vergelijk hem dan meteen met ramdisk en caching ).

[igmar]

Op vrijdag 24 mei 2002 15:26 schreef Glimi het volgende:
Korte samenvatting: Ik zit hier met Suse Linux 8.0 (wel aardig hoor ) en daar moet een ramdisk op van 1.4 GB. Echter hij loopt gewoon tegen een limiet aan van 1 GB terwijl ik wel genoeg geheugen heb (2 GB, waarvan 1,8 Free)

Even er vanuitgaand dat je het over tmpfs hebt :

in Documentation/filesystems/tmpfs.txt staat :

code:

tmpfs has a couple of mount options :

size: The limit of allocated bytes for this tmpfs instance.  The default is half of your physical memory without swap.

De reden hiervoor is dat je anders je systeem kan deadlocken : Er is geen manier om geheugen gealloceerd weer vrij te geven, dus op een gegeven moment gaat je systeem gewoon hard over de zeik.

Met size kun je de grootte aanpassen (de ramdisk_size optie kan ik niet terugvinden).

[Aaargh!]

Ik denk dat het cache systeem van het kernel efficienter (en veiliger) is dan een ramdisk.
Maar je zou natuurlijk een aantal tests kunnen draaien om de performance te vergelijken.

[deadinspace]

Op zaterdag 25 mei 2002 13:45 schreef Aaargh! het volgende:
Ik denk dat het cache systeem van het kernel efficienter (en veiliger) is dan een ramdisk.

Mja, OTOH: de kernel moet in het geval van caching wel voor elke block een lookup doen om te zien of hij gecached is of niet... Voor een ramdisk hoeft dat weer niet.