Saddam Hussein is dead, hanged at dawn in Baghdad for crimes against humanity.

Posted by: Pixy Misa at 12:31 AM | Comments (7) | Add Comment | Trackbacks (Suck)
Post contains 29 words, total size 1 kb.

That's me they're talking about.

And then they segue into a discussion on Ghostbusters. These girls rock!

* And the rest of it too. Uguu!!

Posted by: Pixy Misa at 05:49 AM | Comments (2) | Add Comment | Trackbacks (Suck)
Post contains 40 words, total size 1 kb.

Simple Server Monitor is what it says. It monitors your servers - on ping, HTTP, SMTP and/or POP - and screams like a stuck parrot if anything goes down.* It also plots little graphs of response times. Not fancy, but it fills the immediate need.

I also tried out Spiceworks, which is kind of neat, but really designed for monitoring small office networks. It's written in Ruby (using Rails), and runs in the background, accessed through your browser. For a Web app, it's pretty neat, though for a monitoring system it gives me a great deal of information I don't want. Doesn't seem to like monitoring the web servers, either.

Zenoss is probably quite good if you work with SNMP 7 days a week. Otherwise, avoid. The simplest way to set it up involves downloading a pre-packaged virtual machine and running it under VMWare.

PortSensor is another simple monitoring tool, but a very flexible one since you can have it execute custom shell scripts remotely via SSH and process the results using regular expressions. Naturally I'd rather not do any of that, and it doesn't have any particularly significant functionality built in. It's more a sort of monitoring toolkit.

Simple Server Monitor I'm keeping until I find something better; the others have hit the bit bucket.

* Well, that last is due to the alert sound I chose.

Posted by: Pixy Misa at 07:56 AM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 256 words, total size 2 kb.

Except that the default table pointer size is 32 bits.

And it seems that changing it from 32 to 40 bits slows database writes by about 10%.

Not that I will necessarily be using MyISAM. What I was doing when my table hit 4GB was finding out whether to use MyISAM or InnoDB.

Well, off we go again. About 4500 inserts per second right now (at one record per query, which is far from the fastest method, but is after all what the application will be doing).

Posted by: Pixy Misa at 09:57 PM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 116 words, total size 1 kb.

Crap.

Posted by: Pixy Misa at 12:20 PM | Comments (1) | Add Comment | Trackbacks (Suck)
Post contains 30 words, total size 1 kb.

• A laser printer.
• A rubber ducky.
• And a winning lottery ticket.

...

Ooh, thanks Santa!*

* Okay, so it was not a very winning lottery ticket...

Posted by: Pixy Misa at 05:57 AM | Comments (5) | Add Comment | Trackbacks (Suck)
Post contains 34 words, total size 1 kb.

And then I went and had dinner, and read a book, and read some blogs, and had some ice cream, and then came and posted this. Because IronPython has a leetle performance problem relative to CPython**; or rather, it lacks at least one very important optimisation from CPython. See if you can spot what it is:

Source code for the benchmark can be found in my earlier post.

* Again; I had it on my old notebook, but that got reformatted and reinstalled at least four times, and in any case I no longer have it.

** The standard version of Python, which is written in C. more...

Posted by: Pixy Misa at 11:57 AM | Comments (1) | Add Comment | Trackbacks (Suck)
Post contains 325 words, total size 2 kb.

Posted by: Pixy Misa at 11:12 AM | Comments (4) | Add Comment | Trackbacks (Suck)
Post contains 42 words, total size 1 kb.

Posted by: Pixy Misa at 10:11 AM | Comments (3) | Add Comment | Trackbacks (Suck)
Post contains 8 words, total size 1 kb.

Spam flood. Double spam flood, in fact - blog comments and incoming email.

Fluffy wasn't running, and Apache took over the machine, and then exim took it the rest of the way. By the time I logged in it was using nearly 100% of swap.

Posted by: Pixy Misa at 01:07 AM | Comments (1) | Add Comment | Trackbacks (Suck)
Post contains 65 words, total size 1 kb.

Posted by: Pixy Misa at 03:14 PM | Comments (2) | Add Comment | Trackbacks (Suck)
Post contains 10 words, total size 1 kb.

Hope they do a good job.

Steven:

