Amator Profesionist

Overused services on abused servers

Things I’ve learned while running a public BitTorrent tracker that handles about 66k torrents and, on average, about 70k peers. On a 7 year old desktop machine turned server, nonetheless.

Load averages can get up to the high three hundreds, heh:

19:22:59 up 11 days,  1:56,  1 user,  load average: 380.23, 384.55, 292.47

Once you’ve reached a critical efficiency level in software, the hardware will screw you over: went from handling 15-20 requests/sec via a PHP and flat-file based tracker (lighttpd + fastcgi + php-cgi) to handling around 200 reqs/sec and 600 live connections at any moment with xbtt reverse proxied from lighttpd. But the line was so saturated that I was seeing latencies of 16-20s on connections. And when you’re running on 256 MBs of RAM, … well, welcome to swap hell.

Although never explicitly mentioned anywhere, lighttpd can use the source IP as a parameter in a rewrite. It’s just a question of doing the rewrite inside a regex IP address conditional:

$HTTP["remoteip"] =~ "(.*)" {

    url.rewrite-once = ( "\/target\?(.*)$" => "/target?ip=%1&$1" )

}

The %1 parameter is the match of the $HTTP[“remoteip”] check, while the $1 parameter is the match of the rewrite check itself. So you can basically reproduce nginx’s $remote_addr in rewrites, and then use it for reverse proxying, thus passing the original IP to the target webserver as a GET parameter, not just as a header.

Unless IPv6 is enabled. Because apparently if it is, you can’t just do matching against $HTTP[“remoteip”], probably because IPs show up as v4-mapped IPv6s (::ffff:127.0.0.1). And as I’m an IPv6 enthusiast, that’s a no-no.

Consumer-grade routers suck. I’ve been blaming that NetGear router for a while for dropping connections like mad. How is it that a shitty 7 year old system with a load in the hundreds which actually processes requests can still handle more connections than a one year old router?! And it isn’t exactly one of the cheap ones either.

Praise be to lighttpd! Quirky, buggy software, might exchange it for nginx one day. But for now, it’s everything I need and keeps everything running smooth.

And in the end, when all was said and done, I decided that running a BitTorrent tracker is too much hassle for no reward whatsoever, I’ve already gleaned all the knowledge I could from this experience and I had simply become bored with it. So I just CNAMEd tracker.token.ro to tracker.publicbt.com - let them handle all those thousands of peers! That’s what they’re there for.

Using GNUplot to graph process CPU usage

At a friend’s request and out of plain curiosity, I went about trying to find a way to graph per-process CPU usage over time. So I wrote this tiny script that grabs a certain PID’s CPU usage every 3 seconds for however long the user specifies, and when it’s done, it outputs a nice ASCII chart of the CPU usage, courtesy of GNUplot.

Here’s the script:

