Mailman throwing lost-datafile errors with every message

Jun 24 15:49:39 2004 (353) lost data files for filebase: 1088100914.7161551+9a9200d2cba7be877a02453e1f812069b0c78761 <rinse and repeat about once a second> Mailman 2.1.2 (I'll upgrade if you INSIST...) Python 2.2 SunOS eh.net 5.7 Generic_106541-24 sun4u sparc SUNW,Ultra-5_10
I've been getting this line thrown in my error logfile frequently. Additionally, mailman has about 1200 files open when the (aging) computer locks up after taking quite a bit of abuse (it tends to end up with the CPU at 100% iowait, out of swap, with more processes running than is healthy. (The machine only has 256 megabytes of RAM-- and the replacement server was initially due to arrive over a month ago, but Hewlett-Packard has delayed that date to about a month from now).
I've seen this question asked before somewhere in the archives ( http://www.mail-archive.com/mailman-developers@python.org/msg06528.html ) but the (very limited) answer does not seem to have helped.

At 4:17 PM -0400 2004-06-24, foobar@eh.net wrote:
Upgrading to 2.1.5 may help solve this problem. Certainly, this
is one of the issues that Barry mentioned in his message at <http://mail.python.org/pipermail/mailman-developers/2004-January/016396.html>.
However, before you do that, you might want to try Barry's other
suggestion in this message, namely to enable SYNC_AFTER_WRITE. It may (or may not) kill your performance, but it may help you avoid these errors.
Out of curiosity, have you added the "logging" option to your
filesystem mount where you process mail? My experience is that this helps improve the performance of systems running Solaris 7 and above, and will greatly reduce/eliminate your time to run fsck when you're booting the system.
Of course, replacing the filesystem with Veritas VxFS would be a
bigger performance improvement, as would replacing the disk subsystem with an external high-performance RAID array, but these are not likely to be options you can take advantage of.
If possible, you should increase the amount of swap on the
system. You probably can't make any hardware upgrades in your current condition, but I'd be surprised if you can't add more swap space, even if the new swap space is not contiguous with the old.
That might at least help you survive the problems a bit better.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.

At 4:17 PM -0400 2004-06-24, foobar@eh.net wrote:
Upgrading to 2.1.5 may help solve this problem. Certainly, this
is one of the issues that Barry mentioned in his message at <http://mail.python.org/pipermail/mailman-developers/2004-January/016396.html>.
However, before you do that, you might want to try Barry's other
suggestion in this message, namely to enable SYNC_AFTER_WRITE. It may (or may not) kill your performance, but it may help you avoid these errors.
Out of curiosity, have you added the "logging" option to your
filesystem mount where you process mail? My experience is that this helps improve the performance of systems running Solaris 7 and above, and will greatly reduce/eliminate your time to run fsck when you're booting the system.
Of course, replacing the filesystem with Veritas VxFS would be a
bigger performance improvement, as would replacing the disk subsystem with an external high-performance RAID array, but these are not likely to be options you can take advantage of.
If possible, you should increase the amount of swap on the
system. You probably can't make any hardware upgrades in your current condition, but I'd be surprised if you can't add more swap space, even if the new swap space is not contiguous with the old.
That might at least help you survive the problems a bit better.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
participants (2)
-
Brad Knowles
-
foobar@eh.net