http://bugzilla.spamassassin.org/show_bug.cgi?id=2114
------- Additional Comments From [EMAIL PROTECTED] 2004-02-15 17:54 ------- ok, let's step back a second... there are 2 issues here as far as I can see: 1) sa-learn mode in ArchiveIterator causes the list of messages to use to be stored in memory ... So sa-learn first goes through all the files, finds the offsets for each message, and stores that in memory plus some metadata. So if you're learning a huge # of messages, that can be pretty big. 2) expire/update and the various hack atime reset code were using foreach() in earlier versions of SA, which caused (iirc) a temp array to be created in memory with the full list of tokens in the DB, which can be pretty big too. #1 still happens, but you don't seem to be getting OOMed at that stage. #2's expiry/etc issue was fixed somewhere in the 2.6x series (2.62 I think), and the atime hackery is no longer done post 2.5x. So I guess what I'm trying to get to is this: Does the problem still occur with 2.63? If you can, does it occur with 3.0.0? If it still occurs, we'll have to do a bit more debugging. #1 is easily solvable, at least on UNIX -- we already do it for mass-check runs (store the list of message offsets in a temp file and do some fork() fun to avoid the memory hit over the learning period). It's sort of a hack, which is why it's not the default for sa-learn. But I'm guessing this isn't your problem. For me, the storage for ~200k message offsets only adds ~60MB to the process memory usage in testing/mass-check. If #2 is occurring... more debugging. ;) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
