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

Reply via email to