<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://prospect.org/power/2025-07-17-how-did-elon-musk-turn-grok-into-mechahitler/"/>
	<rdf:li rdf:resource="https://krzysztofslusarski.github.io/2022/12/12/async-manual.html"/>
	<rdf:li rdf:resource="https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/"/>
	<rdf:li rdf:resource="https://gceasy.io/"/>
	<rdf:li rdf:resource="https://medium.com/thron-tech/lessons-learned-about-monitoring-the-jvm-in-the-era-of-containers-47e7fe0b77dc"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/big-data/best-practices-for-successfully-managing-memory-for-apache-spark-applications-on-amazon-emr/"/>
	<rdf:li rdf:resource="https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior#what-value-to-choose-for-malloc_arena_max"/>
	<rdf:li rdf:resource="http://www.brendangregg.com/USEmethod/use-linux.html"/>
	<rdf:li rdf:resource="https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/"/>
	<rdf:li rdf:resource="https://engineering.linkedin.com/blog/2016/04/dr-elephant-open-source-self-serve-performance-tuning-hadoop-spark"/>
	<rdf:li rdf:resource="https://twitter.com/akpurtell/status/698614296226312192"/>
	<rdf:li rdf:resource="http://blog.threatstack.com/scaling-cassandra-lessons-learned"/>
	<rdf:li rdf:resource="https://databricks.com/blog/2015/05/28/tuning-java-garbage-collection-for-spark-applications.html"/>
	<rdf:li rdf:resource="http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-gc-migration-to-expectations-and-advanced-tuning"/>
	<rdf:li rdf:resource="https://issues.apache.org/jira/browse/CASSANDRA-7486"/>
	<rdf:li rdf:resource="http://engineering.linkedin.com/java/optimizing-java-cms-garbage-collections-its-difficulties-and-using-jtune-solution"/>
	<rdf:li rdf:resource="https://groups.google.com/d/msg/mechanical-sympathy/DWlziVmyW-w/at-54WECjL4J"/>
	<rdf:li rdf:resource="http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/"/>
	<rdf:li rdf:resource="http://tobert.github.io/tldr/cassandra-java-huge-pages.html"/>
	<rdf:li rdf:resource="https://speakerdeck.com/elasticsearch/maintaining-performance-in-distributed-systems"/>
	<rdf:li rdf:resource="https://twitter.com/AWSSummits/status/487280813780656129/photo/1"/>
	<rdf:li rdf:resource="http://aws.amazon.com/articles/3604"/>
	<rdf:li rdf:resource="http://docs.basho.com/riak/latest/ops/advanced/backends/leveldb/"/>
	<rdf:li rdf:resource="http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html"/>
	<rdf:li rdf:resource="https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock"/>
	<rdf:li rdf:resource="http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications"/>
	<rdf:li rdf:resource="http://vanillajava.blogspot.co.uk/2013/07/micro-jitter-busy-waiting-and-binding.html?m=1"/>
	<rdf:li rdf:resource="http://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html"/>
	<rdf:li rdf:resource="http://www.fullcontact.com/blog/mongo-to-cassandra-migration/"/>
	<rdf:li rdf:resource="http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads"/>
	<rdf:li rdf:resource="http://engineering.chartbeat.com/2014/01/02/part-1-lessons-learned-tuning-tcp-and-nginx-in-ec2/"/>
	<rdf:li rdf:resource="http://www.slideshare.net/cpwatson/cpn302-yourlinuxamioptimizationandperformance"/>
	<rdf:li rdf:resource="http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html"/>
	<rdf:li rdf:resource="http://kerneldave.blogspot.ie/2013/10/response-to-optimizing-linux-memory.html"/>
	<rdf:li rdf:resource="http://java-is-the-new-c.blogspot.de/2013/07/what-drives-full-gc-duration-its.html"/>
	<rdf:li rdf:resource="http://www.infoq.com/articles/tuning-tips-G1-GC"/>
	<rdf:li rdf:resource="http://www.slideshare.net/amywtang/wbdb2012-voldemortssd"/>
	<rdf:li rdf:resource="http://www.jclarity.com/products/censum/"/>
	<rdf:li rdf:resource="http://java-is-the-new-c.blogspot.ie/2013/07/tuning-and-benchmarking-java-7s-garbage.html"/>
	<rdf:li rdf:resource="http://mechanical-sympathy.blogspot.ca/2013/07/java-garbage-collection-distilled.html"/>
	<rdf:li rdf:resource="http://distributeddreams.blogspot.ie/2012/04/making-sense-out-of-bdb-je-fast-stats.html"/>
	<rdf:li rdf:resource="http://www.psc.edu/index.php/networking/641-tcp-tune"/>
	<rdf:li rdf:resource="http://imho.nu/iMHo/tcp-optimizer/"/>
	<rdf:li rdf:resource="http://www.slideshare.net/aszegedi/everything-i-ever-learned-about-jvm-performance-tuning-twitter"/>
	<rdf:li rdf:resource="http://blog.explainmydata.com/2012/07/expensive-lessons-in-python-performance.html"/>
	<rdf:li rdf:resource="http://www.slideshare.net/boundary_slides/garbage-garbage-everywhere"/>
	<rdf:li rdf:resource="http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/"/>
	<rdf:li rdf:resource="http://blip.tv/file/2232410"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://prospect.org/power/2025-07-17-how-did-elon-musk-turn-grok-into-mechahitler/">
    <title>How Did Elon Musk Turn Grok Into MechaHitler?</title>
    <dc:date>2025-07-18T08:52:31+00:00</dc:date>
    <link>https://prospect.org/power/2025-07-17-how-did-elon-musk-turn-grok-into-mechahitler/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent description of the layers of tuning available for LLMs, and the risks involved, as demonstrated by Grok's recent "MechaHitler" incident:

