That what I suspected. Now that you mention it, I did have some write inefficiencies configured (lacked write caching) that have since been corrected. I just tested again, and results were much better, more like what I would expect. I think the writes were what was clobbering performance.
If you have a look and don't see any inefficiency, I'd leave it alone. I like thorough integrity checks. :) Thanks for everything, Sam. -- -Eric 'shubes' Sam Clippinger wrote: > I'll take a look at the code to see if there's anything wrong, but it's > likely there's not a lot I can do about this (except make the test less > comprehensive). The graylist test looks at every folder and file > individually, examines permissions and tests writeability. Since the > goal is to identify problems with the folder structure, I tried to make > it as thorough as possible. The pruning script, by comparison, is only > looking at the dates on the files and folders, so it can run much faster. > > -- Sam Clippinger > > On 7/9/10 11:23 AM, Eric Shubert wrote: >> I notice that the --config-test option is painfully slow with a graylist >> of any size. I just ran it with a graylist of<5000 entries, and it took >> several minutes. It did finally finish fine, so it's not much of a >> problem. In comparison, qtp-prune-graylist ran against the same graylist >> in 8 seconds, although to be fair some entries were undoubtedly still >> cached. >> >> Just wanted to let folks know that it is indeed slow, so give it some >> time. I did notice at the time that top showed a high cpu wait >> percentage, so it's I/O bound no doubt. Sam, you might want to have a >> look at this when you get a chance. Low priority though. >> >> Thanks. >> >> _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
