Re: Best practices for IDS on virtual machine?

Hi Art , Hmm... I would like to disagree with you... but before that I will do the write test. What I remember from tests did on the past (studying about this behave) I conclude the write I/O throughput bounds will be "defined" from the Linux kernel dirty buffers flush/sync parameters and how much memory do you have available to hold this dirty buffer (against the amount of data written from the engine during a checkpoint for example). Like I said , I *would like* but I do not dare disagree THE Art Kagel :) I will test and post here my test ... Regards Cesar 2013/4/13 Art Kagel <art.kagel@gmail.com> > Cesar, your timings for read-reread using the OS cache are credible and I > will say something about that at the end. However, note that whether you > use RAW or COOKED without DIRECT_IO or COOKED with DIRECT_IO your data is > safe! When you disable DIRECT_IO and are using COOKED chunks, Informix > opens all chunk files, except temp dbspaces, with the O_SYNC flag enabled > which causes any writes to those files to be immediately flushed to disk > before acknowledging the write as complete. Informix in turn does not > complete any transaction on an unbuffered log database unless the logical > log buffer write containing the COMMIT record has been acknowledged by the > OS that means that your data is safe! Now if you are using BUFFERED > logging, then there is a small risk that transactions accumulating in the > log buffers may not be written to disk until the buffer fills. That opens > a window of risk, but the risk is the same for RAW and COOKED with > DIRECT_IO if you use buffered logging. > > Now to your timings. Yes, reading and rereading the same data from the > buffer cache will be faster with COOKED files than with RAW or DIRECT_IO > which bypass the buffer cache. However, you did not present any timings > for writing! That is where RAW and DIRECT_IO improve your performance. > With COOKED files and no DIRECT_IO Informix is writing from its buffers to > the OS buffers and the O_SYNC flag is forcing the OS to wake a sync thread > to write the newly dirtied cache pages to disk. Informix has to wait for > the extra memory copy then for the OS IO scheduler to wake an IO thread and > perform the write. With RAW devices and with DIRECT_IO enabled for COOKED > files, the copy from Informix memory to OS memory is skipped and an > Informix AIO VP performs the write directly or a KAIO thread schedules the > asynchronous IO in the OS kernel's asynchronous IO service and returns to > work without having to wait. This is at least 25-20% faster than an O_SYNC > write which is completely synchronous and so must be performed by > Informix's AIO VPs. > > Test it! > > 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, Apr 12, 2013 at 8:19 PM, Cesar Inacio Martins < > cesar.inacio.martins@gmail.com> wrote: > >> Hi Richard , >> >> check this practical test about the effect of the cooked file cache >> (performance focus) : >> >> | tablename = my_table >> | size allocated = 3168 MB >> | size used = 2974 MB >> | rows = 33.120.000 >> >> I reconfigure my test instance with only 40MB of 4k pages buffer (where >> the data is allocated) >> | $ onstat - >> | IBM Informix Dynamic Server Version 11.70.FC6 -- On-Line -- Up >> 00:05:43 -- 688536 Kbytes >> | $ onstat -b | grep buff >> | 0 modified, 10000 total, 16384 hash buckets, 2048 buffer size >> | 0 modified, 10000 total, 16384 hash buckets, 4096 buffer size >> | 0 modified, 10000 total, 16384 hash buckets, 8192 buffer size >> >> >> The machine: Opensuse 12.2 with 4GB memory running over vmware ESXi with >> 1 SATA disk (this is a desktop, where I use for tests) >> the chunks are into ext2 partition , but I'm not using DIRECT_IO , where >> will make all difference here... because with it will behave as RAW . >> | $ mount | grep ifx >> | /dev/mapper/vgifxdados-lvifxdisco1 on /ifxdados type ext2 (rw,noatime) >> >> Here I clear the Linux cache : >> | jdivm06:~ # echo 3 > /proc/sys/vm/drop_caches >> >> This output is from "dstat -tmd 5" utility (is a SAR improved) >> | ----system---- ------memory-usage----- -dsk/total- >> | time | used buff cach free| read writ >> | 12-04 20:29:36| 429M 28.6M 2384M 1022M| 211k 75k >> | 12-04 20:29:41| 429M 28.6M 2384M 1022M| 0 0 >> | 12-04 20:29:46| 429M 28.6M 2384M 1022M| 0 0 >> | 12-04 20:29:51| 215M 264k 298M 3350M| 16k 0 <<<< drop caches >> run here >> | 12-04 20:29:54| 214M 264k 298M 3351M|5461B 0 >> >> I run this select forcing a full scan, remember: 2.9 Gb will be read from >> disk at least and the engine have only 40 MB of buffers. >> I don't know why the output of my "time" command become all together on >> the same line, anyway you can see , took 1 minute to run. >> | $ echo "select {+full (my_table)} count(1) from my_table" | time >> dbaccess testedb >> | Database selected. >> | (count) >> | 33120929 >> | 1 row(s) retrieved. >> | Database closed. >> | 0.00 user 0.00 system 1:02.78 elapsed 0%CPU (0 avgtext+0avgdata >> 11248maxresident)k >> | 0inputs+0outputs (0major+781minor)pagefaults 0swaps >> >> dstat output : Check the memory usage and disk read. >> | ----system---- ------memory-usage----- -dsk/total- >> | time | used buff cach free| read writ >> | 12-04 20:34:46| 214M 232k 320M 3329M| 958k 0 >> | 12-04 20:34:51| 213M 232k 320M 3330M| 0 0 >> | 12-04 20:34:56| 217M 336k 455M 3192M| 21M 0 <<<<< start the >> select here >> | 12-04 20:35:01| 219M 636k 755M 2888M| 60M 0 >> | 12-04 20:35:06| 217M 852k 970M 2675M| 43M 0 >> | 12-04 20:35:11| 217M 1032k 1151M 2494M| 36M 0 >> | 12-04 20:35:16| 217M 1120k 1238M 2407M| 17M 0 >> | 12-04 20:35:21| 218M 1160k 1284M 2360M|9162k 401k >> | 12-04 20:35:26| 217M 1440k 1556M 2088M| 54M 345k >> | 12-04 20:35:31| 217M 1684k 1801M 1843M| 49M 0 >> | 12-04 20:35:36| 218M 1928k 2044M 1600M| 49M 0 >> | 12-04 20:35:41| 218M 2264k 2379M 1264M| 67M 0 >> | 12-04 20:35:46| 219M 2472k 2587M 1054M| 42M 0 >> | 12-04 20:35:51| 219M 2720k 2839M 803M| 50M 0 >> | 12-04 20:35:56| 220M 3108k 3224M 416M| 77M 0 <<<<<< finished here >> | 12-04 20:36:01| 219M 3200k 3319M 322M| 19M 0 >> | 12-04 20:36:06| 220M 3200k 3319M 322M| 0 0 >> | 12-04 20:36:11| 220M 3200k 3319M 322M| 0 211k >> | 12-04 20:36:16| 220M 3200k 3319M 322M| 0 0>> >> >> You must agree we will not use much buffer pool from engine right. >> So if you go with RAW devices or DIRECT_IO here and run the same >> statement