<blockquote>LLMs become “woke” because they are trained to be pro-social — to be helpful, kindly, truthful, and not to say bigoted or cruel things. Training it to do the opposite — to be anti-woke — is to activate every antisocial association in the English language, including racism, sexism, cruelty, dishonesty, and Nazism. According to a vast statistical representation of the English language constructed by none other than Elon Musk, that’s what anti-wokeness is. “Elon Musk is repeatedly insisting, no, no, there’s a difference between what I’m doing and being a Nazi. And what the model keeps telling him is, statistically, that’s not the case,” said Schou.

A key implication here is that LLMs will tend to converge on similar types of behavior. The above researchers were not using Grok, but they found the exact same pattern of powerful association groupings of good and evil in other LLMs — and these can’t be removed through fine-tuning. One could imagine the RLHF process including adjustments of every parameter, but experts said that this will degrade or break the model. The matrices in an LLM are arranged hierarchically, and the top layers get fixed in place relatively early in pretraining. Mess with them, and the model will stop working. Instead, RLHF developed more like a series of gates that prevent undesired outcomes. “The model completes most of the computation that it needs in order to reach a particular outcome,” [Andreas] Schou said. “And then says, ‘Wait, wait, wait, I’m saying that I’m MechaHitler. No, I’m not doing that.’”

One could try to assemble a custom dataset with nothing but “conservatism minus the Nazis” and train a new model from scratch, but not only would that be extremely expensive, it also would not be nearly as strong as leading models, since its universe of available training data would be much smaller.</blockquote>

Funnily enough, the latter approach is exactly what Elon Musk claims xAI are now doing.]]></description>
<dc:subject>llms language technology ai mechahitler grok tuning rlhf woke training</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:08edfa8b6a64/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:language"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:technology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mechahitler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grok"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rlhf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:woke"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:training"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://krzysztofslusarski.github.io/2022/12/12/async-manual.html">
    <title>Async-profiler manual by use cases</title>
    <dc:date>2023-01-05T15:53:26+00:00</dc:date>
    <link>https://krzysztofslusarski.github.io/2022/12/12/async-manual.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Amazing collection of Java async-profiler commands and examples, each one representing a specific common (or not-so-common) use case we are liable to run into with production services: includes continuous profiling, wall-clock vs CPU, allocations, locks, cache misses, page faults, and thread-startup overhead]]></description>
<dc:subject>async-profiler java jvm profiling tracing performance tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8ec959433ae2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async-profiler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/">
    <title>Extreme HTTP Performance Tuning: 1.2M API req/s on a 4 vCPU EC2 Instance | talawah.io</title>
    <dc:date>2021-05-21T08:54:01+00:00</dc:date>
    <link>https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is very cool. Updating the old "C10K" problem space to C1.2M -- the current state of Linux userspace networking -- using libreactor and a whole load of up-to-date tweaks.

Interesting to note that this scale is feasible to run in Docker (using --network=host, of course).
]]></description>
<dc:subject>http servers c10k linux performance scalability ops tuning libreactor networking tcp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:022774113a4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c10k"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libreactor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gceasy.io/">
    <title>GCEasy.io</title>
    <dc:date>2020-12-04T10:57:55+00:00</dc:date>
    <link>https://gceasy.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Java Garbage collection log analysis made easy: Industry's first machine learning guided Garbage collection log analysis tool. GCeasy has in-built intelligence to auto-detect problems in the JVM & Android GC logs and recommend solutions to it.'

