Michael Mohr
UNIX Systems Administrator
Auckland University of Technology
Private Bag 92006
Auckland, NZ
Tel: (649) 917-9999, ext 8133
Fax: (649) 917-9901
>>> [EMAIL PROTECTED] 05/04/01 06:55pm >>>
On Thu 03 May 2001 22:35, you wrote:
> Analog performs all of its processing in memory. This enhancement
is
> just short of requiring a database or series of temporary files.
We
> already have the very major potential for conflicts involving pie
> charts when two users are running simultaneously. Imagine the
chaos
> if two or three users are trying to process against a series of
files
> in /tmp or some other location. Unix users have it over NT users
in
He he he! What if your users use "gcc" the same time? Will
compiling
crash? ;-)
====
If your gcc is properly configured, that condition shouldn't happen.
Access to certain parts of memory (gcc is memory intensive) requires
those parts be locked. Ownership of the lock prevents other users
from accessing it. I have seen conditions where a single user can
crash gcc by running multiple compiles, but that's an OS issue.
> that filenames can be suffixed with the process id. (Yes, you can
do
> the same with NT.) Is it worth the expense of already valueable
disk
> space to stream copies of 20-30GB logs into temporary storage?
Who did this? Indeed is a wast of space. But temporary files are
not
on spliting files, but for intermediary results. Which are small
enough
to keep on disk between succesive processing but big enough to not
keep
it in memory.
If you want to be fair, just say the solution (whithout requiring
to
split files). I tell somtehing: just try to split 600M in chunks on
your
system and tell me if it not enter on trashing (supose you have
Linux,
I don't know how Solaris, HP-UX etc. handle disk buffers).
So, it's more practicaly to eliminate file spliting overhead. Again,
I
repeat it's a pain to split 600M or more. Seeking on file is only
read
so disk traffic is more reduced.
Also, as I said user can choose. If it want e.g UNIQUEIP options,
then
analog main parsing loop will take in account this. I don't know
analog
internals so I just make suppositions. If introducing this options
break many parts in analog structure, then it must be biased if must
be implemented soon or not at all.
====
I agree that UNIQUEIP[{hour}|{day}|{week}|{month}] would be a good
enhancement. My question is whether it is worth the major change to
an already very efficient program? You can achieve the same results
using a Perl script or a UNIX shell script that entails cut, sort,
grep and wc.
+------------------------------------------------------------------------
| This is the analog-help mailing list. To unsubscribe from this
| mailing list, go to
| http://lists.isite.net/listgate/analog-help/unsubscribe.html
|
| List archives are available at
| http://www.mail-archive.com/[email protected]/
| http://lists.isite.net/listgate/analog-help/archives/
| http://www.tallylist.com/archives/index.cfm/mlist.7
+------------------------------------------------------------------------