There's something very strange about the visitor counter at the top. When I visit it with IE, right now, it said 000816. Revisiting it a few minutes later it said 000823. But when I visit it using Firefox, it said 172600. A bit later it said 172661.

Yes indeed.

Posted by: Pixy Misa at 09:43 AM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 59 words, total size 1 kb.

Over the last few months, the frequency of my visits to the Junk folder have increased to every day, then to two or three times a day, then every two or three hours. Even though I have filters set to auto-delete the obvious crap, I'm getting something like 2000 emails a day, 99% of them spam.

No more.

Today I set SpamAssassin to auto-delete at 9, and set the value for BAYES_99 to 7. (I'm tempted to bump that up to 8.8.)

Unfortunately, since I monitor email for all of mu.nu - bounces, abuse reports, that sort of thing - I need to receive things that set off a lot of normal spam flags. I don't want to, but if I don't keep an eye on things then sooner or later I'll be hearing from our hosting company. (The PHP spam incident I refer to below was one that I caught and fixed without anyone at SoftLayer being troubled because I saw the sudden increase in bounce messages.)

Fortunately the Bayesian filtering in SpamAssassin seems to be very reliable, and a 99% rating plus two points worth of other spammy traits will now relieve me of ever seeing the message. I've seen valid messages get Bayes ratings of 40 or so, but that won't get zapped unless you're doing a lot of other things wrong.

Seems to be working. I'm still getting the occasional spam through to Thunderbird - at a setting of 9, SpamAssassin doesn't catch those blasted PHYA pump-and-dump spams - but most of it is then gets eaten by my filter rules.

And a blessed peace descended upon Pixy Central...

Posted by: Pixy Misa at 01:11 AM | Comments (4) | Add Comment | Trackbacks (Suck)
Post contains 349 words, total size 2 kb.

Spammers who sneak in through PHP errors,
Hackers from Turkey spreading their brand of terrors,
Disk drives that die when they're put to the test -
It's Christmastime, guys! Won't you give it a rest?!

Posted by: Pixy Misa at 07:59 PM | Comments (3) | Add Comment | Trackbacks (Suck)
Post contains 64 words, total size 1 kb.

This matters to me more than most because I run VMWare Server on my notebook, and when I'm not connected to my wireless network I can't connect to my virtual Linux server either. Even though it's running on the same box.

So what I did was this: I installed the Microsoft Loopback Adaptor, and bridged it to my wireless network. So now, with or without wireless, I can still reach my server.

The only problem is, Windows now tells me that my wireless is disconnected. And if you go into the wireless networks screen, right below where it says "Not connected", it has a Disconnect button to disconnect the unconnected network.

Apart from that, it works fine.

I was having trouble mounting the Samba share from the virtual Linux server back to Windows, but that was because Plesk doesn't (or at least, didn't) automatically apply its firewall rules after a reboot.* Quite possible something I did wrong, but certainly confusing.

Plesk also has a nicely confusing way of managing your Samba shares; it adds an include file to the standard smb.conf, puts the shares it's managing in there, and ignores what's defined in the main file. That might actually be the best way to handle things, but it ain't obvious when you run into it for the first time.

I also set up a PPTP VPN to SoftLayer from my home network. That lets me manage the servers even if the regular public network at the hosting company is down (the VPN goes through a dedicated Cogent link); it lets me run backups without touching by 4TB/month bandwidth allowance; and it lets me do things like check on CPU temperatures and voltage levels in the servers. And do both soft and hard resets, if I should feel the urge. Without even opening a browser window!

* Yes, I have a complete web hosting management system installed on a virtual machine on my notebook.

You mean to say you don't?

Posted by: Pixy Misa at 11:25 AM | Comments (1) | Add Comment | Trackbacks (Suck)
Post contains 368 words, total size 2 kb.

Nnnnot really.

WELL, IT'S HARDLY A BLOODY BOOT LOADER, IS IT?!!???!!?

Look, if you go to my brother's computer shop in Padstow, he'll replace the operating system for you.

Okay, so after all that, it just sits there saying GRUB. Remarkable boot loader, GRUB. Beautiful plumage.

I don't think it liked booting from a software mirror for some reason. FC5 was perfectly happy with it. CentOS 4.4, on the other hand, promptly joined the bleedin' choir invisible.