Looks pretty simple to use, decent free tier.  Haven't tried it yet though....

]]></description>
<dc:subject>java gc tuning performance jvm logs ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d3d8327d2376/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/thron-tech/lessons-learned-about-monitoring-the-jvm-in-the-era-of-containers-47e7fe0b77dc">
    <title>G1 GC tuning metrics</title>
    <dc:date>2020-03-11T13:21:50+00:00</dc:date>
    <link>https://medium.com/thron-tech/lessons-learned-about-monitoring-the-jvm-in-the-era-of-containers-47e7fe0b77dc</link>
    <dc:creator>jm</dc:creator><description><![CDATA[supposedly this is about "tuning in the era of containers", but really it's more about which metrics are usable for GC tuning with the newish java G1 garbage collector.]]></description>
<dc:subject>jvm g1 g1gc gc tuning metrics ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:44d5b27b29bf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/big-data/best-practices-for-successfully-managing-memory-for-apache-spark-applications-on-amazon-emr/">
    <title>Spark memory tuning on EMR</title>
    <dc:date>2019-04-10T09:48:34+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/big-data/best-practices-for-successfully-managing-memory-for-apache-spark-applications-on-amazon-emr/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Best practices for successfully managing memory for Apache Spark applications on Amazon EMR', on the AWS Big Data blog.

'In this blog post, I detailed the possible out-of-memory errors, their causes, and a list of best practices to prevent these errors when submitting a Spark application on Amazon EMR.

My colleagues and I formed these best practices after thorough research and understanding of various Spark configuration properties and testing multiple Spark applications. These best practices apply to most of out-of-memory scenarios, though there might be some rare scenarios where they don’t apply. However, we believe that this blog post provides all the details needed so you can tweak parameters and successfully run a Spark application.']]></description>
<dc:subject>spark emr aws tuning memory ooms java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7d538a70d00d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ooms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior#what-value-to-choose-for-malloc_arena_max">
    <title>Fix glibc's MALLOC_ARENA_MAX variable</title>
    <dc:date>2019-03-25T12:37:07+00:00</dc:date>
    <link>https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior#what-value-to-choose-for-malloc_arena_max</link>
    <dc:creator>jm</dc:creator><description><![CDATA[It seems that recent versions of glibc (up to glibc 2.25 at least) have some dysfunctional behaviour around malloc's arenas on multi-CPU systems,  massively inflating the number of arenas allocated, which inflate reported VM sizes and (for multi-threaded Ruby services in particular) fragmenting memory badly.

See also https://devcenter.heroku.com/articles/testing-cedar-14-memory-use

Presto issue reported with glibc malloc arena-per-thread behaviour resulting in Presto OOMs: https://github.com/prestodb/presto/issues/8993

Hadoop affected by the inflated VM sizes reported as a side effect: https://issues.apache.org/jira/browse/HADOOP-7154

Good detailed writeup from IBM's WebSphere blog: https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage]]></description>
<dc:subject>ops ruby memory malloc allocation arenas tuning fragmentation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f6214c1a141c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allocation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:arenas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fragmentation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.brendangregg.com/USEmethod/use-linux.html">
    <title>USE Method: Linux Performance Checklist</title>
    <dc:date>2016-06-29T16:30:13+00:00</dc:date>
    <link>http://www.brendangregg.com/USEmethod/use-linux.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Really late in bookmarking this, but has some up-to-date sample commandlines for sar, mpstat and iostat on linux]]></description>
<dc:subject>linux sar iostat mpstat cli ops sysadmin performance tuning use metrics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c50f8a259903/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iostat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mpstat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:use"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/">
    <title>Squeezing blood from a stone: small-memory JVM techniques for microservice sidecars</title>
    <dc:date>2016-06-18T09:46:44+00:00</dc:date>
    <link>https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Reducing service memory usage from 500MB to 105MB:

<blockquote>We found two specific techniques to be the most beneficial: turning off one of the two JIT compilers enabled by default (the “C2” compiler), and using a 32-bit, rather than a 64-bit, JVM.</blockquote>

]]></description>
<dc:subject>32bit jvm java ops memory tuning jit linkerd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ade3b2e45f61/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:32bit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkerd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://engineering.linkedin.com/blog/2016/04/dr-elephant-open-source-self-serve-performance-tuning-hadoop-spark">
    <title>Open Sourcing Dr. Elephant: Self-Serve Performance Tuning for Hadoop and Spark</title>
    <dc:date>2016-04-13T16:00:35+00:00</dc:date>
    <link>https://engineering.linkedin.com/blog/2016/04/dr-elephant-open-source-self-serve-performance-tuning-hadoop-spark</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>[LinkedIn] are proud to announce today that we are open sourcing Dr. Elephant, a powerful tool that helps users of Hadoop and Spark understand, analyze, and improve the performance of their flows.</blockquote>

neat, although I've been bitten too many times by LinkedIn OSS release quality at this point to jump in....

]]></description>
<dc:subject>linkedin oss hadoop spark performance tuning ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:48eaac9e2c7d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/akpurtell/status/698614296226312192">
    <title>Semisupervised Intern Descent</title>
    <dc:date>2016-02-13T22:01:51+00:00</dc:date>
    <link>https://twitter.com/akpurtell/status/698614296226312192</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Also known as "Graduate Student Descent", a common approach to hyperparameter tuning in machine learning -- ie. get an intern to sit there tweaking parameters until they find something approximating optimal performance]]></description>
<dc:subject>optimization funny terms terminology graduate-student-descent hyperparameters semisupervised-intern-descent tuning interns</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5eb66f4c558b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terminology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graduate-student-descent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperparameters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:semisupervised-intern-descent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interns"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.threatstack.com/scaling-cassandra-lessons-learned">
    <title>Scale it to Billions — What They Don’t Tell you in the Cassandra README</title>
    <dc:date>2015-09-28T15:30:07+00:00</dc:date>
    <link>http://blog.threatstack.com/scaling-cassandra-lessons-learned</link>
    <dc:creator>jm</dc:creator><description><![CDATA[large-scale C* tips]]></description>
