Pressing on to delve into another part of the project ...
Again another grep script in the same vein worked very hard for about twenty
minutes and then
disgorged the original target file in its output, using an increment of 4.7GB
of RAM. Even with
the target file moved into the working directory ... so that workaround
failed.
Faced with no alternative, this lazy semi-geek condensed the target file to a
simple one-column
list (which he ought to have done at the outset) and re-ran the grep script
on the condensed target,
with the happy response of a slowly rising output file (rising in kB
incrementsrather than multi-MB),
the same RAM usage (the additional 4.7GB), and usage of 520kB of SWAP, which
it had not done before.
Grep again took about twenty minutes to accomplish all this.
Grep was clearly going through the same motions each time, but somehow its
actual output has gotten
overwritten in the first instance, but was protected in the second run. The
target file was 63.5MB
in the first run and still 26.5MB the second time, but now the output file
has real grepped data
without superfluous material, about 3MB and 71,000 rows of non-duplicated
matching PTR's.
One difference between yesterday and today is that the pattern file now has
nearly 4,000 hostnames.
What should I be seeing with the terminal ? dmesg |tail or dmesg |more