Re: [Declude.JunkMail] OT: MaxDSNSize

[Matt]

I'm just going to cross-post this from the o.e.support newsgroup, but unless there is interest here in more of this, I'm just going to avoid updating this thread. ------------- Sandy, I started testing by using the following:     ...\Services\InetInfo\Parameters\PoolThreadLimit    200     ...\Services\InetInfo\Parameters\ThreadTimeout 600     Specifies the amount of time an input-output processing thread     should be maintained even if there is no I/O activity on the     system. In general when there is no I/O activity and no requests     outstanding the server is idle and does not consume memory. But     if that situation continues and exceeds the ThreadTimeout     interval, then the thread is stopped. Units are in seconds. The second setting seemed to make sense, though I'm not sure that it solves anything and I'm not sure if it has any consequences yet.  By default IIS will keep treads open in an inactive state for 24 hours; I set mine to 10 minutes. I noted in the documentation that MaxPoolThreads defaults to 2 x memory in MB, so on a 1 GB system that should be 2048.  I'm not sure that this needs to be tweaked. It also seemed to be redundant to specify both the PoolThreadLimit and AdditionalPoolThreadsPerProc.  Both would seem to work, though the documentation indicates that PoolThreadLimit should be increased if AdditionalPoolThreadsPerProc results in a number over 200.  Since I am tuning a server specifically for a purpose, I avoided the thread additions by way of the SMTP specific setting and just gave IIS as a whole more threads.  By default SMTP will use 90% of the available pool if required. I didn't look at ListenBackLog and MaxConcurrency.  I did just look these things up in relation to IIS 6.0 and here's what Microsoft says:     ListenBackLog (Default 25)     Specifies the maximum number of active connections to hold in     the queue while they wait for server attention. Enhanced IIS     functionality generally makes it unnecessary to use or modify     this entry, although extremely heavy traffic might benefit by     increasing this value up to 50.     MaxConcurrency (Default 0)     Specifies the amount of concurrency that a system should     provide. IIS uses completion ports to handle input-output (I/O).     In general, have more than one thread running and conflicting on     shared memory or locks. This key specifies how many threads per     processor should be allowed to run simultaneously, if there is a     pending I/O operation. A value of 0 allows the system to make     the intelligent choice of the number of threads to use. Any     nonzero value specifies that the system should allow that many     threads per processor to run simultaneously. Honestly, I'm not sure that these should be changed based on reading the IIS 6.0 info, though IIS 5.0 had slightly different settings/recommendations by default. After one full day of running my same old setup with tarpitting on, I did find that a PoolThreadLimit 200 resolved my issues on it's own.  I did recommend though to Peter that if he was to promote changes, he might use AdditionalPoolThreadsPerProc, but on further review, since this requires a change to PoolThreadLimit if that number is over 200, I'm thinking that tweaking PoolThreadLimit is the way to go. I haven't tested actual throughput or simultaneous connections, but considering that most of the open threads are just tarpitted and waiting to deliver a 5xx error, I'm not sure that changing ListenBackLog or MaxConcurrency is necessary, or what the right values would be if it was.  If I was using MS SMTP to pump out bulk mail at top speed, it would seem that increasing at least ListenBackLog would be of benefit. FYI, I'm running three instances with max connections for each set to 25, and my Event log does show when this limit is passed, and it doesn't happen but a few times per day even though there are over 200 domains serviced, but none of these instances are serving my primary MX. So to summarize, you can definitely tune the threads and achieve many more connections without creating issues for FTP or unresponsive SMTP connections, and the defaults in Windows seem way too low for this sort of use.  I would recommend changing just PoolThreadLimit to a value that is about 20 above the number of simultaneous connections that your MS SMTP instances allow, and those should be set to a reasonable number. I'm reserving judgment on the other settings because it would seem to take a lot of testing to figure out for sure what is best for this particular use and it seems to be working fine for this use without tweaking them. Matt Sanford Whiteman wrote: I have not yet tested out any changes to the threads. It seems that people don't want to discuss it. Oh, I'll discuss it. . . but I don't really don't know why the burden of proof fell my way, rather than this stuff being investigated _before_ declaring without real testing that MS SMTP isn't scaleable. With the following entries: ListenBackLog 200 MaxConcurrency 200 MaxPoolThreads 200 PoolThreadLimit 256 AdditionalPoolThreadsPerProc 100 I am able to have open up to 137 receive threads on an Athlon 64, 512 MB RAM, 2 x 7200 RPM SATA RAID. It's clear that the claimed bottleneck doesn't exist when a system is properly tweaked. People testing this further must be aware that IIS SMTP dynamically balances connections between I/O completion ports alone (which have less overhead than threads, but which cause thread starvation if used exclusively), and full-fledged threads together with I/O completion ports. This dynamic adjustment is why you should not expect an arithmetic relationship between the number of connections and the number of threads. It can be difficult in a low-end laboratory setup the long-lived connections necessary to force the uptick in allocated threads. You may think you're testing properly, but the server is actually closing and opening the connections in pace with the clients, so it never has a need to allocate more threads. But when the need is there, and the Registry maximum thresholds have been properly extended, the threads will be made available. I'm not bothering to test the IIS FTP service vis-a-vis this information, since I don't use that service. My mission was to prove that MS SMTP can flexibly expand its thread pool beyond the default limit to account for long-lived connections. Q. E. D. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- [This E-mail was scanned for viruses by Declude EVA www.declude.com] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.