If anybody notices anything that doesn't work properly, please let me know by email. If the mail server doesn't work, please send an SMS text message to my mobile phone: +49 179 3217777

2008-12-12 02:30-04:30 UTC

The Apache web server became very slow after an overload around 20:12 the previous evening. It was restarted at 05:20. During the time span given above the server nearly stopped answering.

I tuned the Apache configuration to make the server resilient towards overloads; reduced Apache2 setting MaxClients further, from 64 to 32. Note that this does not lead to reduced performance, as each task processes queued HTTP requests. It is likely that fewer tasks yield a higher total performance.

We will get a new, much more powerful server in April anyway, so I will not put much effort into tuning now.

2007-12-24 10:26-10:30 UTC

The Apache web server hung after a configuration change and had to be rebooted. Cause unknown, probably some bug in the Confixx software. Not critical, because the administrator who triggers the problem will immediately notice and take corrective action. The mail server appears to have been working all the time, except during the actual reboot.

2007-12-08 12:??-13:20 UTC

Server was down. Investigating cause. A possible cause is that a server overload causes thrashing due to too many web server tasks (httpd2-prefork) exhausting physical memory and making the server extremely slow. Reduced Apache2 setting MaxClients from 150 to 64.

Fortunately this happens only rarely, but I'm considering to set up a log trap to find out what exactly is happening in these rare circumstances.

2007-11-21 21:00-08:00 UTC

Our server moves from Düsseldorf to Frankfurt and gets an even faster Internet connection. Unfortunately it has to be switched off, transported, and reconnected.

2007-11-14 04:00-08:00 UTC

The server was down due to a MySQL database table corruption, possibly caused by a hard server reset on 2007-11-08 (see below). The server was working through that week in spite of the error, but last night a burst of spider accesses brought it down.

I could unambiguously locate and repair the defect, along with a few other glitches. The server is running fine now.

2007-11-08 18:30-19:30 UTC

Slowly progressing server failure, probably caused by an endless loop I mistakenly programmed into the Apache rewrite module commands. The server was slowly brought to its knees when the number of simultaneous processes, mainly an excessive number of Apache web server processes, exceeded 340. A more normal number for all processes is 80, including about a dozen Apache web server processes. A soft reset was tried, but took too long. After an hour I did a hard reset.

At least this shows where the limits of our server lie, namely around 300 processes. I'm not sure our server could handle 200 simultaneous users though, at least not when they all hit the CMS. But no worries, an upgrade to a much more powerful server is in the cards and will happen when needed.

2007-11-04 09:00-11:00 UTC

Moved the entire system to the same virtual server that carries elephanttrust.org to save one virtual server, to join the two domains .org and .net, and to unite the web and mail servers. Moved elephanttrust.org into a subfolder.

2007-10-19 16:00-17:00 UTC

Upgraded from Drupal 5.2 to 5.3.

2007-10-17 13:00 UTC

I have raised the spam defenses a little. Our mail server will now become lazy and slow when it detects one of the following:

1. Two or more incoming connections per second are attempted.
2. Another computer tries to deliver more than three emails to recipients that are unknown or otherwise erroneous on our server.

If you notice any problems with your email, please let me know.

2007-10-14 12:00 UTC

There was a sporadic problem with our mail server overloaded by spammers, who apparently deliver their warez in bursts through multiple parallel connections.

With some bad luck you may have hit one of those streaks once or twice, but it was always temporary and resolved itself after a couple of minutes. It also only inhibited sending mail, never receiving. But since most email client programs send first and then receive, you'd hit the error before the program would even attempt to receive. Trying to receive only would have worked.

I have worked on that and increased our intake capacity from 15 simultaneous incoming mail streams to 60. I've seen even these exhausted once, apparently by a Russian spammer, but the server remained responsive throughout. I repeatedly checked my mail and never saw an error since the change.

2007-10-04 11:45 UTC

After over two months of perfectly smooth server operation we had a total hosting provider failure that lasted several minutes, but less than half an hour. Not only our web site and mail server went down, but all other users and web sites as well.

The mail failure is not critical, as senders' mail servers will keep your incoming mail and retry the delivery. No mail got lost.

2007-07-30 6:10 UTC

We're now running on Drupal 5.2, up from 5.1. The upgrade took 1 h 10 min.

Until 10:50 UTC we still had an error affecting images, since repaired.

2007-05

This web site started its life in late May 2007, but didn't really get used much before July 2007.