<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Scaling kv store performance in Knowledge Management</title>
    <link>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271312#M2391</link>
    <description>&lt;P&gt;For the size of my kvstore it actually slows it down even more.&lt;/P&gt;

&lt;P&gt;The writes first need to be performed by the captain in the search head cluster and then replicated out to over 30 indexers.&lt;/P&gt;</description>
    <pubDate>Fri, 29 Jul 2016 12:08:45 GMT</pubDate>
    <dc:creator>Lucas_K</dc:creator>
    <dc:date>2016-07-29T12:08:45Z</dc:date>
    <item>
      <title>Scaling kv store performance</title>
      <link>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271310#M2389</link>
      <description>&lt;P&gt;I am encountering an issue with the kvstore (6.4.1/6.4.2) where i am hitting a relative performance limit with update/insert records.&lt;/P&gt;

&lt;P&gt;I have tried different search head architectures, both standalone and clustered (8 members). Hardward based, vm based, and even an i7 laptop.&lt;BR /&gt;
I have tried splitting my searches into small timeframes (1 minute per search) so there are less events to update per search.&lt;BR /&gt;
I have tried staggering my searches so that the small timeframes have even less concurrent kvstore operations occuring at the same time.&lt;/P&gt;

&lt;P&gt;Regardless of what I try I hit a limit of between 1500-1800 record updates per minute. &lt;/P&gt;

&lt;P&gt;I have a use case where I need to update around 2 million records every 10 minutes. At a 1.5-1.8k update rate I am looking at an 18-22 minute run time for a 10 min window. Due to the cumulative performance limit of the kvstore it doesn't help when I split the searches so more can run concurrently. All it does it slow down the kvstore writes.&lt;/P&gt;

&lt;P&gt;Using a search head cluster with multiple kv stores doesn't help as all the writes are delegated to the captain anyway.&lt;/P&gt;

&lt;P&gt;I've tried the following limits.conf settings but performance doesn't really change much.&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[kvstore]
max_queries_per_batch =  20000
max_rows_per_query = 1000000
max_queries_per_batch = 20000
max_size_per_result_mb = 5000
max_accelerations_per_collection = 0 
max_fields_per_acceleration = 0
max_threads_per_outputlookup = 0
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;Any suggestions on speeding up the kvstore?&lt;/P&gt;</description>
      <pubDate>Tue, 26 Jul 2016 06:10:29 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271310#M2389</guid>
      <dc:creator>Lucas_K</dc:creator>
      <dc:date>2016-07-26T06:10:29Z</dc:date>
    </item>
    <item>
      <title>Re: Scaling kv store performance</title>
      <link>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271311#M2390</link>
      <description>&lt;P&gt;Have you tried setting replicate=true in your collections.conf and local=false in your lookup command? This will allow the lookup to run on the indexers. See &lt;A href="http://dev.splunk.com/view/SP-CAAAEZJ#replication"&gt;http://dev.splunk.com/view/SP-CAAAEZJ#replication&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 27 Jul 2016 17:51:47 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271311#M2390</guid>
      <dc:creator>masonmorales</dc:creator>
      <dc:date>2016-07-27T17:51:47Z</dc:date>
    </item>
    <item>
      <title>Re: Scaling kv store performance</title>
      <link>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271312#M2391</link>
      <description>&lt;P&gt;For the size of my kvstore it actually slows it down even more.&lt;/P&gt;

&lt;P&gt;The writes first need to be performed by the captain in the search head cluster and then replicated out to over 30 indexers.&lt;/P&gt;</description>
      <pubDate>Fri, 29 Jul 2016 12:08:45 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271312#M2391</guid>
      <dc:creator>Lucas_K</dc:creator>
      <dc:date>2016-07-29T12:08:45Z</dc:date>
    </item>
    <item>
      <title>Re: Scaling kv store performance</title>
      <link>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271313#M2392</link>
      <description>&lt;P&gt;I think it may be to do with mongodb internal indexing of fields.&lt;/P&gt;

&lt;P&gt;I'm making an assumption that splunks kv store "accelerated field" is actually a mongodb index or something similar.&lt;/P&gt;

&lt;P&gt;Just found this post in regards to kv "indexes" -&amp;gt; &lt;A href="https://answers.splunk.com/answers/246404/how-to-create-an-index-on-a-kvstore.html"&gt;https://answers.splunk.com/answers/246404/how-to-create-an-index-on-a-kvstore.html&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;So it seems that by having my key accelerated im actually slowing down inserts.&lt;/P&gt;

&lt;P&gt;This &lt;A href="http://stackoverflow.com/questions/22077685/mongodb-update-upsert-performance-barrier-performance-falls-off-a-cliff"&gt;mongodb post&lt;/A&gt; seems to suggest that true mongodb indexes actually increase upsert performance. This contradicts the splunk answers post in relation to accelerations.&lt;/P&gt;</description>
      <pubDate>Fri, 29 Jul 2016 12:19:53 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Knowledge-Management/Scaling-kv-store-performance/m-p/271313#M2392</guid>
      <dc:creator>Lucas_K</dc:creator>
      <dc:date>2016-07-29T12:19:53Z</dc:date>
    </item>
  </channel>
</rss>