<dc:subject>cassandra configuration tuning scale ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:41bfcab2a82b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:configuration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scale"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://databricks.com/blog/2015/05/28/tuning-java-garbage-collection-for-spark-applications.html">
    <title>Tuning Java Garbage Collection for Spark Applications</title>
    <dc:date>2015-06-06T07:02:50+00:00</dc:date>
    <link>https://databricks.com/blog/2015/05/28/tuning-java-garbage-collection-for-spark-applications.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[So much for G1GC being fire-and-forget]]></description>
<dc:subject>g1gc gc java jvm performance spark ops tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:431050bae8c9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-gc-migration-to-expectations-and-advanced-tuning">
    <title>Migration to, Expectations, and Advanced Tuning of G1GC</title>
    <dc:date>2015-05-09T08:19:41+00:00</dc:date>
    <link>http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-gc-migration-to-expectations-and-advanced-tuning</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Bookmarking for future reference.  recommended by one of the GC experts, I can't recall exactly who ;)]]></description>
<dc:subject>gc g1gc jvm java tuning performance ops migration</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1dbd33f78572/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migration"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://issues.apache.org/jira/browse/CASSANDRA-7486">
    <title>Cassandra moving to using G1 as the default recommended GC implementation</title>
    <dc:date>2015-04-29T15:42:34+00:00</dc:date>
    <link>https://issues.apache.org/jira/browse/CASSANDRA-7486</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a big indicator that G1 is ready for primetime. CMS has long been the go-to GC for production usage, but requires careful, complex hand-tuning -- if G1 is getting to a stage where it's just a case of giving it enough RAM, that'd be great.

Also, looks like it'll be the JDK9 default: https://twitter.com/shipilev/status/593175793255219200]]></description>
<dc:subject>cassandra tuning ops g1gc cms gc java jvm production performance memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0b4b3d1abe38/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.linkedin.com/java/optimizing-java-cms-garbage-collections-its-difficulties-and-using-jtune-solution">
    <title>Optimizing Java CMS garbage collections, its difficulties, and using JTune as a solution | LinkedIn Engineering</title>
    <dc:date>2015-04-11T20:21:41+00:00</dc:date>
    <link>http://engineering.linkedin.com/java/optimizing-java-cms-garbage-collections-its-difficulties-and-using-jtune-solution</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I like the sound of this -- automated Java CMS GC tuning, kind of like a free version of JClarity's Censum (via Miguel Ángel Pastor)]]></description>
<dc:subject>java jvm tuning gc cms linkedin performance ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:717dfe95f072/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/d/msg/mechanical-sympathy/DWlziVmyW-w/at-54WECjL4J">
    <title>Gil Tene's &quot;usual suspects&quot; to reduce system-level hiccups/latency jitters in a Linux system</title>
    <dc:date>2015-04-06T20:27:37+00:00</dc:date>
    <link>https://groups.google.com/d/msg/mechanical-sympathy/DWlziVmyW-w/at-54WECjL4J</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Based on empirical evidence (across many tens of sites thus far) and note-comparing with others, I use a list of "usual suspects" that I blame whenever they are not set to my liking and system-level hiccups are detected. Getting these settings right from the start often saves a bunch of playing around (and no, there is no "priority" to this - you should set them all right before looking for more advice...).</blockquote>

]]></description>
<dc:subject>performance latency hiccups gil-tene tuning mechanical-sympathy hyperthreading linux ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e22d85fc3109/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hiccups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mechanical-sympathy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperthreading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/">
    <title>JClarity's Illuminate</title>
    <dc:date>2015-02-26T15:49:43+00:00</dc:date>
    <link>http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Performance-diagnosis-as-a-service. Cool.

<blockquote>Users download and install an Illuminate Daemon using a simple installer which starts up a small stand alone Java process. The Daemon sits quietly unless it is asked to start gathering SLA data and/or to trigger a diagnosis. Users can set SLA’s via the dashboard and can opt to collect latency measurements of their transactions manually (using our library) or by asking Illuminate to automatically instrument their code (Servlet and JDBC based transactions are currently supported).

SLA latency data for transactions is collected on a short cycle. When the moving average of latency measurements goes above the SLA value (e.g. 150ms), a diagnosis is triggered. The diagnosis is very quick, gathering key data from O/S, JVM(s), virtualisation and other areas of the system. The data is then run through the machine learned algorithm which will quickly narrow down the possible causes and gather a little extra data if needed.

