Re: Best practices for IDS on virtual machine?

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 > statemente again, will take the same or close time. > With cooked file without DIRECT_IO , take only 9 seconds... > > | $ echo "select {+full (my_table)} count(1) from my_table" | time > dbaccess testedb > | Database selected. > | (count) > | 33120929 > | 1 row(s) retrieved. > | Database closed. > | > | 0.00user 0.00system 0:09.23elapsed 0%CPU (0avgtext+0avgdata > 11248maxresident)k > | 0inputs+0outputs (0major+781minor)pagefaults 0swaps > > dstat output : > | ----system---- ------memory-usage----- -dsk/total- > | time | used buff cach free| read writ > | 12-04 20:37:16| 220M 3200k 3319M 321M| 0 0 > | 12-04 20:37:21| 220M 3200k 3319M 322M| 0 0 > | 12-04 20:37:26| 220M 3200k 3319M 322M| 0 0 > | 12-04 20:37:3