SAWMILLFORUM

Thanks for the rcrt switch, that was greatly appreciated! I'm building on a Linux box, the logfiles are all gzips and left compressed, it's just each one expands to about a 250M file and they date back to 2004, so it takes a while to crunch through, I imagine I'm just hitting I/O and CPU limits.

I didn't get any errors during the build, it seemed to build OK. Awkwardly, I kicked it off from the web interface and someone then unplugged the network cable on me, so I ended up just following the build by viewing the IPC/ file for the task directly.

It's crunching through the xref stuff now, so hopefully that should sort out the first problem, then I can attempt another update. Previously it just stopped updating, cutting off at May 17th, despite all the logfiles being present and read by sawmill during an update. The session overview thing had stopped working as well, so I imagine something was corrupted in some way. Doing updates from the command line showed no errors, so I was out of ideas apart from a full rebuild.

I think sometimes what happens is that a build or update is already running, and someone triggers a second one, and rather than detecting that the database is being modified, it tries to start a second one anyway. I wish I could maybe get sawmill modified to create a lock file so that can't happen.

Sawmill 7.1.9; Copyright (c) 2005 Flowerfire
#### Internal Error: Unknown progress step 'building_xrefs_separately'<br /><pre>
Error occurred at: : Sf164d383f8fd9c8770b7f012c7bedb96.cpp:246
</pre>

Cheers,

Sam
samuel.martin@hp.com

I dumped the database, built from scratch, then tried to get the sessions to work again. Now I get:

Can't open file LogAnalysisInfo/ReportCache/jessops/SessionCache/c113cb3e049e13d2120c2b96ab6e854d/page.expanded (mode=wb) (No such file or directory)

; Error occurred at: : /tulip1/sawmill/v7/production/src/utilities.cpp:2464;

This differs from yesterday, when it gave me an out of memory errors, despite the RSS being around 400M and the box having 3G.

Anyone seen these before?

As an initial step in testing if this is the case, please try zooming in on a single day, than *then* doing a session report. If that works, but an unfiltered report does not work then this is probably an out-of-memory condition.

We recognize that it's somewhat outrageous that Sawmill requires gigabytes of RAM for this analysis, and we are working to move the session analysis to disk, to fix this problem. In fact, that latest internal code for Sawmill 7.2 includes this feature--session analyses are done primarily on disk, rather than in memory. This is highly experimental at this point, and I couldn't possible recommend it for a production environment, but that's the long-term solution: Sawmill 7.2 will fix this excessive memory usage issue (and a few other excessive memory usage issues as well).

If you try with a one-day filter, does it work?

I did however try with a single day and got:

3. Generating report (1) nan% 00:00:00 00:01:29

It stuck at nan% forever. I'll try it again with two days, see if that makes a difference.