Once Illuminate has determined the root cause of the performance problem, the diagnosis report is sent back to the dashboard and an alert is sent to the user. That alert contains a link to the result of the diagnosis which the user can share with colleagues. Illuminate has all sorts of backoff strategies to ensure that users don’t get too many alerts of the same type in rapid succession!</blockquote>

]]></description>
<dc:subject>illuminate jclarity java jvm scala latency gc tuning performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d8f4dcc75538/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:illuminate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jclarity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tobert.github.io/tldr/cassandra-java-huge-pages.html">
    <title>TL;DR: Cassandra Java Huge Pages</title>
    <dc:date>2015-02-03T22:09:12+00:00</dc:date>
    <link>http://tobert.github.io/tldr/cassandra-java-huge-pages.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Al Tobey does some trial runs of -XX:+AlwaysPreTouch and -XX:+UseHugePages]]></description>
<dc:subject>jvm performance tuning huge-pages vm ops cassandra java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d448b5d53e34/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:huge-pages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://speakerdeck.com/elasticsearch/maintaining-performance-in-distributed-systems">
    <title>Maintaining performance in distributed systems [slides]</title>
    <dc:date>2015-01-25T23:43:59+00:00</dc:date>
    <link>https://speakerdeck.com/elasticsearch/maintaining-performance-in-distributed-systems</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great slide deck from Elasticsearch on JVM/dist-sys performance optimization]]></description>
<dc:subject>performance elasticsearch java jvm ops tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:99d8451bc962/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elasticsearch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/AWSSummits/status/487280813780656129/photo/1">
    <title>Latest EBS tuning tips</title>
    <dc:date>2014-07-11T13:54:10+00:00</dc:date>
    <link>https://twitter.com/AWSSummits/status/487280813780656129/photo/1</link>
    <dc:creator>jm</dc:creator><description><![CDATA[from yesterday's AWS Summit in NYC:

<blockquote>
Cheat sheet of EBS-optimized instances. http://t.co/vmTlhUtpWk
Optimize your queue depth to achieve lower latency & highest IOPS. http://t.co/EO48oa0D6X
When configuring your RAID, use a stripe size of 128KB or 256KB.  http://t.co/N0ldtFJ4t6
Use larger block size to speed up the pre-warming process. http://t.co/8UoIeWE2px
</blockquote>]]></description>
<dc:subject>ebs aws amazon iops raid ops tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dbfd882c9ad6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://aws.amazon.com/articles/3604">
    <title>AWS SDK for Java Client Configuration</title>
    <dc:date>2014-06-17T11:19:59+00:00</dc:date>
    <link>http://aws.amazon.com/articles/3604</link>
    <dc:creator>jm</dc:creator><description><![CDATA[turns out the AWS SDK has lots of tuning knobs: region selection, socket buffer sizes, and debug logging (including wire logging).]]></description>
<dc:subject>aws sdk java logging ec2 s3 dynamodb sockets tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6e67b33f2691/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sockets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://docs.basho.com/riak/latest/ops/advanced/backends/leveldb/">
    <title>Tuning LevelDB</title>
    <dc:date>2014-05-29T13:53:01+00:00</dc:date>
    <link>http://docs.basho.com/riak/latest/ops/advanced/backends/leveldb/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good docs from Riak]]></description>
<dc:subject>leveldb tuning performance ops riak</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8dffa2129e4d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:leveldb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riak"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html">
    <title>Coping with the TCP TIME-WAIT state on busy Linux servers</title>
    <dc:date>2014-05-01T22:49:27+00:00</dc:date>
    <link>http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[extensive blog post]]></description>
<dc:subject>networking linux tcp performance time-wait sysctls tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1161c9971396/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-wait"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysctls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock">
    <title>Scaling Realtime at DISQUS</title>
    <dc:date>2014-04-30T10:57:02+00:00</dc:date>
    <link>https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Disqus' realtime architecture -- nginx PushStream module doing the heavy lifting, basically.  See https://gist.github.com/dctrwatson/0b3b52050254e273ff11 for the production nginx configs they use.  I am very impressed that push-stream has grown to be so solid; it's a great way to deal with push from the sounds of it.

http://blog.disqus.com/post/51155103801/trying-out-this-go-thing now notes that some of the realtime backends are in Go.

https://speakerdeck.com/dctrwatson/c1m-and-nginx ("C1M and Nginx") is a more up to date presentation.  It notes that PushStream supports "EventSource, WebSocket, Long Polling, and forever iframe".  More sysctls and nginx tuning in that prez.]]></description>
<dc:subject>sysctl nginx tuning go disqus realtime push eventsource websockets long-polling iframe python</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:92ccc8b3f3ef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysctl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nginx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disqus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eventsource"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:websockets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:long-polling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iframe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:python"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications">
    <title>Garbage Collection Optimization for High-Throughput and Low-Latency Java Applications</title>
    <dc:date>2014-04-08T21:54:13+00:00</dc:date>
    <link>http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications</link>
    <dc:creator>jm</dc:creator><description><![CDATA[LinkedIn talk about the GC opts they used to optimize the Feed. good detail]]></description>
