This will set queues 0-7 to specific smp affinity slots.
Is it that EBS snapshots are engineered to prevent this? Or just that it's not likely to happen in practice?
1) The file system correctly orders or journals operations (I'm not familiar with XFS, but this is the case with FFS2/FreeBSD, ZFS, ext3/4 journaling, etc).
2) The database system correctly orders or journals operations, and properly fsync(s) to disk (which postgreSQL does)
Of course, there's no harm to an abundance of caution with something like this.
"Takeaway: if read capacity is likely to be a concern, bringing up read-slaves ahead of time and getting them in rotation is ideal"
Sorry but this is not 'ideal', this is Capacity Planning 101. If you're launching a new product which you expect to be very popular, take your peak traffic and double or quadruple it and build out infrastructure to handle it ahead of time. I thought this was the whole point of the "cloud"? Add a metric shit-ton of resources for a planned peak and dial it down after.
Paul is nice so we are nice.
Last time I checked, I haven't built a service with +20mm users. I Googled you. I don't think you have built a service with +20mm users.
Programming is hard. Scaling is harder.
Let's have some empathy here. I bet the Instagram team has parents and siblings and significant others and friends that they haven't seen in a while. I bet they have responsibilities that they have neglected to keep the service up. I'd rather not poop on their head when they are trying to scale their service by millions of users.
This stuff is hard. Leaving a comment on a news aggregation service is easy.
I have no idea how many users Sportsline had but it was a bunch. Peaks of 64k hits per second on the dynamic layer, up to 8 gigabits sustained traffic in one datacenter... it was pretty ugly on firefighting days. I don't mean to poop on them, but if they're as big as they seem to be I hold them to a higher standard than a 6 month old start-up fresh out of college.
I agree it's hard. The fact that they were able to handle the traffic they did with only a small amount of downtime is a testament to the fact that they did have their shit together (as well they should with the number of users they had already).
Re RRD, have you read about graphite? "Graphite originally did use RRD for storage until fundamental limitations arose that required a new storage engine."
Hmm, didn't know that. Too bad they didn't just extend RRD. Did they say what the limitations were? I see a note about high volume causing lots of writes and implementing caching to deal with it, but that can be dealt with via tuned filesystem parameters...
Ah, I found the page: http://graphite.wikidot.com/whisper
RRD can be tuned to ignore 'irregular' data points, or include them all. The timestamp issue can be a problem but there are methods to deal with order of updates (like take them via tcp, or rrd merge tools).
If you have a lot of RAM to spare, an excellent hack is putting your RRDs with the highest amount of writes in a tmpfs volume and rsync'ing them regularly (it's insanely fast, trust me). More on tuning RRD: http://oss.oetiker.ch/rrdtool-trac/wiki/TuningRRD http://oss.oetiker.ch/rrdtool/doc/rrdcached.en.html http://sourceforge.net/apps/trac/ganglia/wiki/rrdcached_inte... http://community.zenoss.org/docs/DOC-4696
Question about quality insta-photos on Android.
I have JPG from SGS2 - http://kia4sale.narod.ru/insta/01.jpg
This is http://kia4sale.narod.ru/insta/02.jpg instaphoto (Earlybird) from Android version
This is http://distilleryimage9.instagram.com/662ade7483ce11e19e4a12... - instaphoto from SGS2 JPG but on iPhone 4.
Question: why instaphoto on Android version in blurry?
Per second... It must be quite a moment when you reach this point.
So if they want to keep their counter greater than that for a long time, they'll probably have to extend their market beyond humans.
NewRelic gives you mainly a predefined set of metrics, where you just have to install the agent to get them. Then. There's an additional module where you can send your own set of metrics and display them.
Statsd on the contrary is 'only' a tool to collect and then display metrics. You have to define everything you eant to measure yourself (or use plugins to your app).
So these two are definitely related, but better used for different (although overlapping) jobs.
For a small team like ours, we prefer solutions that are easy to reason about and get back into a healthy state (it would take one server deploy to point all appservers at new Redis master), rather than fully automated failover and the "fun" split-brain issues that ensue. Of course that may change as we build out our Ops team, etc.
Their sales dudes like startups, we were only lightly funded when we started using them - garth@newrelic could probably help you.
(Btw not connected in any way, jsut a very happy user that convinced enough companies to try them, that I think you would be a good match, too)