mkramdisk

Greetings Everyone, This is my first post, and right away I have a question. I've been toying with the idea of using mkramdisk to create a large enough ram drive to hold my temp space. One concept that I've been contemplating is to have the server create a the ram disk on startup, and if successful, copies the temp DB space chunks to the ram disk, and re-link the symbolic file links to the chunks that now exist on the ram disk. Has anyone gone through with something similar to this? If so, how well did it work for you? Did you notice much in the way of performance increases? Thanks

It will work, the copy is the critical part. Performance will depend on how extensively your system uses temp space. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jan 27, 2012 at 9:17 AM, ANTHONY LANDRY <justicepvp+iiug@gmail.com>wrote: > Greetings Everyone, > This is my first post, and right away I have a question. > > I've been toying with the idea of using mkramdisk to create a large enough > ram > drive to hold my temp space. > > One concept that I've been contemplating is to have the server create a the > ram disk on startup, and if successful, copies the temp DB space chunks to > the > ram disk, and re-link the symbolic file links to the chunks that now exist > on > the ram disk. > > Has anyone gone through with something similar to this? If so, how well > did it > work for you? Did you notice much in the way of performance increases? > > Thanks > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8f3ba681a728fd04b7837a31

That's totally unsuported, but I imagine you know that. As Art wrote, it really depends on how much use of temp dbspace you have... But then again, if you have plenty of RAM then you can configure your instance to do things in memory instead of on disk... Having said that, I once did something similar to test some INSERTs. I noticed I was getting slow because of the logical logs, so I created a dbspace in ramdisk and moved the logical logs there (how's that for unsupported hmmmm?). I didn't kept numbers, but it really made a difference (of course having logical logs in memory is more or less saying that you don't care about recoverability, so why use logging after all). But I did it for the "fun". If by any chance you use temp for temporary tables, than something that could be interesting would be to create tables using VTI (Virtual table information) that would keep them in memory... Or eventually use external dbspaces... But I never paid too much attention to any of these... That could be the beginning of integrating solidDB "inside" Informix... Regards. On Fri, Jan 27, 2012 at 2:17 PM, ANTHONY LANDRY <justicepvp+iiug@gmail.com>wrote: > Greetings Everyone, > This is my first post, and right away I have a question. > > I've been toying with the idea of using mkramdisk to create a large enough > ram > drive to hold my temp space. > > One concept that I've been contemplating is to have the server create a the > ram disk on startup, and if successful, copies the temp DB space chunks to > the > ram disk, and re-link the symbolic file links to the chunks that now exist > on > the ram disk. > > Has anyone gone through with something similar to this? If so, how well > did it > work for you? Did you notice much in the way of performance increases? > > Thanks > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --00248c769136a8e71304b783fd59

Thanks for the responses. After reading your replies, you've helped me shape my direction more toward adding a SSD array that is large enough for my logs and tmpdbs. Probably running 4 drives raid 10 plus a hot spare. Since I've never ran a database off of SSDs, any advice is welcome. Thanks

Runs great! Be careful to know and monitor the devices' MTBFs and replace them when they get close. Also, be very careful which drives you buy. The performance characteristics of the various brands and models very widely and several are not worth the cost premium over physical spindles! Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jan 27, 2012 at 12:58 PM, ANTHONY LANDRY <justicepvp+iiug@gmail.com>wrote: > Thanks for the responses. > > After reading your replies, you've helped me shape my direction more toward > adding a SSD array that is large enough for my logs and tmpdbs. > > Probably running 4 drives raid 10 plus a hot spare. > > Since I've never ran a database off of SSDs, any advice is welcome. > > Thanks > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8f6432c222966204b78821fc