<dc:subject>performance optimization linkedin java jvm gc tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:77cabe371f7c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://vanillajava.blogspot.co.uk/2013/07/micro-jitter-busy-waiting-and-binding.html?m=1">
    <title>Micro jitter, busy waiting and binding CPUs</title>
    <dc:date>2014-03-21T11:26:50+00:00</dc:date>
    <link>http://vanillajava.blogspot.co.uk/2013/07/micro-jitter-busy-waiting-and-binding.html?m=1</link>
    <dc:creator>jm</dc:creator><description><![CDATA[pinning threads to CPUs to reduce jitter and latency. Lots of graphs and measurements from Peter Lawrey]]></description>
<dc:subject>pinning threads performance latency jitter tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:186b39854e95/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pinning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html">
    <title>Impact of large primitive arrays (BLOBS) on JVM Garbage Collection</title>
    <dc:date>2014-03-19T12:12:51+00:00</dc:date>
    <link>http://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some nice graphs and data on CMS performance, with/without -XX:ParGCCardsPerStrideChunk]]></description>
<dc:subject>cms java jvm performance optimization tuning off-heap-storage memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:026572f118c8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:off-heap-storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.fullcontact.com/blog/mongo-to-cassandra-migration/">
    <title>Migrating from MongoDB to Cassandra</title>
    <dc:date>2014-02-12T10:49:07+00:00</dc:date>
    <link>http://www.fullcontact.com/blog/mongo-to-cassandra-migration/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting side-effect of using LUKS for full-disk encryption: 'For every disk read, we were pulling in 3MB of data (RA is sectors, SSZ is sector size, 6144*512=3145728 bytes) into cache. Oops. Not only were we doing tons of extra work, but we were trashing our page cache too. The default for the device-mapper used by LUKS under Ubuntu 12.04LTS is incredibly sub-optimal for database usage, especially our usage of Cassandra (more small random reads vs. large rows). We turned this down to 128 sectors — 64KB.']]></description>
<dc:subject>cassandra luks raid linux tuning ops blockdev disks sdd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9e9bd44bf027/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:luks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blockdev"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sdd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads">
    <title>Cassandra: tuning the JVM for read heavy workloads</title>
    <dc:date>2014-01-24T10:14:24+00:00</dc:date>
    <link>http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The cluster we tuned is hosted on AWS and is comprised of 6 hi1.4xlarge EC2 instances, with 2 1TB SSDs raided together in a raid 0 configuration. The cluster’s dataset is growing steadily. At the time of this writing, our dataset is 341GB, up from less than 200GB a few months ago, and is growing by 2-3GB per day. The workload on this cluster is very read heavy, with quorum reads making up 99% of all operations.</blockquote>

Some careful GC tuning here.  Probably not applicable to anyone else, but good approach in general.]]></description>
<dc:subject>java performance jvm scaling gc tuning cassandra ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bc4cff6803b7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.chartbeat.com/2014/01/02/part-1-lessons-learned-tuning-tcp-and-nginx-in-ec2/">
    <title>Chartbeat's Lessons learned tuning TCP and Nginx in EC2</title>
    <dc:date>2014-01-03T14:19:46+00:00</dc:date>
    <link>http://engineering.chartbeat.com/2014/01/02/part-1-lessons-learned-tuning-tcp-and-nginx-in-ec2/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a good writeup of basic sysctl tuning for an internet-facing HTTP proxy fleet running in EC2.  Nothing groundbreaking here, but it's well-written]]></description>
<dc:subject>nginx amazon ec2 tcp ip tuning sysctl linux c10k ssl http</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4c04f47e8135/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nginx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysctl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c10k"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/cpwatson/cpn302-yourlinuxamioptimizationandperformance">
    <title>Netflix: Your Linux AMI: optimization and performance [slides]</title>
    <dc:date>2013-12-21T20:50:48+00:00</dc:date>
    <link>http://www.slideshare.net/cpwatson/cpn302-yourlinuxamioptimizationandperformance</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a fantastic bunch of low-level kernel tweaks and tunables which Netflix have found useful in production to maximise productivity of their fleet.  Interesting use of SCHED_BATCH process scheduler class for batch processes, in particular.  Also, great docs on their experience with perf and SystemTap.  Perf really looks like a tool I need to get to grips with...]]></description>
<dc:subject>netflix aws tuning ami perf systemtap tunables sched_batch batch hadoop optimization performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5c1292b5cc15/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ami"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systemtap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tunables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sched_batch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:batch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html">
    <title>HotSpot JVM garbage collection options cheat sheet (v3)</title>
    <dc:date>2013-11-10T00:10:17+00:00</dc:date>
    <link>http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[authoritative]]></description>
<dc:subject>jvm hotspot java tuning ops gc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a6b132013693/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hotspot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://kerneldave.blogspot.ie/2013/10/response-to-optimizing-linux-memory.html">
    <title>Response to &quot;Optimizing Linux Memory Management...&quot;</title>
    <dc:date>2013-10-23T16:28:35+00:00</dc:date>
    <link>http://kerneldave.blogspot.ie/2013/10/response-to-optimizing-linux-memory.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A follow up to the LinkedIn VM-tuning blog post at http://engineering.linkedin.com/performance/optimizing-linux-memory-management-low-latency-high-throughput-databases --

