ElasticSearch 5.1.2:
Bootstrap is passed except system_call_filter "Seccomp", CentOS 6环境
背景:
每个doc,1200fields, 4KB每个DOC。所有的fields只有三种类型:date, keyword, numberic。 2400W记录一个INDEX。主要用作实时数据分析
有三个数据节点(master:true; data:true; ingest:default true)
一个独立的 ingest 节点(master:false; data:false; ingest:true).
所有的节点 JVM 配置都是一样,如下。 每个节点64GB内存,SSD,24核, 物理机。
jvm.options:
-Xms24g
-Xmx24g
-XX:NewSize=8g
-XX:MaxNewSize=8g
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
通过 elasticsearch-spark, DataFrame.saveToEs() 方法bulk 插入ES。 10个Client同时往Ingest Node插入。
性能如下
Ingest 节点
其中一个数据节点:
4个节点。总体性能才1000doc/s。平均indexing每个DOC需要 4ms。所有的节点CPU使用率插入期间 10%以下。也没有 throttle, bulk queue, bulk rejections, index queue, index rejections or other issues等现象 从kibana monitoring的图中显示。
以更高的并发client写,性能会下降。
Settings of Index:
"settings": {
"index": {
"number_of_shards": 3,
"number_of_replicas": 0,
"mapping.total_fields.limit": 1500,
"refresh_interval": "60s"
}
mapping:
"dynamic": false,
"_all": {
"enabled": false
},
集群设置
Cluster:
{
"persistent": {
"indices": {
"store": {
"throttle": {
"max_bytes_per_sec": "100mb"
}
}
}
},
"transient": {}
}
其他的设置都是默认设置。
遇到的问题是:INDEXINGH性能很差。只有1000DOC/S,换算下来才4MB/S。
从截图可以发现INGEST Node的性能比DATA Node还要差,不理解为什么。 Ingest node 有非常多的young gc, full, gc。
从官方文档来看 ingest干了如下的事情
• intercepts bulk and index requests
• applies the transformations
• passes the documents back to the index or bulk APIs
我们没有使用pipeline。
在另一个虚拟机里搭的Ingest node的JVM DUMP如下。导数据的时候,Ingest node几G的空间,瞬间就被吃完了。
主要是byte[]。 写入速度700DOC/S。
综上,想求教如此耗内存的原因? Ingest node 这样不合理啊
Bootstrap is passed except system_call_filter "Seccomp", CentOS 6环境
背景:
每个doc,1200fields, 4KB每个DOC。所有的fields只有三种类型:date, keyword, numberic。 2400W记录一个INDEX。主要用作实时数据分析
有三个数据节点(master:true; data:true; ingest:default true)
一个独立的 ingest 节点(master:false; data:false; ingest:true).
所有的节点 JVM 配置都是一样,如下。 每个节点64GB内存,SSD,24核, 物理机。
jvm.options:
-Xms24g
-Xmx24g
-XX:NewSize=8g
-XX:MaxNewSize=8g
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
通过 elasticsearch-spark, DataFrame.saveToEs() 方法bulk 插入ES。 10个Client同时往Ingest Node插入。
性能如下
Ingest 节点
其中一个数据节点:
4个节点。总体性能才1000doc/s。平均indexing每个DOC需要 4ms。所有的节点CPU使用率插入期间 10%以下。也没有 throttle, bulk queue, bulk rejections, index queue, index rejections or other issues等现象 从kibana monitoring的图中显示。
以更高的并发client写,性能会下降。
Settings of Index:
"settings": {
"index": {
"number_of_shards": 3,
"number_of_replicas": 0,
"mapping.total_fields.limit": 1500,
"refresh_interval": "60s"
}
mapping:
"dynamic": false,
"_all": {
"enabled": false
},
集群设置
Cluster:
{
"persistent": {
"indices": {
"store": {
"throttle": {
"max_bytes_per_sec": "100mb"
}
}
}
},
"transient": {}
}
其他的设置都是默认设置。
遇到的问题是:INDEXINGH性能很差。只有1000DOC/S,换算下来才4MB/S。
从截图可以发现INGEST Node的性能比DATA Node还要差,不理解为什么。 Ingest node 有非常多的young gc, full, gc。
从官方文档来看 ingest干了如下的事情
• intercepts bulk and index requests
• applies the transformations
• passes the documents back to the index or bulk APIs
我们没有使用pipeline。
在另一个虚拟机里搭的Ingest node的JVM DUMP如下。导数据的时候,Ingest node几G的空间,瞬间就被吃完了。
主要是byte[]。 写入速度700DOC/S。
综上,想求教如此耗内存的原因? Ingest node 这样不合理啊
1 个回复
Hannibal_
赞同来自:
es版本1,7,2,8个节点,按按天建索引,一天的数据8千万~九千万
我测试的是spark的并行度不能太高,太高会抛出超时异常,到后面数据入库进不去。我现在是设置的8个partition,给了32个executor,同事最多有四个task在入库,这个入库目前是正常的数据能正常进去 如果有数据积累还是抗住不。
我的感觉是流任务入库慢,但是离线入库就快多了