Do you have suggestions on which brands/model lines are better Art? Jonathon Wyza CX & CBORD System Administrator CX Programmer/Analyst Administrative Computing Bethel College (574)-807-SQL5(7755) AIM: Iamwyza Google+ Profile jonathon.wyza@bethelcollege.edu =============================== SLES 11x64 & IDS 11.50.FC6 JICS 7.4.3 & Cognos 8 "Don't document the problem, fix it." - Atli Björgvin Oddsson -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Friday, January 27, 2012 3:14 PM To: ids@iiug.org Subject: Re: mkramdisk [26062] Runs great! Be careful to know and monitor the devices' MTBFs and replace them when they get close. Also, be very careful which drives you buy. The performance characteristics of the various brands and models very widely and several are not worth the cost premium over physical spindles! Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jan 27, 2012 at 12:58 PM, ANTHONY LANDRY <justicepvp+iiug@gmail.com>wrote: > Thanks for the responses. > > After reading your replies, you've helped me shape my direction more > toward adding a SSD array that is large enough for my logs and tmpdbs. > > Probably running 4 drives raid 10 plus a hot spare. > > Since I've never ran a database off of SSDs, any advice is welcome. > > Thanks > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8f6432c222966204b78821fc ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Check out this article and its predecessor article: http://www.techspot.com/review/181-solid-state-drive-roundup2/ Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jan 27, 2012 at 3:22 PM, Wyza, Jonathon <wyzaj@bethelcollege.edu>wrote: > Do you have suggestions on which brands/model lines are better Art? > > Jonathon Wyza > CX & CBORD System Administrator > CX Programmer/Analyst > Administrative Computing > Bethel College > (574)-807-SQL5(7755) > AIM: Iamwyza > Google+ Profile > jonathon.wyza@bethelcollege.edu > =============================== > SLES 11x64 & IDS 11.50.FC6 > JICS 7.4.3 & Cognos 8 > > "Don't document the problem, fix it." > - Atli Björgvin Oddsson > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Friday, January 27, 2012 3:14 PM > To: ids@iiug.org > Subject: Re: mkramdisk [26062] > > Runs great! Be careful to know and monitor the devices' MTBFs and replace > them > when they get close. Also, be very careful which drives you buy. The > performance characteristics of the various brands and models very widely > and > several are not worth the cost premium over physical spindles! > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > organization with which I am associated either explicitly, implicitly, or > by > inference. Neither do those opinions reflect those of other individuals > affiliated with any entity with which I am affiliated nor those of the > entities themselves. > > On Fri, Jan 27, 2012 at 12:58 PM, ANTHONY LANDRY > <justicepvp+iiug@gmail.com>wrote: > > > Thanks for the responses. > > > > After reading your replies, you've helped me shape my direction more > > toward adding a SSD array that is large enough for my logs and tmpdbs. > > > > Probably running 4 drives raid 10 plus a hot spare. > > > > Since I've never ran a database off of SSDs, any advice is welcome. > > > > Thanks > > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --e89a8f6432c222966204b78821fc > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --bcaec5186cbeed81c904b7886a69

I have used tempdbs on ramdisk in Linux with version of Informix 9.40 and it was big performance increases. From version 11.x and newest Linux, I don't use ramdisk because I have same performance with and without tempdbs on ramdisk. Why ? I think because of this: If your system have plenty of read/writes of small amount of data to tempdbs, + your informix version is 11.X and you use Linux OS, and you have plenty od RAM, I suggest you to: - put datadbs on storage, or some disk array - Raid10 as raw devices with direct I/O - create more than three tempdbs on file system (tempdbs is working always without direct i/o I think) In this way, you will use Informix BUFFERS to cache data on dadadbs on Raid10 array, and cache from OS Linux to read/write into/from tempdbs. Other way, if your system is doing small number of read/write but plenty of data on tempdbs (bigger than you free RAM in OS), then buy SSD disk-s, configure as Raid1 and put the tempdbs's on then. onstat -g iof will tell you how Informix really "feel" speed of i/ooperations on chunks. Here are, on first view, strange behavior: Raw devices is on EMC storage, plenty of disk, Raid 10 etc .. tempdbs is on cheap two local disks with Raid 1 and onstat -g iof says: (io/s is important) AIO global files: gfd pathname bytes read page reads bytes write page writes *io/s* 11 /dev/raw/raw7 1411320700928 689121804 7446683648 3636080 *364.2* 4 /dbs/tempdbs1 1305537200128 637475284 1259472764928 614976968 *8175.8* all this because of cache on Linux OS :) On 27.01.2012 15:17, ANTHONY LANDRY wrote: > Greetings Everyone, > This is my first post, and right away I have a question. > > I've been toying with the idea of using mkramdisk to create a large enough ram > drive to hold my temp space. > > One concept that I've been contemplating is to have the server create a the > ram disk on startup, and if successful, copies the temp DB space chunks to the > ram disk, and re-link the symbolic file links to the chunks that now exist on > the ram disk. > > Has anyone gone through with something similar to this? If so, how well did it > work for you? Did you notice much in the way of performance increases? > > Thanks > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > -- Ivan Zaviç System& DB Administrator Mobile:+381-69-846-99-08 mail: ivan.zavis@mi-system.co.rs _________________________________________________________ M&I SYSTEMS CO. Bulevar vojvode Stepe 16, 21000 Novi Sad, Serbia Tel/Fax: +381-(0)21-68-98-608 Mail: info@mi-system.co.rs, URL: http://www.mi-system.co.rs Odricanje od odgovornosti: Ovaj dokument namenjen je samo licima kojima je upu†en i za pozivanje na isti od stane bilo kog lica, neophodna je naknadna pismena potvrda njegovog sadr§aja. Shodno tome, M&I Systems, Co. Novi Sad odriŸe svaku odgovornost i ne prihvata bilo kakvu obavezu (ukljuŸuju†i sluŸaj nepa§nje) za posledice koje mo§e pretrpeti bilo koje lice zbog Ÿinjenja ili neŸinjenja na bazi takve informacije pre nego çto takva lica prime dodatnu pismenu potvrdu. Ukoliko ste greçkom primili ovu elektronsku poruku, uniçtite ili izbriçite istu sa vaçeg raŸunara. Svako umno§avanje, çirenje, kopiranje, obelodanjivanje, izmene, distribucija i/ili objavljivanje ove elektronske poruke je strogo zabranjeno. Sadr§aj ove elektronske poruke ne predstavlja nu§no stavove M&I Systems, Co. Novi Sad