<blockquote>Do not read in to this article too much, especially for trying to understand how the Linux VM or the kernel works.  The authors misread the "global spinlock on the zone" source code and the interpretation in the article is dead wrong.
</blockquote>
]]></description>
<dc:subject>linux tuning vm kernel linkedin memory numa</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:028705973c7a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:numa"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://java-is-the-new-c.blogspot.de/2013/07/what-drives-full-gc-duration-its.html">
    <title>What drives JVM full GC duration</title>
    <dc:date>2013-10-08T11:15:46+00:00</dc:date>
    <link>http://java-is-the-new-c.blogspot.de/2013/07/what-drives-full-gc-duration-its.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting empirical results using JDK 7u21:

<blockquote>Full GC duration depends on the number of objects allocated and the locality of their references. It does not depend that much on actual heap size.</blockquote>

Reference locality has a surprisingly high effect.]]></description>
<dc:subject>java jvm data gc tuning performance cms g1</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:71efc8abad7c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/articles/tuning-tips-G1-GC">
    <title>Tips for Tuning the Garbage First Garbage Collector</title>
    <dc:date>2013-09-18T21:34:06+00:00</dc:date>
    <link>http://www.infoq.com/articles/tuning-tips-G1-GC</link>
    <dc:creator>jm</dc:creator><dc:subject>g1gc gc java jvm tuning ops optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6b12d8d218aa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/amywtang/wbdb2012-voldemortssd">
    <title>Voldemort on Solid State Drives [paper]</title>
    <dc:date>2013-09-04T14:26:32+00:00</dc:date>
    <link>http://www.slideshare.net/amywtang/wbdb2012-voldemortssd</link>
    <dc:creator>jm</dc:creator><description><![CDATA['This paper and talk was given by the LinkedIn Voldemort Team at the Workshop on Big Data Benchmarking (WBDB May 2012).'

<blockquote>
With SSD, we find that garbage collection will become a very significant bottleneck, especially for systems which have little control over the storage layer and rely on Java memory management. Big heapsizes make the cost of garbage collection expensive, especially the single threaded CMS Initial mark. We believe that data systems must revisit their caching strategies with SSDs. In this regard, SSD has provided an efficient solution for handling fragmentation and moving towards predictable multitenancy.</blockquote>]]></description>
<dc:subject>voldemort storage ssd disk linkedin big-data jvm tuning ops gc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:086f50102a3b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voldemort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:big-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.jclarity.com/products/censum/">
    <title> Censum</title>
    <dc:date>2013-07-25T11:43:37+00:00</dc:date>
    <link>http://www.jclarity.com/products/censum/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>[JVM] GC is a difficult, specialised area that can be very frustrating for busy developers or devops folks to deal with. The JVM has a number of Garbage Collectors and a bewildering array of switches that can alter the behaviour of each collector. Censum does all of the parsing, number crunching and statistical analysis for you, so you don't have to go and get that PhD in Computer Science in order to solve your GC performance problem.  Censum gives you straight answers as opposed to a ton of raw data. can eat any GC log you care to throw at it. is easy to install and use.</blockquote>

Commercial software, UKP 495 per license.]]></description>
<dc:subject>censum gc tuning ops java jvm commercial</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ed538dc1a0a6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:censum"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:commercial"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://java-is-the-new-c.blogspot.ie/2013/07/tuning-and-benchmarking-java-7s-garbage.html">
    <title>Tuning and benchmarking Java 7's Garbage Collectors: Default, CMS and G1</title>
    <dc:date>2013-07-25T11:27:30+00:00</dc:date>
    <link>http://java-is-the-new-c.blogspot.ie/2013/07/tuning-and-benchmarking-java-7s-garbage.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Rudiger Moller runs through a typical GC-tuning session, in exhaustive detail]]></description>
<dc:subject>java gc tuning jvm cms g1 ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6ef833ae0fa3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mechanical-sympathy.blogspot.ca/2013/07/java-garbage-collection-distilled.html">
    <title>Java Garbage Collection Distilled</title>
    <dc:date>2013-07-16T22:22:21+00:00</dc:date>
    <link>http://mechanical-sympathy.blogspot.ca/2013/07/java-garbage-collection-distilled.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a great summary of the state of JVM garbage collection from Martin Thompson]]></description>
<dc:subject>jvm java gc garbage-collection tuning memory performance martin-thompson</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f32e30988004/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:garbage-collection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:martin-thompson"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://distributeddreams.blogspot.ie/2012/04/making-sense-out-of-bdb-je-fast-stats.html">
    <title>Making sense out of BDB-JE fast stats</title>
    <dc:date>2013-05-14T20:42:42+00:00</dc:date>
    <link>http://distributeddreams.blogspot.ie/2012/04/making-sense-out-of-bdb-je-fast-stats.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good info on the system metrics recorded by BDB-JE's EnvironmentStats code, particularly where cache and cleaner activity are concerned.  Particularly useful for Voldemort]]></description>
