Your JoeDog was down this morning. This site is hosted on the free plan at Amazon Web Services. Through the EC2 web portal, he was able to read the console logs of the downed instance. It was filled with entries which looked like this:
9443.085875 Write-error on swap-device (202:0:10258840)
9443.085875 Write-error on swap-device (202:0:10295632)
9443.085875 Write-error on swap-device (202:0:10320576)
9443.085875 Write-error on swap-device (202:0:10336216)
9443.085875 Write-error on swap-device (202:0:10395280)
So Your JoeDog plugged that error into the Google machine and it produced this Amazon EC2 forum entry. The Amazon rep asked that troubled soul if he could stop and start his instance. So Your JoeDog did a stop and start. That didn’t solve his problem, either. In the end, he was forced to clone the volume and bring up a whole new server. He took the opportunity to add more memory. Yeah, that means he’s no longer on the free plan but he can’t deal with the low-memory micro instance for another second. Not. One. More. Second.
So if you’re a troubled soul who found this entry because you googled “Write-error on swap-device” for your downed EC2 instance, here’s how you bring up a clone.
- EC2 Dashboard => Instances (select downed instance)
- Actions => Image => Create image (that’s going to take a while)
- On the left nav: Images => AMIs (select the new one)
- Select it, then hit Launch. (follow the instructions)
Once your new server is up and running, log in and scrutinize the environment. You should have all the content that was one the old one. It is, afterall, a clone. Once you’re feeling good about the new server, you can terminate the old one and delete the old image.
Your JoeDog found Richard Stallman to be the same in real life as he is on the Internets: a complete pain in the ass. He’s not just the how priest of free software, he’s also the choir. For example, most of us understand that when you buy hardware it comes with proprietary firmware. He gets worked up about that. The dude will inconvenience himself rather than compromise his commitment to free — as in freedom — software.
Actually, he’s a very nice guy but I’m still surprised to learn we have a anything in common. Yet we do! For example, did you know we
- Both prefer console based editors although Stallman uses that god awful emacs.
- Think C++ is one ugly-ass language
- Think java is elegant although we don’t use it often.
- Both consider C our favorite language.
- Don’t care for 4Chan.
That’s about it, but it’s more traits than Your JoeDog would have thought possible. Click that and you’ll see what I mean. If the rich aren’t like the rest of us, then neither is Stallman. And that’s a good thing because the guy’s a treasure. (Even if he is a pain in the ass.)
If you’re following the 3.1.0 thread, then you know siege clients are essentially capped by your operating system’s FD_SETSIZE. For most of us, that means 1024. You can increase its capacity by recompiling your kernel, an operation Your JoeDog hasn’t attempted in over 20 years. In all likelihood, you don’t feel like doing that either.
To overcome this limit, we switched from select to poll in siege-3.1.0 rc2. If your OS supported poll, then you’d use that mechanism to test socket readiness. So while that increased our capacity, it wrecked our performance. Why? It’s still not clear why but that’s the feedback we received from several testers. It also matches our own experience.
Which brings us to release candidate 3. We now use both mechanisms. If a socket descriptor is less than FD_SETSIZE, then we test it with select. If it’s greater than that, we use poll. Thus far it seems like a good compromise until we develop better method for high volume socket testing.
NOTE: If your web server is not configured to run a pool of 1024 threads, do NOT configure siege with that many simulated users. If you use more siege threads than available web server threads, connections will back up while waiting for handlers and before you know it, you’ll have a mess. You’ve been warned.
Here’s a handy-dandy labor saving tip for you. Let’s say — and why not? — we want to make a linky-link like Pittsburgh Pirates in WordPress. With the URL copied to your clipboard, highlight the link text in the WordPress editor then hit Ctrl-v. Done and done. No need to use the chain link icon. You’re welcome.
NOTE: Andrew McCutchen tied the game for the Pirates in the bottom of the eight as Your JoeDog was working on the Pittsburgh Pirates link for this entry….
Look, Your JoeDog is willing to support his friends’ fitness efforts but if they start posting vital signs to social media, he may have to de-friend them. Would anyone actually post their vital signs? Yes, and believe it or not, there’s an app for that.
The Wifi Body Scale measures weight, body fat, heart rate, and the air quality of whatever room your scale is in. It comes with Wifi networking and a Health Mate app that lets you share its data to social media.
In theory, the app holds you accountable as others bear witness to a personal struggle. But to what extent can they participate in this public shaming? Is it okay to “Like” unflattering updates? Can they note that, um, “your numbers are really going up”?
Keep in mind this technology is still in its infancy. As it becomes more refined, we may one day be able to tell who’s overweight simply by looking at them….
From Tom Goodwin over at TechCrunch:
Uber, the world’s largest taxi company, owns no vehicles. Facebook, the world’s most popular media owner, creates no content. Alibaba, the most valuable retailer, has no inventory. And Airbnb, the world’s largest accommodation provider, owns no real estate. Something interesting is happening.
Indeed. The future belongs to transaction-skimmers…
Earlier today we told you about a hard limit in siege. Since it relied on select rather than poll, it was unable to open more than 1024 concurrent sockets on most — maybe all! — operating systems. Now Your JoeDog never needs that many sockets but some of you are over 1000. When you scheduled that many, your OS would abort siege. Don’t worry, the Supreme Court is cool with that.
This limitation was the result of a design decision from 1999. Fortunately, a 2001 design decision made it easy to incorporate both mechanisms in the same distribution. The configure script will check to see if you have poll and, really, in 2015 you should have it. If you do, it will use that mechanism to test your sockets.
Nothing changes for you dinosaurs. If you don’t have poll, then you can carry on with your precious select.
So Your JoeDog could use some beta testers. The changes have been submitted to the main branch at github.com and they’re available in this distribution: http://download.joedog.org/siege/beta/siege-3.1.0-rc2.tar.gz
Test it, Doggers, test its little brains out.
Back in 1999-ish, Your JoeDog made a decision! Once he makes a decision, he doesn’t look back. “That’s over, Doggers. It’s time to move on.” And move on we did. Since 1999 we’ve been using select to check if our socket descriptor is ready for input. This is an important test because siege pounds your web server until it calls him “Daddy.” If the socket doesn’t get ready, then the request must time out or siege will hang.
We don’t want more hanging chads!
There were two mechanisms we could have used to accomplish this: poll and select. We chose select because it was more flexible and more readily available. At the time, we supported a great many platforms: Solaris, HP-UX, AIX, SCO, BSD, Linux, etc. The downside to select was its capacity. The fd_set couldn’t handle numbers higher than 1024. Well back in 1999, Yahoo! might have been doing 1024 concurrent connections but mere mortals didn’t need that capacity.
Recently we told you that siege crashes when large pools of simultaneous users are created. We finally got to the bottom of that problem and it dates back to that 1999 decision. Siege aborts when socket descriptors larger than 1024 are passed to FD_SET. We will fix this problem but there’s currently no ETA. It will require extensive testing and more of those difficult 1999-ish decisions.
For example, should we just stone-cold switch to poll or should we support both mechanisms? The latter will create a macro soup; does anyone have a stomach for that? Another option is create an array of fd_sets and place them on each thread. That would allow us to continue using select. (Your JoeDog kinda likes this option). And finally we could just say “Fsck it.” If you really have that many users, then you can afford Load Runner.
NOTE: To give you some perspective on traffic, this site is ranked 155,295 in the US. We almost never exceed 50 hits a second. Your JoeDog professionally webmasters a site ranked under 8000 and it almost never exceeds 100 hits a second. You must have a really large audience to generate 1024 hits a second. The vast majority of you should be fine with 255 threads or less.
Over at OpenSource.com, Rich Bowen has a fine article about software documentation.
Have you noticed that the more frequently a particular open source community tells you to RTFM, the worse the FM is likely to be? I’ve been contemplating this for years, and have concluded that this is because patience and empathy are the basis of good documentation, much as they are the basis for being a decent person.
Empathy is the ability to understand needs of others so it’s a particularly good trait for someone who’s writing software instructions. This week Your JoeDog was installing a vendor’s code and he ran into a snag with one of the modules. It couldn’t connect to the database and its port listeners were walking on those of another module.
Your JoeDog took the time to detail theses issues so the vendor would have an easy time with his diagnosis. If you construct your prose with the recipient in mind, then you can convey a more meaningful message. That thoughtfulness did make it easy for the vendor to diagnose the problem. Your JoeDog sent him over 1000 words and he replied with a single sentence. That sentence solved his problem while it boiled his blood. And what did the vendor say that caused such a reaction?
“You don’t need to install that.”
“WTMF?” Your JoeDog thought. He omitted MFs from his reply and simply asked the vendor this: “Then why does your documentation tell me to install that?”
“That’s just generic documentation we send to all customers,” he said.
A more empathetic man would have pruned and tailored his documentation to meet the needs of the target audience. Does Your JoeDog consider this man empathetic? No. He thinks he’s kind of a dick.
We received messages about core dumps that occur when siege is run with more than 700 threads. That’s a lot of threads, you guys! First things first — and this can’t be stressed enough — if you run siege with -c700, make sure your web server is configured with a pool of 700 threads. If you hit a pool of 256 threads with 700 users, all you’re gonna do is make a mess, mmmkay?
Now back to those core dumps. Here’s the thing: we’ve been unable to reproduce the problem but some diligent siegers have worked with us to get stack traces. As a result, we’ve added improved error handling and integrity checks in the problematic region. Your JoeDog would greatly appreciate if you could test version 3.1.0 release candidate 1. You can provide feedback here or by email, whichever you prefer.