#!/bin/zsh
if (( ! $# )); then
    echo "Usage: $0:t <PID> <minutes to monitor>" >&2
    return 1;
fi

let "ticks=$2*60/3"
for i in {1..$ticks}; do;
    ps -p $1 -o pcpu | grep -v % >> $1-usage.txt;
    sleep 3;
    echo $i / $ticks;
done;

gnuplot -e "set term dumb; set yrange [0:100]; \
plot '$1-usage.txt' s c;"

And here’s the output:

100 ++------+------+-------+------+-------+------+-------+------+------++
    +       +      +       +      +       +  'usage-mplayer.txt'+****** +
    |                                                                   |
    |                                                                   |
 80 ++                                                                 ++
    |                                                                   |
    |                  *******************                              |
    *******************                  *                        ******|
 60 +*                                   *                      ***    ++
    |                                    *                    **        |
    |                                    *                    *         |
    |                                    *                   *          |
    |                                    *                   *          |
 40 ++                                   *                   *         ++
    |                                    *                   *          |
    |                                    *                  *           |
    |                                    *                  *           |
 20 ++                                   *                  *          ++
    |                                    *                  *           |
    |                                    *******************            |
    +       +      +       +      +       +      +       +      +       +
  0 ++------+------+-------+------+-------+------+-------+------+------++
    0      100    200     300    400     500    600     700    800     900

And GNUplot also does graphical charts! Take the <PID>-usage.txt file dropped in your cwd by the script and run it thru GNUplot like this:

gnuplot -e "set term png; set output graph.png; \
set yrange [0:100]; plot 'PID-usage.txt' s c"

The numbers on the X axis are ticks (seconds/3), the numbers on the Y axis are CPU usage.

Required for this script: zsh, gnuplot and… ps.

emergent online technologies!

So recently I’ve been earning myself a couple of techie/geek badges with token.ro, as it now supports/implements a bunch of next-gen technologies and ideas. Some are useful, others are implemented just because I could.

• IPv6 support
  The site has been fully IPv6 enabled for a few months. I’ve got a httpd listening on an IPv6 address, AAAA records in my nameservers, which are IPv6-accessible themselves *and* have IPv6 glue at the ccTLD authority. Only 3 of the 6 root nameservers for .ro are IPv6 enabled, but we’re getting there.
• SPF and DKIM for email
  I’m now publishing strict SPF records and a DomainKey. All outgoing emails from this domain are signed with DKIM, all incoming+forwarded emails go thru SRS to prevent any SPF breakage. Take that, spam!
• OpenID
  This one isn’t exactly new: this domain is also my OpenID, via delegation to the provider of my choice (currently idproxy.net). The advantages of OpenID are numerous, the advantage of using your own site as your OpenID is that you’re not tied to any one provider - provider delegations are easily changed.
• FOAF
  So I got into the whole semantic web craze and published my FOAF description. Basically, FOAF is a means of creating a distributed social network, with each participant retaining full control over the data made public (as the FOAF description is just an XML file published on your website).
• microID signatures
  The entire site (including this blog) has been signed with my microID. Not extremely useful (with microID, the possibility of verification implies the possibility of spoofing), but I liked the concept. Added bonus: claimid now recognizes me as the author of my own website, isn’t that awesome? And, well, I like microformats.
• CDN delivery
  As a tiny experiment, this tumblelog’s static content is now served via the Coral Content Distribution Network. I don’t expect speed improvements, I just want to see how it… feels. I’m thinking of deploying my own CDN for the whole domain, seeing as how I have access to servers on multiple continents. And deploying a CDN with GeoScaling, my DNS provider, would be a breeze.

Next up on the list? Probably a hosted XMPP+SIP solution, some LOC records for the domain, putting my SSL cert to good use by enabling HTTPS and whatever else will pique my interest.

…and it’s over.

Mi-au dat cu flit de la google.

We carefully reviewed your background and experience, and though we do not have a position that is a strong match with your qualifications at this time, we will be keeping your resume active in our system.  We will continue to use our database to match your profile with new opportunities and will reach out to you if we find an opening for which you may be qualified.

Elegant, n-am ce zice, dar tot flit se cheamă.

Păcat că n-a mers, dar trebuie să recunosc că mă simt mai mult uşurat decât orice altceva. A fost o experienţă foarte interesantă şi unică… şi nu cred că m-ar ţine s-o repet. O lună de interviuri, în total vreo 4 ore de back and forth despre linux, reţelistică, programare şi altele, mi-a ajuns.

Urmează să le dau un reply în care să le zic să-mi trimită un tricou cu “Google wanted me for a job and all I got is this t-shirt”.

Am mai dat încă 2 interviuri, fiecare de câte 45 de minute.

Pe 27 martie a decurs binişor interviul. Am vorbit exclusiv despre linux de data asta. Îmi aduc aminte distinct că am discutat despre zombie processes (lol zombies), fork bombs, ulimit, diferenţe între shell commands şi executabile, codurile de ieşire ale lui fork() în C, cum porneşti un proces din cod, permisiunile din linux (rwxst pe fişiere şi directoare, ce face fiecare), cum umountezi un fs care nu se lasă (lsof). Intervievatorul ăsta n-a mai fost aşa prietenos şi deschis ca primii 2, părea mai plictisit şi sictirit de mine, dar m-am descurcat ok.

Ăsta ar fi trebuit să fie ultimul interviu telefonic, situaţia fiind că după ăsta ori mă invită la un interviu on-site, ori nu. Numai că la vreo săptămână după interviu primesc email de la recrutorul din Irlanda că vor să-mi mai programeze un interviu telefonic. N-or fi fost convinşi, nu ştiu.

Ieri 11 am avut al patrulea interviu telefonic cu Google. Al patrulea. Iar 45 de minute de întrebări, de data asta mai mult axate pe reţelistică şi network stack-ul din linux. Dintre întrebări: cum se stabileşte o conexiune TCP (SYN - SYN ACK - ACK), de ce e nevoie de ăştia 3 paşi, ce mai e conţinut în pachetele astea, mai specific ce face window size-ul, care-s diferenţele între TCP şi UDP, care-s diferenţele între un pachet TCP şi o datagramă UDP, inclusiv din cod, ce aplicaţii/protocoale pe UDP ştiu şi de ce folosesc UDP, cum lucrează DNS-ul, ce tipuri de DNS entries cunosc, cum se cache-uieşte DNS-ul, ce-i TTL, ce-i SOA. A mai întrebat ce înseamnă o conexiune în TIME_WAIT (fumbled this one) şi cum arata o conexiune SMTP (să-i povestesc protocolul practic). Şi a trebuit să scriu şi ceva cod de data asta, a văzut că scrisesem că ştiu python, i-am zis că-s în curs de învăţare. M-a pus să scriu o bucată de cod python care afişează fiecare al treilea element al unui array începând cu elementul 4: după vreo 3-4 revizii de cod mi-a ieşit ceva funcţional. (Apropo, e stupid de incomod şi greu să scrii cod pe foaie şi dup-aia să-l dictezi prin telefon.) Însă în ultimele 5 minute m-a încuiat nasol: să scriu o funcţie care determină dacă un integer e putere a lui 2: banal, nu? numai că nu mi-a ieşit nici de-al dracu; am încercat ceva recursiv, dar m-am înpiedicat în rotunjiri. Scosesem ceva aproape funcţional când mi-a spus că ar trebui să mă uit la bitwise operations. Da, bine, superb, nu m-am mai jucat cu operaţii pe biţi de prin clasa a 9-a. Şi evident nu mi-a picat fisa; între timp m-am documentat niţel, şi într-adevăr, soluţia era foarte elegantă.

De data asta interviul s-a încheiat cu o notă nefavorabilă pentru mine, plus că după 4 interviuri devenisem eu relativ blazat şi nepăsător şi am impresia că s-a auzit în tonul meu. Rămâne de văzut dacă mă invită la interviu on-site sau nu, n-am curaj să dau un pronostic. A şi dacă mai vor înca vreun interviu telefonic, îmi bag picioarele, mi-a ajuns.

Şi mulţumesc bunilor mei prieteni care m-au sunat aseară după ce tocmai reuşisem să adorm, spunând că sună din partea Google-ului şi că vor să mă anunţe că-s un faggot, cu un accent americănesc indecent de realist (*points @ NSD*) :D.

OK, pe 17 martie am dat al doilea interviu la Google, a fost bine.

Intervievatorul a fost foarte de treaba, glumeţ şi destins, m-a întrebat care-i diferenţa înte hub şi switch (plus detalieri - mergând până la cum îşi populează două switch-uri MAC table-urile), cum lucrează traceroute-ul, nişte chestii de subnetare CIDR (ce bcast are 10.0.0.30/25 de exemplu), care-i diferenţa între symlinks si hardlinks (extins până la ce-i în inode-urile unui fişier şi cum vezi ce-i acolo), cum ştergi un fişier denumit “-f” şi altele.

“The feedback was positive” a zis următorul recrutor, de data asta din Irlanda, şi mi-a programat un interviu pentru poimâine, joi 27. Care aparent va atinge tot ce am trecut eu în CV: linux sysadmin, networking, understanding of TCP/IP, C/C++, C#, PHP, Python, Perl, Java, bash scripting, HTML, CSS, experienţă MySQL.

N-am înflorit mai nimic, numai că: python ştiu la nivel de tutorial, perl şi bash scripting înţeleg, dar nu-s în stare să scriu prea bine, Java ştiu niţel de la facultate, dar nu mi-a prea plăcut şi n-am reţinut mai nimic, C/C++ n-am folosit niciodata în linux, nici nu ştiu care-s headerele diferite, PHP şi MySQL am mai uitat şi tot aşa.

To do list:

• reread python tutorial
• find a good, simple perl tutorial
• skim php manual
• skim mysql manual
• install mysql and play around a bit
• read bash scripting tutorial

…btw still freaking out.

Aşadar!

Am dat primul interviu la Google, a fost fain, m-am descurcat. Am aflat care-i job-ul, mai am încă două interviuri telefonice (primul fiind luni) şi, cu condiţia că trec de astea, un interviu on-site.

Mi-a fost recomandat să citesc dintre următoarele, ca să fiu pregătit pentru interviul de luni:

- Networking Basics
- System Administration Basics
- System monitoring and troubleshooting
- Scripting

still freaking out btw.

Mâine 7 martie, orele 20:30 am interviu pentru un “engineering position at Google Europe”. O_O

Nu ştiu exact despre ce e vorba, ştiu doar că m-au contactat cu chestia asta pentru că ştiu C/C++, Python, administrare de unicşi şi reţelistică. Şi mâine mă sună! Google! Pe mine!

*freaks out*