<dc:subject>voldemort caching bdb bdb-je storage tuning ops metrics reference</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:14b3ea9af8a3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voldemort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bdb-je"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reference"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.psc.edu/index.php/networking/641-tcp-tune">
    <title>TCP Tune</title>
    <dc:date>2013-04-05T16:15:57+00:00</dc:date>
    <link>http://www.psc.edu/index.php/networking/641-tcp-tune</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>These notes are intended to help users and system administrators maximize TCP/IP performance on their computer systems. They summarize all of the end-system (computer system) network tuning issues including a tutorial on TCP tuning, easy configuration checks for non-experts, and a repository of operating system specific instructions for getting the best possible network performance on these platforms.</blockquote>

Some tips for maximizing HPC network performance for the intra-DC case; recommended by the LinkedIn Kafka operations page.]]></description>
<dc:subject>tuning network tcp sysadmin performance ops kafka ec2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:90ef24f751cb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://imho.nu/iMHo/tcp-optimizer/">
    <title>IOS TCP wifi optimizer</title>
    <dc:date>2013-02-28T21:45:40+00:00</dc:date>
    <link>http://imho.nu/iMHo/tcp-optimizer/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Basically, tweaking a few suboptimal sysctls to optimize for 802.11b/n; requires a Jailbroken IOS device.  I'm surprised that Apple defaulted segment size to 512 to be honest, and disabling delayed ACKs sounds like it might be useful (see also http://www.stuartcheshire.org/papers/NagleDelayedAck/).

<blockquote>TCP optimizer modifies a few settings inside iOS, including increasing the TCP receive buffer from 131072 to 292000, disabling TCP delayed ACK’s, allowing a maximum of 16 un-ACK’d packets instead of 8 and set the default packet size to 1460 instead of 512. These changes won’t only speed up your YouTube videos, they’ll also improve your internet connection’s performance overall, including Wi-Fi network connectivity.</blockquote>
]]></description>
<dc:subject>tcp performance tuning ios apple wifi wireless 802.11n sysctl ip</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:96226cdb6566/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wireless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:802.11n"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysctl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/aszegedi/everything-i-ever-learned-about-jvm-performance-tuning-twitter">
    <title>Everything I Ever Learned About JVM Performance Tuning @Twitter</title>
    <dc:date>2012-12-01T18:51:22+00:00</dc:date>
    <link>http://www.slideshare.net/aszegedi/everything-i-ever-learned-about-jvm-performance-tuning-twitter</link>
    <dc:creator>jm</dc:creator><description><![CDATA[presentation by Attila Szegedi of Twitter from last year.  Some good tips here, well-presented]]></description>
<dc:subject>tuning jvm java gc cms presentations slides twitter</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:80c49db84474/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.explainmydata.com/2012/07/expensive-lessons-in-python-performance.html">
    <title>Expensive lessons in Python performance tuning</title>
    <dc:date>2012-07-23T10:05:43+00:00</dc:date>
    <link>http://blog.explainmydata.com/2012/07/expensive-lessons-in-python-performance.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some good advice for large-scale Python performance: prun and guppy for profiling, namedtuples for memory efficiency, and picloud for trivial EC2-based scale-out.  (via Nelson)]]></description>
<dc:subject>picloud prun guppy namedtuples python optimization performance tuning profiling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:78e224a43e8c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:picloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prun"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:guppy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:namedtuples"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/boundary_slides/garbage-garbage-everywhere">
    <title>Scott Andreas - Garbage, Garbage Everywhere [slides]</title>
    <dc:date>2011-12-04T23:00:35+00:00</dc:date>
    <link>http://www.slideshare.net/boundary_slides/garbage-garbage-everywhere</link>
    <dc:creator>jm</dc:creator><description><![CDATA['GC Strategies for Event Processing Systems on the JVM']]></description>
<dc:subject>gc java jvm event-streams event-processing tuning slides presentations scott-andreas performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:750e291a35af/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:event-streams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:event-processing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scott-andreas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/">
    <title>The MySQL “swap insanity” problem and the effects of the NUMA architecture</title>
    <dc:date>2010-09-29T15:48:24+00:00</dc:date>
    <link>http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[very interesting; modern multicore x86 architectures use a NUMA memory architecture, which can cause a dip into swap, even when there appears to be plenty of free RAM available]]></description>
<dc:subject>linux memory mysql optimization performance swap tuning vm numa swap-insanity swapping</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:6aad45b4a7bc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:numa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swap-insanity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swapping"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blip.tv/file/2232410">
    <title>Mindblowing Python GIL</title>
    <dc:date>2010-02-19T11:55:55+00:00</dc:date>
    <link>http://blip.tv/file/2232410</link>
    <dc:creator>jm</dc:creator><description><![CDATA['presentation about how the Python GIL actually works and why it's even worse than most people even imagine.'  A good chunk btw could be rephrased as 'pthreads is worse than most people even imagine'.  pretty awful data, though]]></description>
<dc:subject>python gil locking synchronization ouch performance tuning coding interpreters threads pthreads</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:005314349ca9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synchronization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ouch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interpreters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pthreads"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>