<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>profiling &#8211; Robust Perception | Prometheus Monitoring Experts</title>
	<atom:link href="/tag/profiling/feed" rel="self" type="application/rss+xml" />
	<link>/</link>
	<description>Prometheus Monitoring Experts</description>
	<lastBuildDate>Fri, 04 Oct 2019 14:52:01 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.9.3</generator>

<image>
	<url>/wp-content/uploads/2015/07/cropped-robust-icon-32x32.png</url>
	<title>profiling &#8211; Robust Perception | Prometheus Monitoring Experts</title>
	<link>/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>How much RAM does Prometheus 2.x need for cardinality and ingestion?</title>
		<link>/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Mon, 06 May 2019 07:01:51 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[profiling]]></category>
		<category><![CDATA[prometheus]]></category>
		<category><![CDATA[tsdb]]></category>
		<guid isPermaLink="false">https://www.robustperception.io/?p=4416</guid>

					<description><![CDATA[I previously looked at ingestion memory for 1.x, how about 2.x? Prometheus 2.x has a very different ingestion system to 1.x, with many performance improvements. This time I'm also going to take into account the cost of cardinality in the head block. To start with I took a profile of a Prometheus 2.9.2 ingesting from [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Using tsdb analyze to investigate churn and cardinality</title>
		<link>/using-tsdb-analyze-to-investigate-churn-and-cardinality</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Mon, 04 Feb 2019 08:41:39 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[profiling]]></category>
		<category><![CDATA[prometheus]]></category>
		<category><![CDATA[tsdb]]></category>
		<guid isPermaLink="false">https://www.robustperception.io/?p=4265</guid>

					<description><![CDATA[The Prometheus TSDB's code base includes a tool to help you find "interesting" metrics in terms of storage performance. When it comes to Prometheus resource usage and efficiency, the important questions are around cardinality and churn. That is how many time series you have, and how often the set of time series changes. I recently [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Optimising Prometheus 2.6.0 Memory Usage with pprof</title>
		<link>/optimising-prometheus-2-6-0-memory-usage-with-pprof</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Mon, 21 Jan 2019 10:48:04 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[golang]]></category>
		<category><![CDATA[profiling]]></category>
		<category><![CDATA[prometheus]]></category>
		<category><![CDATA[tsdb]]></category>
		<guid isPermaLink="false">https://www.robustperception.io/?p=4241</guid>

					<description><![CDATA[The 2.6.0 release of Prometheus includes optimisations to reduce the memory taken by indexes and compaction. There have been some reports that compaction was causing larger memory spikes than was desirable. I dug into this and improved it for Prometheus 2.6.0, so let's see how. Firstly I wrote a test setup that created some samples for [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Optimising startup time of Prometheus 2.6.0 with pprof</title>
		<link>/optimising-startup-time-of-prometheus-2-6-0-with-pprof</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Mon, 07 Jan 2019 09:15:19 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[golang]]></category>
		<category><![CDATA[profiling]]></category>
		<category><![CDATA[prometheus]]></category>
		<category><![CDATA[tsdb]]></category>
		<guid isPermaLink="false">https://www.robustperception.io/?p=4189</guid>

					<description><![CDATA[The 2.6.0 release of Prometheus includes WAL loading optimisations to make startup faster. The informal design goal of the Prometheus 2.x TSDB startup was that it should take no more than about a minute. Over the past few months there's been reports of it taking quite a bit more than this, which is a problem [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Optimising Go allocations using pprof</title>
		<link>/optimising-go-allocations-using-pprof</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Mon, 23 Jan 2017 08:30:44 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[golang]]></category>
		<category><![CDATA[profiling]]></category>
		<category><![CDATA[prometheus]]></category>
		<guid isPermaLink="false">https://www.robustperception.io/?p=2502</guid>

					<description><![CDATA[As I mentioned in a previous post, I made some memory-related improvements to Prometheus that'll be in the 1.5 release. Let's look at how I came across unneeded memory allocations and ultimately improved the code. &#160; My initial goal was to provide guidance to Prometheus users on how many resources they should provision for a given load and what flag [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Which targets have the most samples?</title>
		<link>/which-targets-have-the-most-samples</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Wed, 07 Dec 2016 19:12:37 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[profiling]]></category>
		<category><![CDATA[prometheus]]></category>
		<category><![CDATA[promql]]></category>
		<guid isPermaLink="false">https://www.robustperception.io/?p=2380</guid>

					<description><![CDATA[We previously looked at finding your biggest metrics, that involves an expensive query though. A new feature in Prometheus 1.3 offers another approach. scrape_samples_scraped, like up, is a time series automatically generated by Prometheus as part of doing a scrape. It reports the numbers of samples that the target produced, before metric_relabel_configs is applied. This can be used [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Analysing Prometheus Memory Usage</title>
		<link>/analysing-prometheus-memory-usage</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Tue, 21 Jun 2016 22:53:41 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[profiling]]></category>
		<category><![CDATA[prometheus]]></category>
		<guid isPermaLink="false">http://www.robustperception.io/?p=1922</guid>

					<description><![CDATA[Ever wondered how Prometheus is using its memory? Let's find out! Prometheus is linked with pprof, a Go profiling tool that makes it easy to look at CPU and memory usage. To use it against a local Prometheus server to investigate memory usage, ensure you have a working Go install and then run: go tool pprof [&#8230;]]]></description>
		
		
		
			</item>
	</channel>
</rss>
