# Bulk Processor taking too long **URL:** \ **Category:** Elasticsearch\ **Created:** [May 9, 2018, 2:28pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183 "2018-05-09T14:28:54Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Sivapriya\_1](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@Sivapriya\_1](https://discuss.elastic.co/u/Sivapriya_1)\ **Post date:** [May 9, 2018, 2:28pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/1 "2018-05-09T14:28:54Z")
I'm using the bulk API to index my docs and it is taking longer than expected. My bulk processor client is as follows \ So for 5 mb bulk request (which is about 45 docs) it is taking about ~1s. My index settings are default. I disabled refresh when the indexing is in process. Any thoughts would be appreciated ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [May 9, 2018, 2:43pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/2 "2018-05-09T14:43:00Z")
Why do you think it's too long? It depends a lot on the documents, the mapping, the hardware... What if you send more documents than 45? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [May 9, 2018, 2:44pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/3 "2018-05-09T14:44:44Z")
How many parallel indexing threads/processes do you have? ---
**Author:** ![Sivapriya\_1](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@Sivapriya\_1](https://discuss.elastic.co/u/Sivapriya_1)\ **Post date:** [May 9, 2018, 2:58pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/4 "2018-05-09T14:58:16Z")
If you mean this setting on the bulk processor - 'setConcurrentRequests()', I tried with 5, 10, 15. no difference ---
**Author:** ![Sivapriya\_1](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@Sivapriya\_1](https://discuss.elastic.co/u/Sivapriya_1)\ **Post date:** [May 9, 2018, 2:59pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/5 "2018-05-09T14:59:50Z")
Increasing the bulk size to allow more documents in one bulk request doesn't make much of a difference either. When you say it depends on the mapping, what kind of things in a mapping would affect the performance. Would having too many keyword fields be any concern? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [May 9, 2018, 3:01pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/6 "2018-05-09T15:01:27Z")
What is the specification of your Elasticsearch cluster? How many nodes? What type of hardware and storage? What does CPU usage and disk I/O look like in the cluster while indexing? Are you using dynamic mappings? If so are new fields frequently mapped? ---
**Author:** ![Sivapriya\_1](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@Sivapriya\_1](https://discuss.elastic.co/u/Sivapriya_1)\ **Post date:** [May 9, 2018, 3:08pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/7 "2018-05-09T15:08:02Z")
I'm running ES in a docker container in my localhost. My cluster/node settings { "\_nodes": { "total": 1, "successful": 1, "failed": 0 }, "cluster\_name": "docker-cluster", "nodes": { "OY2gXh4qQZOFIMiDOcu9Bw": { "name": "OY2gXh4", "transport\_address": "172.17.0.2:9300", "host": "172.17.0.2", "ip": "172.17.0.2", "version": "6.2.4", "build\_hash": "ccec39f", "total\_indexing\_buffer": 103887667, "roles": [ "master", "data", "ingest" ], "settings": { "cluster": { "name": "docker-cluster" }, "node": { "name": "OY2gXh4" }, "path": { "logs": "/usr/share/elasticsearch/logs", "home": "/usr/share/elasticsearch" }, "discovery": { "type": "single-node", "zen": { "minimum\_master\_nodes": "1" } }, "client": { "type": "node" }, "http": { "type": { "default": "netty4" } }, "transport": { "type": { "default": "netty4" } }, "network": { "host": "0.0.0.0" } }, "os": { "refresh\_interval\_in\_millis": 1000, "name": "Linux", "arch": "amd64", "version": "4.9.12-moby", "available\_processors": 4, "allocated\_processors": 4 }, "process": { "refresh\_interval\_in\_millis": 1000, "id": 1, "mlockall": false }, "jvm": { "pid": 1, "version": "1.8.0\_161", "vm\_name": "OpenJDK 64-Bit Server VM", "vm\_version": "25.161-b14", "vm\_vendor": "Oracle Corporation", "start\_time\_in\_millis": 1524848868469, "mem": { "heap\_init\_in\_bytes": 1073741824, "heap\_max\_in\_bytes": 1038876672, "non\_heap\_init\_in\_bytes": 2555904, "non\_heap\_max\_in\_bytes": 0, "direct\_max\_in\_bytes": 1038876672 }, "gc\_collectors": [ "ParNew", "ConcurrentMarkSweep" ], "memory\_pools": [ "Code Cache", "Metaspace", "Compressed Class Space", "Par Eden Space", "Par Survivor Space", "CMS Old Gen" ], "using\_compressed\_ordinary\_object\_pointers": "true", "input\_arguments": [ "-Xms1g", "-Xmx1g", "-XX:+UseConcMarkSweepGC", "-XX:CMSInitiatingOccupancyFraction=75", "-XX:+UseCMSInitiatingOccupancyOnly", "-XX:+AlwaysPreTouch", "-Xss1m", "-Djava.awt.headless=true", "-Dfile.encoding=UTF-8", "-Djna.nosys=true", "-XX:-OmitStackTraceInFastThrow", "-Dio.netty.noUnsafe=true", "-Dio.netty.noKeySetOptimization=true", "-Dio.netty.recycler.maxCapacityPerThread=0", "-Dlog4j.shutdownHookEnabled=false", "-Dlog4j2.disable.jmx=true", "-Djava.io.tmpdir=/tmp/elasticsearch.aDuysB5f", "-XX:+HeapDumpOnOutOfMemoryError", "-XX:+PrintGCDetails", "-XX:+PrintGCDateStamps", "-XX:+PrintTenuringDistribution", "-XX:+PrintGCApplicationStoppedTime", "-Xloggc:logs/gc.log", "-XX:+UseGCLogFileRotation", "-XX:NumberOfGCLogFiles=32", "-XX:GCLogFileSize=64m", "-Des.cgroups.hierarchy.override=/", "-Des.path.home=/usr/share/elasticsearch", "-Des.path.conf=/usr/share/elasticsearch/config" ] }, "thread\_pool": { "force\_merge": { "type": "fixed", "min": 1, "max": 1, "queue\_size": -1 }, "fetch\_shard\_started": { "type": "scaling", "min": 1, "max": 8, "keep\_alive": "5m", "queue\_size": -1 }, "listener": { "type": "fixed", "min": 2, "max": 2, "queue\_size": -1 }, "index": { "type": "fixed", "min": 4, "max": 4, "queue\_size": 200 }, "refresh": { "type": "scaling", "min": 1, "max": 2, "keep\_alive": "5m", "queue\_size": -1 }, "generic": { "type": "scaling", "min": 4, "max": 128, "keep\_alive": "30s", "queue\_size": -1 }, "warmer": { "type": "scaling", "min": 1, "max": 2, "keep\_alive": "5m", "queue\_size": -1 }, "search": { "type": "fixed\_auto\_queue\_size", "min": 7, "max": 7, "queue\_size": 1000 }, "flush": { "type": "scaling", "min": 1, "max": 2, "keep\_alive": "5m", "queue\_size": -1 }, "fetch\_shard\_store": { "type": "scaling", "min": 1, "max": 8, "keep\_alive": "5m", "queue\_size": -1 }, "management": { "type": "scaling", "min": 1, "max": 5, "keep\_alive": "5m", "queue\_size": -1 }, "get": { "type": "fixed", "min": 4, "max": 4, "queue\_size": 1000 }, "bulk": { "type": "fixed", "min": 4, "max": 4, "queue\_size": 200 }, "snapshot": { "type": "scaling", "min": 1, "max": 2, "keep\_alive": "5m", "queue\_size": -1 } }, "transport": { "bound\_address": [ "[::]:9300" ], "publish\_address": "172.17.0.2:9300", "profiles": {} }, "http": { "bound\_address": [ "[::]:9200" ], "publish\_address": "172.17.0.2:9200", "max\_content\_length\_in\_bytes": 104857600 } } ---
**Author:** ![Sivapriya\_1](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@Sivapriya\_1](https://discuss.elastic.co/u/Sivapriya_1)\ **Post date:** [May 9, 2018, 3:12pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/8 "2018-05-09T15:12:43Z")
And regarding the cpu and disk I/O should I be looking at this command - 'GET /\_nodes/stats/process' to get those metrics ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [May 9, 2018, 3:28pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/9 "2018-05-09T15:28:06Z")
Look at `top` and `iostat -x`. Given that you have a single node with 1GB heap, are you seeing any messages about frequent or long GC in the Elasticsearch logs? ---
**Author:** ![Sivapriya\_1](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@Sivapriya\_1](https://discuss.elastic.co/u/Sivapriya_1)\ **Post date:** [May 9, 2018, 4:12pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/10 "2018-05-09T16:12:12Z")
Ok I kicked of another upload of around 89000 docs and it took about 20 min. I monitored cpu usage directly via terminal using the 'top' command and as the upload progressed the cpu usage was around 75 - 90%. where as when I ran the command GET /\_nodes/stats/process in kibana, the cpu precent showed around 50% with few spikes up to 70%. (not sure why is there a difference between them i.e terminal vs kibana) The jvm heap used percent was around 50 - 70% ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 6, 2018, 4:12pm UTC](https://discuss.elastic.co/t/bulk-processor-taking-too-long/131183/11 "2018-06-06T16:12:13Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.