On 7/5/07 3:11 AM, "Darren Reed" <[EMAIL PROTECTED]> wrote:
> Peter Eisch wrote: >> If something like that is considered, then there should be a report version >> header included so you're not expecting to see stats for values that aren't >> reported in that version. >> >> Is it a big deal (not personally have done it) to map these values to the >> /kern filesystem? >> >> I use a cron job that runs every minute that scans and logs the output for a >> small subset of the values: >> 'in use' >> 'bucket usage' >> 'active' >> 'max bucket' >> 'maximum' >> I don't specifically know the cost of getting the full stats rather than >> just a subset like this. > > I haven't ever looked at using /kern on BSD. > What are you expecting to see? > Or how are you expecting to use such an interface? > Excellent questions to which I haven't even marginal answers. Capturing stdout from 'ipfstat -s' is little different than opening /kern/ipfstat for reading once past the overhead of an exec call. My best case scenario would be to able to tie vars to oids and then use simple tools to track kernel resources. Even that though would best be implemented by an agent that ioctl'd the kernel anyway and subsequently be a compiled program. Using perl to do the same seems clumsy and marginally portable if using ioctls and "expensive" with exec while reading from a file is simpler. [wandering off topic] The root of this (for me) could be tied back to two other current threads. Finding the "right" prime number to make the kernel buffers sufficiently large while still being reasonable; being able to detect when I've hit the wall; and potentially being able to change the values without having to recompile a kernel. I've had to stop keeping state on the most common TCP ports due to the large number of sessions I need to support. This has been the quick solution to when I hit the wall and it doesn't cost me a full reboot. [/wandering] peter
