Slashdot Mirror
Linux Counter Part 2
Yesterday we totally nuked the Linux Counter
by linking it on these pages.
Steve sent us a link to a detailed page on the
Slashdot Experience contains logs and the like,
documenting the server going crunch. I'm reposting it because
yesterday the server spent several hours down and I'd like
more people to have a chance to register their Linux box. Drop
on in, fill out the form and let the world know that you run
Linux. When you can't track sales to determine an
OSs market share, things get tricky. Update: 02/25 11:47 by CT : That didn't
take long. Guess you guys have more work to do over there (sigh).
woah
I was wondering if VA Research would donate some machines temporarily for the count... It would really help.
Hmm.. It seems that counter.li.org/slashdot :) ..
has experienced slashdot-effect
You could stop this recursively going effect
by NOT telling how that and that server
again were slashdotted
It sucks like things have never sucked before.
It seems every time a NT box gets /.ed to death theres a ton of posts about how this proves that NT sucks and linux Ru3lZ Now we have a linux box crumbling under the stress, does this prove Linux sucks... no I don't think so!
But i think it shows that some linux zealots need to get a grip and not knee-jerk to anything related to anything thats not linux!
I damn near gave myself a hernia laughing at that one!
[Deep breaths, take deep breaths]
My home server gets around 10k hits per day and has been several times advertised on FM, ZDTV and LinuxToday.com. It never experienced any problem.
/. effect ?
/. readers or are these boxes badly configured?
How worse is the
Am I greatly underestimating the power of
Looks like this thing needs to be a bit beefed up
Lessons learned
Slashdotting is good for you. The counter is now defensively configured, and is able to do something intelligent even under heavy load.
A 32-Mbyte Pentium can't fill a 256-Kbit link using Perl.
I'm sure management is happy to know that.
The adrenaline kick of a slashdotting feels real good!
But it does eat time...I spent 4 hours Tuesday night getting the box reconfigured and back on its feet, and then just watching it. Late. On Wednesday, 1412 people registered with the counter.
What happened about 1 minute after the article went up was that a hundred people tried registering, the counter tried to satisfy them, and the machine went into trashing.
Each registration operation requires a Perl script, which has about a 2-Mbyte footprint. You can imagine the result of trying to run 150 of those at the same time.
The solution was to change Apache's "MaxClients" config variable to approximately 1/2 of the Mbytes that could be used for scripts - 12 in this case; the true value was achieved shortly after midnight. (The "factory" default is 150). After getting another 16 Mbytes of RAM, I've since increased it to 20, but at that time (12 noon on the 24th), the Slashdot wave was mostly over, so I don't know if this value is truly safe.
Hhahahaha... and its dead again....
I damn near split my gut I laughed so hard!
'nuf said. ;-)
The solution is very simple and the webmaster of Linux Counter is obviously not well versed when it comes to coding with Perl.
Solution: mod_perl
because if he's out there invoking 2 meg perl processes on a box that small, he's either insane or needs the clue.
Things like this don't say much for Linux, do they ? hehe...
The neat part is that the load never passed 0.40, and that's on a 486-class box! Yay FreeBSD!
On another note, the DNS load from it crushed one of our BSDI BSD/OS name servers, which required a reboot.
Slashdotting is similar.
Unfortunately, it's not a DOS attack because it's everyone plumetting one server with one request each, not one person wacking on it with massive amounts of requests.
---
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Perl takes just as much memory whether it is compiled as mod_perl or loaded as a CGI. The only real difference is that you don't have to spawn a process. That speeds things up, but doesn't reduce the memory footprint.
:-).
Remember, a separate Apache gets spawned to handle each request, up to a certain limit set in your httpd.conf. Think about it, 100 copies of Apache spawned, each with the whole code bloat of Perl embedded into it...
Better have some memory handy, that's all I say
-- Eric
Send mail here if you want to reach me.
Looks like it's slashdotted again...
-Doug
Slashdotting the Linux-counter in this way is not such a great idea. At least not as long as it runs on it's present machine.
Putting a link to it an a visible place IS a good idea. How about putting a reference to the counter in the "Features" area?
Yours
Denis
Hummm. thought I hit the submit button earlier. Anyway, once the counter gets un-/.-ed, make sure you register. A good way to up the demograhics, and you get a neat logo for your webpage - see mine :)
"shop smart:shop s-mart" ash
Thing don't work, homer.
I put in an Email address, and it said that I didn't... :(
Check out this site that runs Linux. It has yet to be Slashdotted. Eat that, NT. :)
Sure does. Essentially the slashdot effect is a legitimate D.O.S. attack. That can hurt almost any OS if it isn't set up to avoid it or if the hardware just underneath just can't do what it is asked to do. In this case, a pentium 66 (w/8MB RAM?) is NOT a top-o-the-line machine. I doubt NT would have done much better on the same hardware, or Solaris, or AIX or ...
Anyway, I guess I'll have to read the details later. They've been slashdotted again. Did anyone NOT see this one coming?
-Derek
I feel should mention this at some point, perhaps
it should become part of a poll.
How long has your OS been up, and what OS?
Hmm, hard to do 3d poll. One would have to have multiple OS and times... Say, 3 major OS, four time brackets for 12 questions.
At any rate, my machine running NT4 at work has been up without crashes or reboots since August.
Including quite a few software upgrades, even the ever buggy Netscape 4.5
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
It seems every time a NT box gets /.ed to death theres a ton of posts about how this proves that NT sucks and linux Ru3lZ Now we have a linux box crumbling under the
/.'d aren't running on a p60 (or was it 90?) with 32M of RAM :-P Plus the fact that after it was reconfigured he said it was working fine, and handling a load that would bring a much more expesnive (in terms of hardware) NT server to its knees.
stress, does this prove Linux sucks... no I don't think so!
But i think it shows that some linux zealots need to get a grip and not knee-jerk to anything related to anything thats not linux!
The difference being that most of the NT machines that get
- Moo
Ita erat quando hic adveni.
It seems every time a NT box gets /.ed to death theres a ton of posts about how this proves that NT sucks and linux Ru3lZ Now we have a linux box crumbling under the stress, does this prove Linux sucks... no I don't think so! But i think it shows that some linux zealots need to get a grip and not knee-jerk to anything related to anything thats not linux! /.'d aren't running on a p60 (or was it 90?) with 32M of RAM :-P Plus the fact that after it was reconfigured he said it was working fine, and handling a load that would bring a much more expesnive (in terms of hardware) NT server to its knees. - Moo
The difference being that most of the NT machines that get
Ita erat quando hic adveni.
"Yesterday we totally nuked the Linux Counter by linking it on these pages."
;-)
;-)
...Now we're doing it again
ROTFL
Is the ./ effect a DOS attack? Heh.
Do we have any kind of an early warning system for these little sites with great content? "Hey, you're about to get more hits in an hour than you've had in the last 2 years. Grab your ankles."
Give the poor bastards a little notice. At least then they could apply some K-Y first.
--Mark
Butt jokes always work. Farts. Constipation. You name it. They're bound to get to someone. Of course, given the size of the /. audience, stories about grand mothers and navel lint would get to SOMEONE.
/. being the "bender". See what I mean about butt jokes? This is the part where you're supposed to laugh.
Seriously though, some kind of early warning/mirroring system could really help out situations like these, although they would take some kind of coordination with the "bend-ee",
If half the people in a group think your witty, does that make you halfwitty?
--Mark
there it goes crunch again.
is the problem the server or the line?
Federico
I would've never had this idea myself... of cours eveyone now knows that posting the same site 2 times in slashdot greatly enhances its chances of survival and uptime.
DUH!
Notepad specialist & FAT administrator, group training available
64 bytes from 195.139.236.69: icmp_seq=6 ttl=42 time=642.4 ms
64 bytes from 195.139.236.69: icmp_seq=7 ttl=42 time=594.3 ms
64 bytes from 195.139.236.69: icmp_seq=8 ttl=42 time=610.6 ms
64 bytes from 195.139.236.69: icmp_seq=9 ttl=42 time=618.4 ms
64 bytes from 195.139.236.69: icmp_seq=10 ttl=42 time=641.7 ms
64 bytes from 195.139.236.69: icmp_seq=11 ttl=42 time=738.1 ms
64 bytes from 195.139.236.69: icmp_seq=12 ttl=42 time=525.8 ms
64 bytes from 195.139.236.69: icmp_seq=13 ttl=42 time=691.5 ms
64 bytes from 195.139.236.69: icmp_seq=14 ttl=42 time=778.1 ms
64 bytes from 195.139.236.69: icmp_seq=15 ttl=42 time=632.8 ms
64 bytes from 195.139.236.69: icmp_seq=16 ttl=42 time=654.1 ms
64 bytes from 195.139.236.69: icmp_seq=17 ttl=42 time=736.0 ms
64 bytes from 195.139.236.69: icmp_seq=18 ttl=42 time=622.7 ms
64 bytes from 195.139.236.69: icmp_seq=19 ttl=42 time=688.5 ms
64 bytes from 195.139.236.69: icmp_seq=20 ttl=42 time=656.6 ms
64 bytes from 195.139.236.69: icmp_seq=21 ttl=42 time=582.3 ms
64 bytes from 195.139.236.69: icmp_seq=22 ttl=42 time=598.5 ms
64 bytes from 195.139.236.69: icmp_seq=23 ttl=42 time=645.1 ms
64 bytes from 195.139.236.69: icmp_seq=24 ttl=42 time=687.4 ms
64 bytes from 195.139.236.69: icmp_seq=25 ttl=42 time=690.4 ms
64 bytes from 195.139.236.69: icmp_seq=26 ttl=42 time=695.8 ms
64 bytes from 195.139.236.69: icmp_seq=27 ttl=42 time=573.7 ms
64 bytes from 195.139.236.69: icmp_seq=28 ttl=42 time=607.2 ms
64 bytes from 195.139.236.69: icmp_seq=29 ttl=42 time=545.0 ms64 bytes from 195.139.236.69: icmp_seq=29 ttl=42 time=545.0 ms
64 bytes from 195.139.236.69: icmp_seq=30 ttl=42 time=703.0 ms
64 bytes from 195.139.236.69: icmp_seq=31 ttl=42 time=757.6 ms
64 bytes from 195.139.236.69: icmp_seq=32 ttl=42 time=683.6 ms
64 bytes from 195.139.236.69: icmp_seq=33 ttl=42 time=728.5 ms
64 bytes from 195.139.236.69: icmp_seq=34 ttl=42 time=705.2 ms
64 bytes from 195.139.236.69: icmp_seq=35 ttl=42 time=898.6 ms
64 bytes from 195.139.236.69: icmp_seq=36 ttl=42 time=973.1 ms
64 bytes from 195.139.236.69: icmp_seq=37 ttl=42 time=1056.3 ms
64 bytes from 195.139.236.69: icmp_seq=38 ttl=42 time=1175.0 ms
64 bytes from 195.139.236.69: icmp_seq=39 ttl=42 time=1047.4 ms
64 bytes from 195.139.236.69: icmp_seq=40 ttl=42 time=1104.8 ms
64 bytes from 195.139.236.69: icmp_seq=41 ttl=42 time=1103.2 ms
64 bytes from 195.139.236.69: icmp_seq=42 ttl=42 time=1076.8 ms
64 bytes from 195.139.236.69: icmp_seq=43 ttl=42 time=1066.4 ms
64 bytes from 195.139.236.69: icmp_seq=44 ttl=42 time=918.2 ms
64 bytes from 195.139.236.69: icmp_seq=45 ttl=42 time=1005.7 ms
64 bytes from 195.139.236.69: icmp_seq=46 ttl=42 time=893.4 ms
64 bytes from 195.139.236.69: icmp_seq=47 ttl=42 time=950.2 ms
64 bytes from 195.139.236.69: icmp_seq=48 ttl=42 time=1109.2 ms
64 bytes from 195.139.236.69: icmp_seq=49 ttl=42 time=1135.0 ms
64 bytes from 195.139.236.69: icmp_seq=50 ttl=42 time=890.9 ms
64 bytes from 195.139.236.69: icmp_seq=29 ttl=42 time=545.0 ms
64 bytes from 195.139.236.69: icmp_seq=30 ttl=42 time=703.0 ms
64 bytes from 195.139.236.69: icmp_seq=31 ttl=42 time=757.6 ms
64 bytes from 195.139.236.69: icmp_seq=32 ttl=42 time=683.6 ms
64 bytes from 195.139.236.69: icmp_seq=33 ttl=42 time=728.5 ms
64 bytes from 195.139.236.69: icmp_seq=34 ttl=42 time=705.2 ms
64 bytes from 195.139.236.69: icmp_seq=35 ttl=42 time=898.6 ms
64 bytes from 195.139.236.69: icmp_seq=36 ttl=42 time=973.1 ms
64 bytes from 195.139.236.69: icmp_seq=37 ttl=42 time=1056.3 ms
64 bytes from 195.139.236.69: icmp_seq=38 ttl=42 time=1175.0 ms
64 bytes from 195.139.236.69: icmp_seq=39 ttl=42 time=1047.4 ms
64 bytes from 195.139.236.69: icmp_seq=40 ttl=42 time=1104.8 ms
64 bytes from 195.139.236.69: icmp_seq=41 ttl=42 time=1103.2 ms
64 bytes from 195.139.236.69: icmp_seq=42 ttl=42 time=1076.8 ms
64 bytes from 195.139.236.69: icmp_seq=43 ttl=42 time=1066.4 ms
64 bytes from 195.139.236.69: icmp_seq=44 ttl=42 time=918.2 ms
64 bytes from 195.139.236.69: icmp_seq=45 ttl=42 time=1005.7 ms
64 bytes from 195.139.236.69: icmp_seq=46 ttl=42 time=893.4 ms
64 bytes from 195.139.236.69: icmp_seq=47 ttl=42 time=950.2 ms
64 bytes from 195.139.236.69: icmp_seq=48 ttl=42 time=1109.2 ms
64 bytes from 195.139.236.69: icmp_seq=49 ttl=42 time=1135.0 ms
64 bytes from 195.139.236.69: icmp_seq=50 ttl=42 time=890.9 ms
195.139.236.69: icmp_seq=35 ttl=42 time=898.6 ms
64 bytes from 195.139.236.69: icmp_seq=36 ttl=42 time=973.1 ms
64 bytes from 195.139.236.69: icmp_seq=37 ttl=42 time=1056.3 ms
64 bytes from 195.139.236.69: icmp_seq=38 ttl=42 time=1175.0 ms
64 bytes from 195.139.236.69: icmp_seq=39 ttl=42 time=1047.4 ms
64 bytes from 195.139.236.69: icmp_seq=40 ttl=42 time=1104.8 ms
64 bytes from 195.139.236.69: icmp_seq=41 ttl=42 time=1103.2 ms
64 bytes from 195.139.236.69: icmp_seq=42 ttl=42 time=1076.8 ms
64 bytes from 195.139.236.69: icmp_seq=43 ttl=42 time=1066.4 ms
64 bytes from 195.139.236.69: icmp_seq=44 ttl=42 time=918.2 ms
64 bytes from 195.139.236.69: icmp_seq=45 ttl=42 time=1005.7 ms
64 bytes from 195.139.236.69: icmp_seq=46 ttl=42 time=893.4 ms
64 bytes from 195.139.236.69: icmp_seq=47 ttl=42 time=950.2 ms
64 bytes from 195.139.236.69: icmp_seq=48 ttl=42 time=1109.2 ms
64 bytes from 195.139.236.69: icmp_seq=49 ttl=42 time=1135.0 ms
64 bytes from 195.139.236.69: icmp_seq=50 ttl=42 time=890.9 ms
64 bytes from 195.139.236.69: icmp_seq=51 ttl=42 time=1054.7 ms
--
The counter isn't dead, just slow. I've been able to get through consistently, as long as I'm willing to wait a while.
The linux counter site didn't go down from the slashdot effect today.
In fact, it didn't go down at all today.
Anyone could have discovered (as I did) through a bit of patience (i.e., open link in new window, then wait), it is working as intended. In fact, I registered myself and my machine while the rest of you were gloating over having (NOT) taken the site down. (I got dragged away from computers for several hours today, so was unable to post this until just now, thus the long delay).
Here's the information from their website (which you too can read online at their *completely functional, working* site).
BEGIN QUOTE
The Linux Counter is a project that has been running since 1993, with the chief aim of letting people tell the world "I use Linux".
It is currently running on a 66 MHz Pentium machine, which at the time of Slashdot had 32 Mbytes of RAM. It is located in Norway, and its connection to the outside world is through a 256 Kbit/second leased line. Its timezone is European (MET, +0100), six hours ahead of the US East Coast, nine hours ahead of California.
The counter keeps rather extensive graphs of its operation, including hourly summaries of the number of visitors, the number of operations done, and the number of Web pages served. The pictures were striking enough that I thought it a Good Thing to preserve them for posterity; the running stats are always available.
[graph removed] This image shows the basic phases of a Slashdotting:
1.Confusion
2.Reconfiguration
3.Return to normality
What happened about 1 minute after the article went up was that a hundred people tried registering, the counter tried to satisfy them, and the machine went into trashing.
Each registration operation requires a Perl script, which has about a 2-Mbyte footprint. You can imagine the result of trying to run 150 of those at the same time.
The solution was to change Apache's "MaxClients" config variable to approximately 1/2 of the Mbytes that could be used for scripts - 12 in this case; the true value was achieved shortly after midnight. (The "factory" default is 150). After getting another 16 Mbytes of RAM, I've since increased it to 20, but at that time (12 noon on the 24th), the Slashdot wave was mostly over, so I don't know if this value is truly safe.
END QUOTE
The simple fact of the matter is: He made the necessary adjustments to weather this storm and succeeded. Slashdot DIDN'T take down the site.
So, to Rob and the rest of you who just *assumed* you had downed the site: I guess you guys have a lot to learn about going to sites that have adapted to your effect (sigh).
~~~~~~~~
Signature illegible, could be somebody else.
Uh I haven't been able to read anything on this yet, but I'm guess the server is in Europe?
It took me 28 hops to get there (yuck!) going from SFO to CHI to NYC (thru Qwest - they rock) to London to Amsterdam to Olso and then on and on...
Has anyone been able to get on sucessfully very recently?
Oh just ignore him. Everyone knows that Anonymous coward is really a microsmurf.
http://www.cs.kuleuven.ac.be/~geert/Linux/m68k/Reg istration.html
(apologies if this was already known)
Does anyone else find it a little ironic that the page detailing how a server experienced the /. effect got slashdotted?
Juiced? Or Not?
I don't believe the explanation for the low capacity of this server though - shouldn't the perl instances share most of that 2 MB/process? I can't believe processing those simple forms takes up that much memory per instance. Unless the memory is getting sucked up by a database backend - or all the processing going on to keep the stats graphics going. But even so, there weren't THAT many hits here. I suspect the problem is the thing is coded to use some kind of persistent server process that hangs around while users are dilly-dallying filling out the forms (or waiting to get the results of their last submitted form).
C'mon we really should be able to do better than this!
Energy: time to change the picture.
Coming through went better by pinging at the same time, so thanks for the idea. I got better ping timing, it ran from 4100 to 130 ms.
Fortuna favet fatuis (Fortuna favors fools, and most of them run windows)
What have you got against this poor site that you /. it two days in a row?
Actually I'm wrong here - It doesn't look like the bandwidth is being used up. It looks like they need some more meaty servers on the Linux Counter??
I have a 4 Processor Pentium Pro w/256 MBs of RAM and 24GBs of HDD just sitiing around. It has Redhat 5.2 installed. Will make it available if there is a better way to do the Linux Counter.
I think linux has come a long way. I have been testing Win NT to Linux, With company needs, I have found that Linux can hold it's own with Win NT and haha GET THIS, Out linux server we tested on was a 166, the nt box, a 233, On some of the database benchmarks we ran the nt just won't keep up with the 166 linux box. Now it makes me wonder what would it do with the dual 350's we will have in two weeks? Well you can find out on the site when we benchmark it.. http://www.anvdesign.net
Got shack?
ShackCentral Network
Worlds best gaming network!!!