Well, it's been one week and we're almost halfway to our goal of $300. Sadly, the donation drive ends at 2359 EST tonight and I don't think we're going to make that. However, we've got enough to make the move and go for a month or two. This doesn't mean that we're not going to move. Quite the contrary, we're going to move so we can more easily handle the amount of traffic we've been getting.
In other news... Happy Birthday to Me! Yep, at 0000 Saturday, March 15 I turned 30. In related news, this birthdate is also shared by Phil Geusz, but I'm not sure how old he is.
After that OOM episode on the fifth, I started looking at what options existed for high-availability hosting for Shifti. After much discussion and weighing of risks I still hadn't been able to make up my mind as to what to propose to the other admins. So I talked to Viqsi about the options and she agreed that the best option would be to get two low-cost servers and then split the load between them.
What this means for Shifti is that, depending on the currently running donation drive, the site will be on its new servers no later than the seventh of April. What this means is that there will probably be a period of downtime, hopefully not more than two hours, while the database is backed up, transferred to the new server and restored. If you'd like to see Shifti make the move to the new servers faster, you could always donate some money—there is a link in the nifty banner at the top of each page.
And there we go... Not even five minutes ago the server went "OOM" (that is, it ran out of memory). This is because the server is an old system, mostly. It's a P3/800 with 768M of RAM. If I had the space in the box I'd install another hard drive and allocate more swap space, but...
While Jon Buck has graciously offered to donate his old computer as a new server the problem is that even that will probably not help the problem much. But just replacing the server will be a stopgap measure, since we are approaching the limits of even the upgraded bandwidth that the readers donations have paid for. Tonight I will be discussing a complete move to a server hosted by ServerBeach with the rest of the administrators and that will probably lead to another ugly donations banner.
There is apparently enough traffic that MySQL's setup - which was already set at double the defaults - started having all kinds of problems. So I've gone and doubled it's settings yet again. At the same time I've done some poking at Shifti's configuration and upped quite a few of MediaWiki's internal settings. Hopefully this will make the site a bit more stable, but if things don't work out, we will have to start planning a move to ServerBeach.
Shifti has reached a level of traffic that I am not sure the server will be able to continue to manage. We are reaching anywhere from 80 to 100 megabytes of bandwidth use a day - an average of more than 200 unique visitors and 10,000 hits per day. Truthfully, the server will probably scale up to more than the current level, but the default for Apache is a max of 20 simultaneous requests and I have changed that to 50.
In other news, after all the work he did to get it into a state where it wouldn't cause the server to choke, we have had to delete the "All In One" version of Michael Bard's "Mythic Journeys" because it was causing some parts of the system to slow down during database accesses.
Anyway, it's time for me to go back to making sure that Shifti stays online and stable. :)
We've just had our first story posted that exceeded the size that Shifti could handle in a single page; Michael Bard's 737000-byte "Mythic Journeys", now split up into two separate pages for your convenience. I consider that to be an interesting landmark of a sort.
After checking the software and the error message that Bard saved I can safely report that he managed to hit a bug in the MediaWiki software itself and the way the parser works. A 737000-byte story without any "extension" tags (like "poem") would not have hit this problem. In fact, the MediaWiki software itself has a hard limit of 2048 kilobytes — that's 2 megabytes — on article size. What happened in this case is that the article text got duplicated and stored in enough places that
Old News 
|
Old News 
