Video Screencast Help

Santa brought a first string cache implementation to {CWoC}, in the form of tag v0.2.0_Rev67

Created: 25 Dec 2009 • Updated: 30 Dec 2009
Ludovic Ferre's picture
0 0 Votes
Login to vote

Santa was busy last night but did not forget the CWoC folks on Connect. So under the tree this morning I found commit 67 [1] which was good enough to be tagged, as version 0.2.0 [2].

Has stated in a previous post [3] it contains a new feature in the form of a string cache. Without going into too much of the code itself we can say the following of the cache and it's current implementation and use (versus other implementation options and usages):

  • The string cache is currently a static array, set to hold a maximum of 8192 string cache entries.
  • The string cache entries are based on a struct defined as shown here:
    struct string_cache_entry {
            int     entry_id;       // Unique ID ~ useful? -> YES
            int     string_length;  // String length to avoid buff overflow
            char *  entry;          // String pointer (string will be heap based)
            enum string_type type;  // What kind of string is this?
            int     hit_counter;    // How many time the entry was added to cache
            int     hit_counter_rev;// How many time the entry was looked-up in cache
    };
    
    
  • With 6 integers used by the structure the current maximum memory consumption by the cache is ( 6 x 8192 ) + ( string_length x 8192 ) = ( 6 x 8 KiB) + ( 38 x 8 KiB ) = 336 KiB in case of filling up the cache with guids (36 bytes each).
  • A dump_cache function exist and is implemented via a command line switch. It dumps the content of the string cache to a file name cache_dump in the current directory. The file contains a header and data is tab separated. A sample output is shown here:
    ludovic@xubuntu-laptop:~/dev/altiris-ns-tooling$ ./top 20 DATA/cache_dump
    sce_id	length	string	type	hits
    0	36	1D6773EB-BCFA-4CD7-BD72-B5E019578BA9	0	3370
    1	36	CF1B574C-AA09-4B28-B79D-25EABAEC2C4E	0	33766
    2	36	6A5638B7-EF80-4592-9AC4-0AD20E017B51	0	4536
    3	36	DF79A308-018D-4C32-9D15-D47104E991B3	0	86800
    4	36	1CCC851D-5465-4145-B02E-DBCE4051497C	0	12715
    5	36	C0E557B2-FA3D-43E6-BA47-C6DA4EA49BED	0	69485
    6	36	51A0B2D9-8A0B-44B0-B309-97F9FFF663DE	0	69368
    7	36	A6A82E01-C757-4650-AEEE-6EA10D02B1FD	0	3236
    8	36	19623205-0324-4671-96CA-3AF960301B03	0	11
    9	36	6480F308-6B8C-4E61-9E5C-CFAD48FEB52E	0	47772
    10	36	C5602784-F2B7-4BD5-BA1D-189DB0CEFF4E	0	12859
    11	36	446A185E-1EF2-464F-B506-A2C595504514	0	11
    12	36	CA6B682F-B7A7-4BFA-824C-48E2B2ED50E2	0	3595
    13	36	F573FE76-8B9C-4265-B0E7-9D9502A5549B	0	11
    14	36	7BFA8F75-F17E-4D6A-A36C-6AE476EACE4A	0	8
    15	36	BD51EFD5-32E5-47B5-B3C8-1524F3D0D43C	0	2688
    16	36	C7BA58DC-7907-483D-88B3-B26DBF089387	0	21931
    17	36	AE61C502-6848-4CC0-A5D5-7EB5DF58E959	0	3
    18	36	D979F515-70DC-4303-B8B9-8E59F5D01505	0	2026
    
    

And we will finish this Christmas post with the good information that came out of this string cache and the data dump: we can get statistics that quickly would highlight incorrect or suspect behaviour, in the case above the fact that 86K and 69K hits are found for 3 unique identifiers is somewhat worrying. It's most likely that these are packages sending event data very often or some Patch Management inventory rules running far too often and set to send all inventory every time!

In all cases once I'll be back from leave in a couple of weeks I should have a lot of information to help my customer finding out why their servers are hit (by 10~12,000 agents) close to a million times in a day.

[1] http://code.google.com/p/altiris-ns-tooling/source...
[2] http://code.google.com/p/altiris-ns-tooling/source...
[3] http://www.symantec.com/connect/blogs/cwoc-working...