Excuse me, this is irrelevant, isn't it?

Yeah, well it's not easy to pad these Python files out to 150 lines, you know.

See also: This.

Posted by: Pixy Misa at 02:32 AM | Comments (3) | Add Comment | Trackbacks (Suck)
Post contains 115 words, total size 1 kb.

I brought the FC5_x64 DVD with me instead of FC5_i386, but what the heck, the machines are 64 bit and it's officially supported by the software I want to install, so roll with it.

So I install FC5, and then I install the software I want to install, and it gets allll the way through downloading and installing itself and falls over with three dozen version conflicts in various RPMs.

So now I'm reinstalling CentOS 4.4, which is the only other Linux I have on me, but which I know definitely works. Unfortunately, all I have is the CDs, so I have to sit here swapping them back and forth between the machines.

The best part is when, two minutes into CD #4, it asks for CD #1 again. When CD #1 is in another machine.

Pfui.

Posted by: Pixy Misa at 02:11 AM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 145 words, total size 1 kb.

Posted by: Pixy Misa at 12:04 AM | Comments (11) | Add Comment | Trackbacks (Suck)
Post contains 18 words, total size 1 kb.

...

They're 2GHz Athlon 64 X2s. The results are Exactly. The. Bloody. Same.

I guess that 2GHz Athlons are the baseline for decent performance, for either desktops or servers. But I got my first one in 2003! Okay, so the new ones are 64-bit and dual core (and about 40% cheaper, from memory), but still...

Posted by: Pixy Misa at 12:02 AM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 90 words, total size 1 kb.

And trusty steed.

Posted by: Pixy Misa at 11:25 PM | Comments (3) | Add Comment | Trackbacks (Suck)
Post contains 20 words, total size 1 kb.

Posted by: Pixy Misa at 02:20 AM | Comments (11) | Add Comment | Trackbacks (Suck)
Post contains 28 words, total size 1 kb.

Doh!

Yeah. That one might work.

Update: The art of helpful commenting:

# code duplication because ow.

Update: Yuggech.

Okay, so it's been a while since I installed the standard BitTorrent package on Linux.

The last time I did so was 4.0.something. The current release is 5.0.3.

4.0.x required Python 2.2 or later.

As for 5.0.3:

* Install Python, version 2.3 or later. (2.4 recommended) -- Fine. Got that.
* Install wxWidgets, version 2.6 or later, in the Unicode flavor. -- I'm not installing wxWidgets on a server just to make BitTorrent happy! I hope that this is only actually required for the GUI apps.
* Install wxPython, version 2.6 or later, in the Unicode flavor. -- Sod off.
* Install GTK, version 2.6 or later. -- Bugger that.
* Install Twisted, version 2 or later. -- No.
* Install PyCrypto, version 2 or later. -- Now that is actually a darn good idea.
* Install Psyco. -- Psyco is good. Requiring Psyco is very very bad.
* Install Zope.Interface. -- Sod off!

So 4.4.0 it is. 4.4 seems to be the end of a stable release, followed by a completely new release with these features:

* completely new UI -- Don't need it or want it.
* smart download/queuing behavior -- Don't need it.
* smart seeding behavior -- Don't need it.
* torrent priority system -- Don't need it.
* detailed progress bar and "piece bar" progress bar -- Don't need it.
* better save location management ("incomplete" and "finished" locations) -- Completely irrelevant.
* automatic bandwidth management - Hmm.
* download rate control -- Don't need it.
* transfer rate graphs -- Don't need it.
* choose which files to download first from a torrent -- Don't need it.
* better error handling and reporting -- Hmm.
* fast extensions (see bittorrent.org) -- Useful, yes, but not here.
* torrent "title" support (see bittorrent.org) -- There's nothing on bittorrent.org!
* multiple tracker support -- Actually, that might be something I could use.
* encryption support -- Don't need it.
* Zeroconf ("Rendezvous") local discovery -- Don't need it.
* sparse files -- Don't need it.
* threaded Disk IO -- Don't need it.
* translation update system -- Don't need it.
* now using wxWidgets instead of GTK on Windows, GUI is now native and should be a lot more stable -- Don't need it, don't want it, just make it go away!
* removed support for Python 2.2 -- Whatev.

Thanks, BitTorrent peeps, for at least keeping 4.4 around.

