Hi Scott,

I too have got perl modules up to date although I am running on Ubuntu LTS
14.04 64 bit.

I only have the rebuild running once per day and only running from on of my
ASSP instances as they have a shared corpus.

The instance that was locking up was not running the rebuild at all and I'm
not seeing any out of memory errors.

I wonder if that is either unrelated or a different symptom of the same
problem.

Thinking on, I also saw two other issues around the same time. The first
was that I had to set the remote monitoring server to not use starttls
otherwise I kept get false down reports.

Last night when downgrading I noticed a lot of SSL renegotiations and SSL
want read first on larger messages but it haven't had time to investigate
those further.

All the best,
Colin.
On 11 Feb 2016 02:37, "Scott MacLean" <[email protected]> wrote:

> On 2/10/2016 11:31 AM, Grayhat wrote:
> >
> >> Any idea where I could start to try to figure out what is going on?
> > I'd try the following:
> >
> > stop assp
> >
> > remove the assp\sl-cache folder
> >
> > run a
> >
> > ppm update --install
> >
> > once the update completes run a
> >
> > ppm log --errors 60
> >
> > check for update errors, fix them and repeat the update; done so, start
> > assp from the command line and let it run so; this way, in case of
> > errors or crashes, you'll see the full message(s) on the console
>
> Thanks, I had tried this already - all my Perl modules are up to date.
> Running ASSP in a console shows nothing - no errors are emitted other
> than what is already being written to the ASSP log.
>
> On 2/10/2016 12:00 PM, Thomas Eckardt wrote:
> > Scott, what is your setting of  'useDB4IntCache' - I think it is set
> > to 'ON'. Switch it to 'OFF'and start a newer version. An restart is
> > required if, this value is changed!
> >
> > I think this has something to do with the BDB-tied STATS hash. This is
> > anyway corrupt, and/or assp is running in to BDB-deadlock.
> >
> > Tell me, if this change fixes the problem - you'll know it after 5
> > minutes.
> >
>
> My useDB4IntCache was already disabled - I am not running BerkelyDB
> (ASSP is running against a MSSQL server).
>
> I did quite a bit of work today trying to figure out what is going on.
> At first, I noticed that my server was showing as "not healthy" - and I
> could see why:
>
>
> *Spamdb* has version: *2_14315_5.020001_UAX#29_UAX#15_WordStem1.27* -
> required version: *2_14315_5.020001_UAX#29_UAX#15_WordStem2.01* ! Run a
> rebuildspamdb to correct this!
>
> Obviously now that I was running the newer version of WordStem, it
> didn't want to use my old Spamdb.
>
> So I tried to run a rebuildspamdb manually.  It got as far as:
>
> Feb-10-16 20:26:08 File Count:    15,000
> Feb-10-16 20:26:08 Processing... notspam with 15,000 files
> Feb-10-16 20:26:12 ignore files older than Dec-12-15 20:26:08 in folder
> notspam
> Feb-10-16 20:27:16 Imported Files for HeloBlackList:    15,000
> Feb-10-16 20:27:16 Imported Files for Bayes/HMM:    0
> Feb-10-16 20:27:16 Finished in 68 second(s)
>
> Feb-10-16 20:27:16 Generating weighted Bayesian tuplets
> Out of memory!
>
> The instant it wrote out the "Out of memory!" message, ASSP started
> writing several thousand lines of:
>
> Feb-10-16 20:27:57 [Worker_4] Warning: got unexpected signal SEGV in
> Worker_4: package - main, file - sub main::BombWeight_Run, line - 97!
>
> It then terminated with no error message - just exited without writing
> any error, either to the log or to the console.
>
> I suspect this may be what has been killing my server on a regular basis
> - I had rebuildspamdb running as a cron job on a fairly regular basis.
> Watching it run, the perl.exe process starts eating memory - beginning
> at around the 500MB that ASSP normally uses, and steadily climbing
> during the rebuildspamdb process to about 1.5 GB. When it gets to
> "Generating weighted Bayesian tuplets" it very rapidly climbs to 1.9 GB,
> then ASSP terminates, without completing the RebuildSpamDB process.
>
> This is a fairly heavy duty server, running 64-bit Windows Server 2008,
> with 16 GB RAM. However, I have never been able to get ASSP to run
> successfully on a 64-bit version of Perl, so it is running on the x86
> version of ActiveState Perl.
>
> I think ASSP is just running out of memory when doing rebuildspamdb,
> which causes it to terminate. This would also explain why I'm suddenly
> getting far more uncaught spam than I used to - my spamdb hasn't been
> updated in a while.
>
> I think my solution is to reduce my spam and notspam folders down from
> 15,000 files, to make it somewhat more manageable and reduce memory
> usage? Unless you have a better idea?
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Assp-test mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Assp-test mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/assp-test

Reply via email to