Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux Counter Part 2 45

Posted by CmdrTaco from the we-did-it-again dept.
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).
This discussion has been archived. No new comments can be posted.

Linux Counter Part 2 More

Linux Counter Part 2

Comments Filter:
  • This box I'm on now got slashdotted [min.net] thanks to that pic of those anonymous guys [linuxonline.org].. or something.

    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.

  • Imagine running the biggest spamhouse... and constantly going down because *EVERYONE* was pinging it just to see if it was up or not.

    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.

    ---

  • 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
  • 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

  • Later (Score:1)

    by mackga ( 990 )
    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 :)
  • Thing don't work, homer.
  • I put in an Email address, and it said that I didn't... :(
  • Check out this site [eunuchs.org] 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
  • 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!


    The difference being that most of the NT machines that get /.'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
  • 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!
    The difference being that most of the NT machines that get /.'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
  • "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.
  • 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.

    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", /. being the "bender". See what I mean about butt jokes? This is the part where you're supposed to laugh.

    If half the people in a group think your witty, does that make you halfwitty?
  • 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!
  • 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).

  • 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?
  • 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!
  • 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?

  • Replay (Score:1)

    by GC ( 19160 )
    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 [anvdesign.net]

Slashdot Top Deals

The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.

Close