Update: libtorrent won't compile. Somewhere, deep in the jungle, a library is missing a .h file. Or something. Ick.

Update: The other thing I want to note, is that for something so popular, BitTorrent is incredibly underdocumented. The only place that the options to the tracker module are documented are in the program, and the only way to find them is by running the program, because they're all in translation files, and if you don't have all the crazy dependencies installed you can't run the program.

Blah.

Here's to statically-linked binaries. Yeah, I know they suck too. But they suck differently.

Posted by: Pixy Misa at 11:40 PM | Comments (5) | Add Comment | Trackbacks (Suck)
Post contains 605 words, total size 4 kb.

Just the thing for timing a long-running benchmark.

Sigh.

Posted by: Pixy Misa at 06:51 PM | Comments (7) | Add Comment | Trackbacks (Suck)
Post contains 21 words, total size 1 kb.

First I suspected that it might be the thread-local data, which can persist between requests. But a bit of debugging showed that this data wasn't growing.

And a bit more debugging showed that the leak still occurred when I disconnected the entire Minx module from the dispatch code and just returned a static string.

And a bit more debugging showed that the leak even occurred with the CherryPy "Hello, World!" example.

If the tools.sessions option was set in the config file.

So then - a bug in the CherryPy session tracking code!

...

Not quite. Well, possibly a small one, but I'm not certain of that.

By default, CherryPy sessions last for 60 minutes, and (also by default) it can be another 5 minutes before the background cleanup task removes them.

Meanwhile, I was hitting CherryPy with anything up to 150 requests per second. And since I was using wget for the testing, rather than a browser, I was throwing the session cookies away.

So I had something like 500,000 sessions active at any time. And CherryPy appears to use about 300 bytes per session.

I didn't notice this with my torture test because that was generating less than 1000 requests an hour. 300kB of overhead is hard to spot on a 70MB process (10 threads, 5MB pages). 150MB of overhead on a 25MB process (100 threads, 100kB pages) is rather more noticeable.

There's still a problem with Minx slowing down over time. The page generation time in my current test has slowed by 75μs over the last 50,000 pages. I had chalked this trend up to the memory leak, but there may be another problem I need to address.

Well, at least I've made progress. I haven't fixed anything - except my test bed - but I have ascertained that the bug doesn't exist.

And I also know that CherryPy can cope with 500,000 simultaneous sessions...

Posted by: Pixy Misa at 02:35 PM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 378 words, total size 2 kb.

Currently I'm seeing a time per page of 7.0 ms and 87 pages per second. The system load is about 60% Python, 2.3% memcached, 1.1% MySQL, and 33% idle. I can't seem to push it much higher than that with my current test framework.

Which tells me that:

1. It's plenty fast.
2. memcached uses no CPU, in the broad scheme of things.

The live deployment will have multiple instances of Minx per server, and load-balance across them as well as across the servers themselves. And the servers will be about 3.5 times as fast (comparing the Xeon 3060 to the Athlon XP 2800+).

Multiply it out and I'll get, hmm, about 465 pages per second.

As for the 7ms of overhead, well, even cached pages get passed through the template engine (because there are template tags that take effect after the page is generated) and it still has to check your login against the database (to see if you have any preference settings that would require a custom page to be presented) and so on. I'll try to keep the overhead down, of course, but that's not too terrible, considering.

Now I'll leave it to soak. Python is using 85MB at the moment (with 50 threads), but seems to be creeping up a bit. One odd thing with CherryPy is that the virtual space is much larger - currently 650MB. Which limits me to about 300 threads total per instance.

The other thing I noticed is that memcached was developed by the people at LiveJournal. LiveJournal has since been acquired by SixApart. SixApart are the Movable Type people. I originally started writing Minx just so I could get off Movable Type.

Well, I was amused.

Update: Hmm. 96MB now. Admittedly, it reached 70MB with 10 threads after a long soak, and I was expecting it to be on the order of 350MB this time.

As long as it stops growing eventually.

Update: 121MB and 8.2ms per page at the 130,000 page mark. That smells like a leak, but a pretty small one.

Posted by: Pixy Misa at 05:42 AM | Comments (1) | Add Comment | Trackbacks (Suck)
Post contains 388 words, total size 2 kb.