Monitoring IDS Load

Hi, I want to tune my IDS instance for optimal utilization. Towards this end I wish to run a load test. I would like to know what all IDS related statistics should I monitor. What kind of tools, scripts should be run while running load test. Some of things which I want to tune specifically are: - Segment size - FG writes - Write Cache - UDR Regards, Gurpreet.

For load/strees testing - versus normal performance monitoring - I would concentrate on the stats displayed by onstat -D, onstat -p (including calculating the basic metrics - BR, BTR, and RAU), onstat -g iov, onstat -g iof, onstat -g ppf, onstat -g seg as well as operating performance stats such as %CPU usage and %memory and swap usage. You are looking for unusual stresses, IO rates approaching or exceeding capacity, disk hotspots, increases in memory usage that may presage swapping, etc. 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 Mon, Sep 3, 2012 at 1:29 AM, GURPREET SACHDEVA <gusachde@cisco.com>wrote: > Hi, > > I want to tune my IDS instance for optimal utilization. Towards this end I > wish to run a load test. I would like to know what all IDS related > statistics > should I monitor. What kind of tools, scripts should be run while running > load > test. Some of things which I want to tune specifically are: > - Segment size > - FG writes > - Write Cache > - UDR > > Regards, > Gurpreet. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93404af3bba1904c8cd5a1a

Thanx Art. Wanted to know how different would be measurement during normal performance load. Regards, Gurpreet.

Normal performance monitoring would include all of that and more including: onstat -P - to monitor which partitions have a dominance in the the cacheand how much that presence is changing over time to determine whether more cache will improve performance Monitoring dbspace freespace changes to predict when space will need to be added. Monitoring tables and indexes with larger numbers of extents to determine candidates for reorganization. Monitoring tables for sequential scans to determine tables that may be missing indexes or are affected by poorly written SQL. Monitoring running SQL to look for sessions with hight sequential scans or a high percentage of disk based sorting. Among other things. 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 Tue, Sep 4, 2012 at 1:47 AM, GURPREET SACHDEVA <gusachde@cisco.com>wrote: > Thanx Art. > > Wanted to know how different would be measurement during normal performance > load. > > Regards, > Gurpreet. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93411195fff2204c8e06954

These indeed look like good parameters to note for. What are the low threshold level and high threshold level for these parameters. What kind of relationships between these statistics should we watch for. Is there a benchmark for analyzing command's output. I found something related to o/p of onstat -p. It is recommended that Bufwait ratio should always be less than 7%, such as Bufwaits Ratio (BR) = (bufwaits / (pagreads + bufwrits)) * 100 Shoot for a BR less than 7% (lower the better) adding LRUs as needed. What are other such recommendations, ratios. Can you point to some references, URLS.

There are three basic performance metrics that I developed that are in general use as bell weathers of overall performance. One, as you noted is the Bufwaits Ratio or BR, the second is the Buffer Turnover Rate or BTR, and the third is the Readahead Utilization or RAU. You can download and install my package ratios.shr_ak. It contains a stored procedure that you install into sysmaster (as informix) in ratios.sql and a shell script to run (newratios.ksh) that calculates these three metrics and a couple of others. The BR and BTR should be calculated separately for each buffer pagesize as well as overall. The formulas are: BR = ((bufwaits/(pagreads+bufwrites)) * 100) Range: 0-7% - OK <10% - Some queries are seeming to be running slow >10% - Many users are experiencing slow response times. Need to increase LRUs for this cache BTR = (((pagreads+bufwrites)/<#buffers>)/<time since stats were zero'd in fractional hours) -- expressed as turns/hour Range: < 10 turns/hour - Healthy > 10 turns/hour - Lots of buffer thrashing. Need to increase buffers in this cache. RAU = (((ixda-RA+idx-RA+da-RA)/RA-pgsused)*100) Range: As close to 100.00% as possible. I get worried when RAU drops below 99.50% Others: Sequential Scan Rate(SSR): (seqscans / <isam opens>) * 100 -- Percent of queries that include a sequential scan Range is VERY dependent on the type of queries you do, so you have to determine a good/bad range depending on your query mix. For pure OLTP with few small lookup tables that are active 1.00% is a good ceiling to start with. Lockwait Ratio(LWR): ((lokwaits/lockreqs) * 100 -- Precentage of lock requests that had to wait Same as for SSR, this is workload dependent. However, if this is high look for highly active tables with page level locking. 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 Thu, Sep 6, 2012 at 7:14 AM, GURPREET SACHDEVA <gusachde@cisco.com>wrote: > These indeed look like good parameters to note for. What are the low > threshold > level and high threshold level for these parameters. What kind of > relationships between these statistics should we watch for. > > Is there a benchmark for analyzing command's output. I found something > related > to o/p of onstat -p. It is recommended that Bufwait ratio should always be > less than 7%, such as > > Bufwaits Ratio (BR) = (bufwaits / (pagreads + bufwrits)) * 100 > > Shoot for a BR less than 7% (lower the better) adding LRUs as needed. > > What are other such recommendations, ratios. Can you point to some > references, > URLS. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae934090361a78d04c907a279