>I have been running ASSP for 3809 days on Gentoo Linux. I don't think that V2 will run on this system, if it is really over 10 years old!!!
First check your system design. - at least 4 CPU cores - at least (absolute minimum) 2GB RAM on 32Bit Perl / 4GB on 64Bit Perl - use at least Perl 5.16.3 - the best unicode processing you'll get with Perl 5.20.1 - install possibly required software (OpenSSL is required) - this depends on which Plugins are used (ASSP_DCC: dcc, - ASSP_OCR: ImageMagick, tesseract, clobber/getpdftext/pdftk ) - install a database engine (BerkeleyDB, MySQL, Postgres, DB2, Oracle, MSSQL .... ) - you must be able to maintain this database (repair, backup, restore, configure) - install and configure ClamAV and/or if you want another Virus-scanner - make sure, you have at least two perfect configured and fast DNS-servers - some modules (eg. Sys-MemInfo, Crypt-GOST) available on CPAN could not be compiled on some systems - download and compile the version provided in the 'ASSP V2 module installation' folder on SF - run the assp module installer - bring all Perl modules up to date - follow the error descriptions if a installation failes (it could be possible that some modules must be 'force'(d) to install ! This depends on the Perl - distro) - on Strawberry-Perl and on ...nix systems - 'cpan-outdated -r|cpanm' or 'cpan --update' will do the tick. - if you install Perl modules via CPAN, make sure you use the same C-header files and the same C compiler like your perl distro! I recommend to compile Perl for assp from source additionaly, if you use any ..nix system. (don't forget to point assp to right perl installation!) - start assp and check the startuplog for warnings and errors - check the file assp/moduleLoadErrors.txt for errors - correct the errors or disable the modules in the assp config -> module setup section - move the main hashes to a database if the startuplog recommends this - configure the rebuild process to use a temporary database (useDB4Rebuild) >I can't use the schedule cron perl modules Schedule::Cron is only used by assp to calculate time values from cron entries. Only the rebuildspamdb and the restart scheduler are using this module 'really'. This module leaks no memory nor does it crazy things! Most of the assp code is loaded by all workers on request. Because of this reason, the memory allocated by assp will typical grow over 1 or 2 days after it was started. This is a normal behavior of V2! My assp starts at 370 MB memory - and allocates ~ 580MB < rebuild > 700MB after running 2 days and stays there. - 5 SMTP workers - Perl 5.16.3 - 32 Bit - using all features and all Plugins - 11.000 files in the corpus - takes ~ 30 minutes for a complete rebuildspamdb on a slow system 'Jan-24-15 04:32:38 Rebuild processed 6.85 files per second.' - spamdb: 400.000 records - HMMdb: 1.500.000 records - ClamAV at 400MB - MySQL at 450 MB - holding all main hashes and lists - Symantec EP 12.1.5 at 1GB >No clue why I need to move a 10yr old cron task to within perl via perl cron modules. No clue ??? - read the manual -> newReportedInterval This is because the rebuildspamdb task is a permanent running task in V2. Both databses are maintened permantly on request (spam/ham reports). The consolidated rebuildspamdb is required only once a day or even less. >Thus I have to log into the web interface daily or when ever just to rebuild the spam database. It could be done this way, but this is not required. The consolidated rebuildspamdb task (the same like in V1) could be run scheduled via configuration. If you want use the system scheduler for any reason - read the file (distro) assp\cmdqueue_example.txt. The SNMP interface (agentX) could be also used to control assp from outside. >The bugs and issues with ASSP are getting ridiculous. I don't know a big one currently. I'm running V2 for 7 years now - using the latest version every time. >When I do run that, it never finishes, maxes out the CPU, cores, etc for hours. The rebuildspamdb task is running a single thread only? And yes - this single thread could use a single core at 100% some times. Use the 'Worker Status' screen - it will tell you what is going on in the threads. To debug the rebuildspamdb task create the empty file 'assp/rebuilddebug.txt' before starting the task. This file will show details about this task. If you have to process a large corpus, it is a good idea to mount the 'assp/tmpDB' folder to a RAM-drive. Another solution would be, to used cached disk IO-system or a SSD. Simply follow the recommendations shown in the rebuild output (rebuildrun.txt). Thomas Von: "William L. Thomson Jr." <w...@o-sinc.com> An: assp-user@lists.sourceforge.net Datum: 23.01.2015 22:36 Betreff: [Assp-user] Stability and which version to run I have been running ASSP for 3809 days on Gentoo Linux. In the last few months ASSP has become VERY unstable. I understand the old single threaded code base is no longer being maintained. I was forced to move away from that due to a bug triggered by a newer version of Perl causing problems in SPF modules. The last single threaded version I ran was 1.9.9.14069. I have since switched to 2.4.3.14313 and presently 2.4.3.14349. Not sure if I need to go back to 2.4.3.14313. I recall having issues thus moving to 2.4.3.14349. Which the biggest issue I am having there is with rebuilding the spam database. I can't use the schedule cron perl modules, those are total crap and leak memory and other things like crazy. No clue why I need to move a 10yr old cron task to within perl via perl cron modules. Or why rebuildspamdb.pl has gone away and replaced with something you cannot invoke directly but have to from ASSP. Thus I have to log into the web interface daily or when ever just to rebuild the spam database. When I do run that, it never finishes, maxes out the CPU, cores, etc for hours. Some new bug and issue. The bugs and issues with ASSP are getting ridiculous. I have never seen such problems with ASSP ever as I have in the last 6 or so months. Its seeming that I might have to against my will be forced to use alternative software that does not have such stability issues. I am tempted to revert to 1.9.9.14284 and hope the issues with SPF are not there. Worse case I can disable that as I had to get some stability. I really cannot believe the amount of issues I am experiencing with ASSP. Why the move to multi-threaded, which seems to cause SERIOUS problems. Am I the only one having stability issues with ASSP? What version are others running? Anyone else seeing ASSP run away when rebuilding spamdb, and other odd errors? Anyone able to actually use the schedule cron modules and have that not leak memory and other things? I believe this might get version specific on stuff, version of perl, version of perl modules, etc. I have no problem providing what ever version information. I really hope ASSP can become stable again and the quality software I have depended on and ran for over a decade. I know quality is subject to debate, and I have never considered ASSP quality code per se. However it has served its purpose, been effective, and more importantly been stable for a very long time. I hope that can return sooner than later! -- William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.com This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Assp-user mailing list Assp-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-user DISCLAIMER: ******************************************************* This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the individual to whom it is addressed. This email was multiple times scanned for viruses. There should be no known virus in this email! ******************************************************* ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Assp-user mailing list Assp-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-user
