Marc Perkel schrieb: > > Martin A. Brooks wrote: >> Marc Perkel wrote: [...] >>> Disk IO is not real heavy. It has a reasonably fast SATA II drive >>> that's not very full. Writes about 3 gigs of log file entries a day. >>> >> A server with _one_ disk? > I have 2 drives in this server. You should have learned a bit or two by now.... like giving precise problem descriptions.
Anyway, you still believe that your problem might be related to the number of tcp-connections. I suppose anyone else has a different opinion and thinks about disk-IO. I suppose you don't really understand disk-IO, otherwise you wouldn't mention "fast SATA II drive that's not very full", since capacity and used vs. free space are totally unrelated to email-server-performance If you have a raid-1-configuration, all your writes are limited by the disk which happens to react slower. For each message actually passing through your system you have to write at least two spool-files once and update the inode-tables regarding creation and deletion of those files. However, a certain percentage of messages might need updates to their state, for example if they have ten recipients which can't be delivered at the same time. Oh, and if you use a journaling filesystem, don't forget the journal. Logfiles should not be synced to disk immediately, so there are fewer transactions, but still, there are at least several IO-transactions to disk for each message. I don't count various exim-databases and locking-issues, since they can be handled by RAM. Any swapping, by the way? Now, the number of transactions per seconds a hard-disk can support is surprisingly low. Standard-reactions to disk-IO-problems would be to use different disks at least for exim-spool and exim-log, but I you are serious about that you would probably use one raid-1 for system, one raid-1 for spool and one raid-1 for log. Thus the number of transactions would be spread across severals disks. Even better: decent(!) Solid-State-disks can perform much more transactions than "normal" disks. Their lack of capacity is usually no issue for a setup where e-mail is only passed through. Net-IO might be an issue, e.g. a slow DNS-resolver. But as a long-time-list-member you know about the value of a local caching nameserver.... I can't stress enough how important it is to have long-term-statistics which can help to investigate performance-problems. I constantly advocate using munin to monitor your systems. Currently it looks like you thought "hey, load is strange", did some counting, found some unexpected number related to TCP and now you can't think of any other possible explanation/reason for your problems. But if you had some decent statistics, you might realise that this value has been perfectly normal for the last 10 month and is unlikely to be the reason of current problems, so you would neither waste our time, nor yours. PS: Just as an example regarding disk-IO: if you consider a MS-Exchange-installation and call in some consultants to calculate the required hardware-setup, they will usually ask questions like "how many users?", "how many messages sent/received per time-unit?", "Expected speak-volume?", etc. Then they calculate the number of concurrent IO-transactions required for decent performance, and based on that number they calculate how many disks are needed. Then they consider raid (either 1 or 5) add some spare-disks and tell you a huge number of disks. Then they ask you how much storage should be available to each user and THEN they will calculate the required size of each disk. I don't think it is unlikely to end up with 100 disks of 160GB each.... -- CU, Patrick.
smime.p7s
Description: S/MIME Cryptographic Signature
-- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
