Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Linux Counter Part 2

Posted by CmdrTaco on Thu Feb 25, 1999 06:07 AM
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.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • by drwiii (434) on Thursday February 25 1999, @11:33AM (#2004558)
    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.

  • by strredwolf (532) on Thursday February 25 1999, @12:57PM (#2004559) Homepage Journal
    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.

    ---

  • by Eric Green (627) on Thursday February 25 1999, @10:44PM (#2004560) Homepage
    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
  • Urrkk... (Score:1)

    by Doug McNaught (668) on Thursday February 25 1999, @11:14AM (#2004561)
    Looks like it's slashdotted again...

    -Doug
  • better idea (Score:1)

    by deno (814) on Thursday February 25 1999, @11:37AM (#2004562) Homepage
    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) <eatshitanddie@slashdot.org> on Thursday February 25 1999, @12:19PM (#2004563) Homepage
    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 :)
  • by mholve (1101) on Thursday February 25 1999, @11:47AM (#2004564) Homepage
    Thing don't work, homer.
  • by mholve (1101) on Thursday February 25 1999, @12:29PM (#2004565) Homepage
    I put in an Email address, and it said that I didn't... :(
  • by mholve (1101) on Thursday February 25 1999, @04:46PM (#2004566) Homepage
    Check out this site [eunuchs.org] that runs Linux. It has yet to be Slashdotted. Eat that, NT. :)
  • by Derek (1525) on Thursday February 25 1999, @01:16PM (#2004567) Journal
    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
  • by Derek Pomery (2028) on Thursday February 25 1999, @02:30PM (#2004568)
    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
  • by Anonymous Cow herd (2036) on Thursday February 25 1999, @01:20PM (#2004569) Homepage
    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
  • by Anonymous Cow herd (2036) on Thursday February 25 1999, @01:20PM (#2004570) Homepage
    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
  • Replay (Score:1)

    by John Zero (3370) on Thursday February 25 1999, @12:05PM (#2004571)
    "Yesterday we totally nuked the Linux Counter by linking it on these pages."

    ...Now we're doing it again ;-)

    ROTFL ;-)
  • Two for two (Score:1)

    by Mark Storer (4097) on Thursday February 25 1999, @11:23AM (#2004572)
    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 (Score:1)

    by Mark Storer (4097) on Thursday February 25 1999, @12:22PM (#2004573)
    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?
  • Crunch (Score:1)

    by donfede (6215) on Thursday February 25 1999, @11:20AM (#2004574) Homepage
    there it goes crunch again.

    is the problem the server or the line?

    Federico
  • Great idea! (Score:1)

    by MagicFab (7234) on Thursday February 25 1999, @11:20AM (#2004575) Homepage
    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!
  • by Signal 11 (7608) on Thursday February 25 1999, @11:28AM (#2004576)
    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



    --
  • by eval (8638) on Thursday February 25 1999, @12:01PM (#2004577) Homepage
    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.
  • by somebody else (8966) on Thursday February 25 1999, @10:00PM (#2004578) Homepage
    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).

  • by Duke of URL (10219) on Thursday February 25 1999, @12:55PM (#2004579)
    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?
  • Linux sucks. (Score:1)

    by jforr (15487) on Thursday February 25 1999, @12:04PM (#2004580)
    Oh just ignore him. Everyone knows that Anonymous coward is really a microsmurf.
  • by QuadPro (16532) on Thursday February 25 1999, @11:18AM (#2004581) Homepage
    http://www.cs.kuleuven.ac.be/~geert/Linux/m68k/Reg istration.html

    (apologies if this was already known)
  • how ironic (Score:1)

    by UM_Maverick (16890) on Thursday February 25 1999, @11:19AM (#2004582) Homepage
    Does anyone else find it a little ironic that the page detailing how a server experienced the /. effect got slashdotted?
  • inefficient coding (Score:1)

    by apsmith (17989) on Thursday February 25 1999, @04:53PM (#2004583) Homepage
    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!
  • by Fred M (18407) on Thursday February 25 1999, @11:52AM (#2004584)
    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)

  • Oh, no! Not AGAIN! (Score:1)

    by pfaut (18898) on Thursday February 25 1999, @12:28PM (#2004585) Homepage
    What have you got against this poor site that you /. it two days in a row?
  • Replay (Score:1)

    by GC (19160) <giles@coochey.net> on Thursday February 25 1999, @12:25PM (#2004586)
    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??
  • by fusion94 (19221) on Thursday February 25 1999, @05:18PM (#2004587) Homepage
    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.
  • Linux vs NT (Score:1)

    by topdogg (200755) on Thursday February 25 1999, @11:18AM (#2004588) Homepage
    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]
  • 14 replies beneath your current threshold.