Elasticsearch 使用积累原文链接：
接触Elasticsearch已经有几年的时间, 从一开始在自己的普通台式机上搭建单实例来简单记录测试环境的日志, 到现在生产上用9个Elasticsearch实例搭成的集群来记录商城后台服务的全量日志. 使用场景没变,都是用了记录日志, 并做实时检索和统计. 但是随着每天记录的数据量快速递增,QPS快速递增,我们经常会碰到一些性能问题,这些问题一直在驱动我们对Elasticsearch集群进行持续优化, 这里是有必要记录一下我们在使用ES(后续文章中用ES代替Elasticsearch)的过程中积累的经验.
查看分片情况,操作简单api
监控所在机器的CPU,IO,JVM等指标,简单分片概览
查看集群gc回收磁盘性能, 分片情况, 简单操作api, 感觉该插件较Head更实用一些
可以通过sql进行聚合检索, 可以将sql语句翻译成ES的JSON检索语句
ES集群优雅停止,启动
在一开始使用ES的时候, 都是通过 kill &pid& (不是Kill -9)来关闭ES实例. 但是每回重启后, 都会发现有很长时间的分片同步(即使没有手动删除数据等操作). 后来发现ES默认是开启自动分片均衡的. 那么如果想要我们在停止,启动某个ES实例后, 可以快速将集群状态变更为Green. 我们最好可以采用如下步骤进行:
暂停集群的分片自动均衡(在集群中任一台ES实例上执行都可以,只需要执行一次) curl -XPUT http://127.0.0.1:9200/_cluster/settings -d'
"transient" : {
"cluster.routing.allocation.enable" : "none"
优雅停止你要升级或检测的ES实例(不到万不得已,绝对不要用Kill -9) curl -XPOST http://127.0.0.1:9200/_cluster/nodes/_local/_shutdown
备注: 在2.0版本之后将废弃该api The _shutdown API has been removed without a replacement. Nodes should be managed via the operating system and the provided start/stop scripts.
升级重启该节点，并确认该节点重新加入到了集群中
重复上面的2,3步，操作其他集群内其他ES实例
重新启动集群的分片自动均衡(在集群中任一ES实例中执行一次即可) curl -XPUT http://127.0.0.1:9200/_cluster/settings -d'
"transient" : {
"cluster.routing.allocation.enable" : "all"
备注: 如果在集群中关闭自动均衡, 业务程序在插入数据时,不会自动创建索引, 需要预先创建好索引
ES集群JVM调优积累
在最开始, 我们使用的ES实例,没有涉及到很大的数据写入和检索(每天几百万数据). 当时我们配置ES的JVM(Xms=Xmx=8G)的垃圾回收器主要是CMS,具体配置如下: # reduce the per-thread stack size
JAVA_OPTS="$JAVA_OPTS -Xss256k"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
这个在小数据量,小内存时运行良好, 基本很少会出现Full gc.
后来我们的数据量为了一天1亿多, 为了加快检索, 我们将Xms,Xmx同时调整为32G. 并按天进行索引,后来发现随着索引数增加,写入数据量增加, Full GC已经影响到了我们的写入和检索(这个时候我们的ES集群是三个实例).我们决定将G1作为垃圾回收期,但是,
我们还是想尝试一下换成G1, 并借此机会把JDK从1.7升级到1.8(升级很平滑), G1的具体配置如下:
JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC "
#init_globals()末尾打印日志
JAVA_OPTS="$JAVA_OPTS -XX:+PrintFlagsFinal "
#打印gc引用
JAVA_OPTS="$JAVA_OPTS -XX:+PrintReferenceGC "
#输出虚拟机中GC的详细情况.
JAVA_OPTS="$JAVA_OPTS -verbose:gc "
JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCDetails "
#Enables printing of time stamps at every GC. By default, this option is disabled.
JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCTimeStamps "
#Enables printing of information about adaptive generation sizing. By default, this option is disabled.
JAVA_OPTS="$JAVA_OPTS -XX:+PrintAdaptiveSizePolicy "
# unlocks diagnostic JVM options
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockDiagnosticVMOptions "
#to measure where the time is spent
JAVA_OPTS="$JAVA_OPTS -XX:+G1SummarizeConcMark "
#设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%。
#JAVA_OPTS="$JAVA_OPTS -XX:InitiatingHeapOccupancyPercent=45 "
TODO 之后会在这补充替换为G1后,ES集群的表现
ES集群健康说明
在Elasticsearch集群中可以监控统计很多信息，其中最重要的就是：集群健康(cluster health)。它的 status 有 green、yellow、red 三种；
可以通过如下命令获取: GET http://127.0.0.1:9200/_cluster/health
在一个没有索引的空集群中，它将返回如下信息： {
"cluster_name":
"elasticsearch",
"green", &1&
"timed_out":
"number_of_nodes":
"number_of_data_nodes":
"active_primary_shards": 0,
"active_shards":
"relocating_shards":
"initializing_shards":
"unassigned_shards":
status 是我们最应该关注的字段。
status 可以告诉我们当前集群是否处于一个可用的状态。三种颜色分别代表：
green : 所有主分片和从分片都可用
yellow: 所有主分片可用，但存在不可用的从分片
red: 存在不可用的主要分片
ES配置文件详解 cluster.name: elasticsearch
#配置es的集群名称，默认是elasticsearch，es会自动发现在同一网段下的es，如果在同一网段下有多个集群，就可以用这个属性来区分不同的集群。
node.name: "Franz Kafka"
#节点名，默认随机指定一个name列表中名字，该列表在es的jar包中config文件夹里name.txt文件中，其中有很多作者添加的有趣名字。
node.master: true
#指定该节点是否有资格被选举成为node，默认是true，es是默认集群中的第一台机器为master，如果这台机挂了就会重新选举master。
node.data: true
#指定该节点是否存储索引数据，默认为true。
index.number_of_shards: 5
#设置默认索引分片个数，默认为5片。
index.number_of_replicas: 1
#设置默认索引副本个数，默认为1个副本。
path.conf: /path/to/conf
#设置配置文件的存储路径，默认是es根目录下的config文件夹。
path.data: /path/to/data
#设置索引数据的存储路径，默认是es根目录下的data文件夹，可以设置多个存储路径，用逗号隔开，例：
#path.data: /path/to/data1,/path/to/data2
path.work: /path/to/work
#设置临时文件的存储路径，默认是es根目录下的work文件夹。
path.logs: /path/to/logs
#设置日志文件的存储路径，默认是es根目录下的logs文件夹
path.plugins: /path/to/plugins
#设置插件的存放路径，默认是es根目录下的plugins文件夹
bootstrap.mlockall: true
#设置为true来锁住内存。因为当jvm开始swapping时es的效率会降低，所以要保证它不swap，可以把#ES_MIN_MEM和ES_MAX_MEM两个环境变量设置成同一个值，并且保证机器有足够的内存分配给es。同时也要#允许elasticsearch的进程可以锁住内存，linux下可以通过`ulimit -l unlimited`命令。
network.bind_host: 192.168.0.1
#设置绑定的ip地址，可以是ipv4或ipv6的，默认为0.0.0.0。
network.publish_host: 192.168.0.1
#设置其它节点和该节点交互的ip地址，如果不设置它会自动判断，值必须是个真实的ip地址。
network.host: 192.168.0.1
#这个参数是用来同时设置bind_host和publish_host上面两个参数。
transport.tcp.port: 9300
#设置节点间交互的tcp端口，默认是9300。
press: true
#设置是否压缩tcp传输时的数据，默认为false，不压缩。
http.port: 9200
#设置对外服务的http端口，默认为9200。
http.max_content_length: 100mb
#设置内容的最大容量，默认100mb
http.enabled: false
#是否使用http协议对外提供服务，默认为true，开启。
gateway.type: local
#gateway的类型，默认为local即为本地文件系统，可以设置为本地文件系统，分布式文件系统，hadoop的#HDFS，和amazon的s3服务器，其它文件系统的设置方法下次再详细说。
gateway.recover_after_nodes: 1
#设置集群中N个节点启动时进行数据恢复，默认为1。
gateway.recover_after_time: 5m
#设置初始化数据恢复进程的超时时间，默认是5分钟。
gateway.expected_nodes: 2
#设置这个集群中节点的数量，默认为2，一旦这N个节点启动，就会立即进行数据恢复。
cluster.routing.allocation.node_initial_primaries_recoveries: 4
#初始化数据恢复时，并发恢复线程的个数，默认为4。
cluster.routing.allocation.node_concurrent_recoveries: 2
#添加删除节点或负载均衡时并发恢复线程的个数，默认为4。
indices.recovery.max_size_per_sec: 0
#设置数据恢复时限制的带宽，如入100mb，默认为0，即无限制。
indices.recovery.concurrent_streams: 5
#设置这个参数来限制从其它分片恢复数据时最大同时打开并发流的个数，默认为5。
discovery.zen.minimum_master_nodes: 1
#设置这个参数来保证集群中的节点可以知道其它N个有master资格的节点。默认为1，对于大的集群来说，可以设置大一点的值（2-4）
discovery.zen.ping.timeout: 3s
#设置集群中自动发现其它节点时ping连接超时时间，默认为3秒，对于比较差的网络环境可以高点的值来防止自动发现时出错。
discovery.zen.ping.multicast.enabled: false
#设置是否打开多播发现节点，默认是true。
discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]
#设置集群中master节点的初始列表，可以通过这些节点来自动发现新加入集群的节点。
ES使用中碰到的问题
rejected execution (queue capacity 50) on org.elasticsearch.action.support.replication.TransportShar
该问题需要在配置文件中添加Thread pool参数. threadpool:
#这是批量插入时需要做的配置
type: fixed
# 设置的和cpu数量一致
queue_size: 10000
#检索时需要做的配置
tyep: fixed
# 设置的和cpu数量一致
queue_size: 10000
整个数据将会被处理它的节点载入内存中，所以如果请求量很大的话，留给其他请求的内存空间将会很少。bulk应该有一个最佳的限度。超过这个限制后，性能不但不会提升反而可能会造成宕机。
最佳的容量并不是一个确定的数值，它取决于你的硬件，你的文档大小以及复杂性，你的索引以及搜索的负载。幸运的是，这个平衡点 很容易确定：
试着去批量索引越来越多的文档。当性能开始下降的时候，就说明你的数据量太大了。一般比较好初始数量级是个文档，或者你的文档很大，你就可以试着减小队列。 有的时候看看批量请求的物理大小是很有帮助的。1000个1KB的文档和1000个1MB的文档的差距将会是天差地别的。比较好的初始批量容量是5-15MB。
同一天机器上不同的es实例, 同一个索引的主副分片被分在了同一台机器上
在构建es集群的前期, 机器数量比较少, 但是机器配置还不错,可能会在一个机器上挂好几个硬盘, 开启多个es实例. 这样少量的机器,可以创建超过机器数量的es实例, 充分利用集群硬件性能,同时也具备更好的可拓展性.
一台机器上多个es实例, 可能会使同一个索引的主副分片被分在同一台机器上,这样就降低了这个索引分片的健壮性,一旦这台机器挂了, 这个索引分片上的数据就是不可用的.
基于上述的描述, es配置文件中需要对所有es实例进行分组,以保证同一个索引的主副分片不在同一台集群中, 具体配置如下: #通过node.group建立一个属性为group
node.group: eagleye_19
#引用属性group的值
cluster.routing.allocation.awareness.attributes: group
java客户端可以检索句子的方法
之前因为存储的内容是中英文混合的, 所以分词的时候采用最小力度分词, 这样如果要检索句子的时候, 不知道为什么, 检索不出来, 最后使用了, 如下方式可以直接检索句子了:
BoolFilterBuilder bqb = FilterBuilders.boolFilter();
if(vo.getQueryStr() != null && !vo.getQueryStr().trim().equals("")){
bqb.must(FilterBuilders.queryFilter(QueryBuilders.queryStringQuery(
ESReservedCharsUtil.removeReservedChars(vo.getQueryStr())).defaultField("body").defaultOperator(QueryStringQueryBuilder.Operator.AND)).cache(true));
// 该种方式不能检索句子
// for(String _s : vo.getQueryStr().split("\\s+")) {
bqb.must(FilterBuilders.termFilter("body", _s));
批量删除索引
#可用批量删除名字以xxx-log-2015.06开头的索引
curl -XDELETE http://127.0.0.1:9201/xxx-log-2015.06*
保证最大限度的使用内存而不引起OutOfMemory
设置es的缓存类型为Soft Reference，它的主要特点是据有较强的引用功能。只有当内存不够的时候，才进行回收这类内存，因此在内存足够的时候，它们通常不被回收。另外，这些引 用对象还能保证在Java抛出OutOfMemory 异常之前，被设置为null。它可以用于实现一些常用图片的缓存，实现Cache的功能.在es的配置文件中做如下修改: index.cache.field.type: soft
通过修改Template,缩小索引大小,减小系统内存使用
在ES的Template中做如下调整 "_source": {'enabled': false}, //如果不需要展示一些字段信息,只是用统计功能, 可以直接关闭
"_all" : { "enabled" : false }, //不对所有字段进行自动索引,可以减小索引数量
//not_analyzed可以不分词, no:不索引, 去除index则会根据分词器进行分词并索引
"index": "not_analyzed",
"store": "false", //如果不需要存储, 不需要显示, 可以直接关闭
//设置了doc_values为true之后，字段创建时，就是用磁盘存储fielddata而不是内存中, fielddata在lucene中就是正排索引, 可以非常快速的帮助我们做数据聚合,排序使用, 倒排索引帮助我们快速检索. 正常如果doc_values为false, 正排索引是放在内存中, 比较消化内存资源. 如果设为true则会放在磁盘中.另外,有一个设置 indices.fielddata.cache.expire 可以设置fielddata 进入内存中的数据多久自动过期。注意，因为 ES 的 fielddata 本身是一种数据结构，而不是简单的缓存，所以过期删除 fielddata 是一个非常消耗资源的操作。ES 官方在文档中特意说明，这个参数绝对绝对不要设置！
"doc_values": true
"type": "string"
加快调整分片和副本时的恢复进度
副本配置和分片配置不一样，是可以随时调整的。有些较大的索引，甚至可以在做 optimize 前，先把副本全部取消掉，等 optimize 完后，再重新开启副本，节约单个 segment 的重复归并消耗。
ES 1.X 的版本升级非常平滑,向前兼容做的不错, 但是 从 1.x到2.x会有一些改动
index设置合理的刷新时间
建立的索引，不会立马查到，这是为什么elasticsearch为near-real-time的原因
需要配置index.refresh_interval参数，默认是1s。在template中设置如下: {
"logstash" : {
"order" : 0,
"template" : "eagleye-log*",
"settings" : {
"index.refresh_interval" : "2s"
"mappings" : {
"_all" : { "enabled" : false },
字段缓存(Field cache)设置
当对字段排序或者对字段做聚合（如 facet ）时，字段缓存（ Field cache ）非常重要。 Es 会将这些待排序或者聚合字段都加载到内存，以提高对这些字段的快速访问。注意，将字段都加载到内存是非常耗费资源的，所以，你应该保证 field cache 足够大，以足以将所有的结果都缓存起来，下次排序或 facet 时不用再次从磁盘进行加载。
可以通过设置 indices.fielddata.cache.size 为具体的大小，比如 2GB ，或者可用内存的百分比，比如 40% 。请注意，这个属性是 node 级别 ( 不是 index 级别的 ). 当这个缓存不够用时，为了跟新的缓存对象腾出空间，原来缓存的字段会被挤出来，这会导致系统性能下降。所以，请保证这个值足够大，能够满足业务需求。另外，如果你没有设置这个值， es 默认缓存可以无限大。所以，在生产环境注意要设置这个值。 indices.fielddata.cache.size:
查看集群健康状况的命令 curl -s localhost:9201/_cat/indices?v | sort -k3
减小es集群脑裂的配置优化
master尽量不作为data节点
discovery.zen.ping_timeout（默认值是3秒）修改,默认情况下，一个节点会认为，如果master节点在3秒之内没有应答，那么这个节点就是死掉了，而增加这个值，会增加节点等待响应的时间，从一定程度上会减少误判。
discovery.zen.minimum_master_nodes（默认是1）：这个参数控制的是，一个节点需要看到的具有master节点资格的最小数量，然后才能在集群中做操作。官方的推荐值是(N/2)+1，其中N是具有master资格的节点的数量（我们的情况是3，因此这个参数设置为2，但对于只有2个节点的情况，设置为2就有些问题了，一个节点DOWN掉后，你肯定连不上2台服务器了，这点需要注意）。
加快master发现的速度,可以将data节点的默认的master发现方式有multicast修改为unicast,并指定具体的master地址 discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"]
有次出现某些分片长期处于UNASSIGNED状态，我们就可以手动分配分片到指定节点上
默认情况下只允许手动分配副本分片，所以如果是主分片故障，需要单独加一个allow_primary选项, 注意，如果是历史数据的话，请提前确认一下哪个节点上保留有这个分片的实际目录，且目录大小最大。然后手动分配到这个节点上。以此减少数据丢失。(我们在测试环境发现有有一天早上六点有几个分片是UNASSIGNED状态, 采用下面的命令可以使集群重回green状态)：
curl -XPOST 127.0.0.1:9200/_cluster/reroute -d '{
"commands": [
"allocate": {
"index": "eagleye_bigindex_",
"shard": 1,
"node": "eagleye_es_236",
"allow_primary": true
因为负载过高，磁盘利用率过高，服务器下线，更换磁盘等原因，可以会需要从节点上移走部分分片 curl -XPOST 127.0.0.1:9200/_cluster/reroute -d '{
"commands": [
"index": "eagleye_bigindex_",
"shard": 1,
"from_node": "eagleye_es_235",
"to_node": "eagleye_es_237"
（转载本站文章请注明作者和出处 ）
相关热门文章78在 SegmentFault，解决技术问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
一线的工程师、著名开源项目的作者们，都在这里：
获取验证码
已有账号？
标签：至少1个，最多5个
没有用到elasticsearch的全文搜索特性，反而它的分词给我带来很多困扰。比如一个字段是
我想用正则表达式去匹配，却只能使用单个词的匹配比如W.*g或者D.*i
而不能使用整个句子的匹配W.*i
这个问题可以参考
以下是我自己的记录
mapping中增加not_analyzed参数
PUT /&index_name&/_mapping
&type_name&: {
properties: {
&column_name&: {type: string, index: not_analyzed}
改变analyzer的type为keyword
PUT /&index_name&
analysis: {
analyzer: {
default: {
type: keyword
或在elasticsearch.yml中加上
type: keword
但这种方法略坑，因为它还是能按词搜，不过按句子搜也是可以了
dynamic_mapping
这种没用过，跟加not_analyzed是一样的，不过是把加这个参数设置成默认行为
0 收藏&&|&&0
你可能感兴趣的文章
19 收藏，7.3k
24 收藏，6k
1 收藏，1.5k
分享到微博？
我要该，理由是：2094人阅读
Elasticsearch（1）
索引有不同的内置缓存模块。 它们包括 过滤器（filter）, 字段（field）&和其它。
过滤器缓存
过滤器缓存负责缓存过滤后的结果(在查询中使用)。 默认实现过滤器缓存(和一个推荐使用在几乎所有的情况下) 的是&节点过滤器缓存 类型。
节点过滤器缓存
这个 节点过滤器缓存 可以被配置为使用总内存的一定比例分配给进程或一个指定数量的内存。 所有的索引分片只能出现在一个节点共享一个单一的节点缓存(这就是为什么它叫 节点 ”)。 这个缓存工具实现了一个叫做 LRU 数据删除策略:当缓存区满了以后,最近最少使用的数据被删除，以腾出空间给新的数据存放。
这个设置允许控制过滤器缓存占多少内存大小， indices.cache.filter.size&,该属性的默认值 20% 。 注意 ,这是不一个索引级别的设置，而是节点级别设置(可以在节点上进行配置)。indices.cache.filter.size&&可以接受一个百分比值,如：30% ,或一个精确值,如：512
索引过滤器缓存
该过滤器缓存是在索引等级上面的(每一个节点上)。 一般来说,不建议使用该缓存，因为缓存内存使用量取决于每个节点上面的分片，这个很难难预测。 这个类型分为: 常驻, &软件 和 弱 （resident,&soft&and&weak.）。
所有类型支持以下设置:
Description
index.cache.filter.max_size
这个是设置缓存（每次查询在一个分片里的缓存）的最大值（计数，而不是字节大小）。默认是不设置（-1），一般用于 soft 缓存或者是适合缓存的过滤器。
index.cache.filter.expire
设置缓存的数据处于非活动状态多长时间后过期。
默认值为（-1）。例如，可以设置为 5m，表示缓存的数据5分钟后过期。
字段数据缓存
字段数据缓存的主要用在当以某一个字段排序或faceting上。 它将所有字段的数值加载到内存中为了提供快速的访问这些值。&字段数据缓存可能很昂贵为一个字段，所以建议要有足够的内存来分配它，并使它加载。
默认该缓存的类型使用 resident（常驻）&(因为重建的代码太大)。 其他类型可以使用 soft。
Description
index.cache.field.max_size
这个是设置缓存（每次查询在一个分片里的缓存）的最大值（计数，而不是字节大小）。默认是不设置（-1）
index.cache.field.expire
设置缓存的数据处于非活动状态多长时间到期。
默认值为（-1）。例如，可以设置为 5m，表示缓存的数据5分钟后过期。
——————————————————————————————————————————–
英文原文：
There are different caching inner modules associated with an index. They include&filter,field&and others.
Filter Cache
The filter cache is responsible for caching the results of filters (used in the query). The default implementation of a filter cache (and the one recommended
to use in almost all cases) is the&node&filter cache type.
Node Filter Cache
The&node&filter cache may be configured to use either a percentage of the total memory allocated to the process or an specific amount of memory. All shards
present on a node share a single node cache (thats why its called&node`). The cache implements an&LRUeviction policy: when a cache becomes full, the least recently used data is evicted to make way for new data.
The setting that allows one to control the memory size for the filter cache isindices.cache.filter.size, which defaults to&20%.&Note, this is&not&an index
level setting but a node level setting (can be configured in the node configuration).
indices.cache.filter.size&can accept either a percentage value, like&30%, or an exact value, like&512mb.
Index Filter Cache
A filter cache that exists on the index level (on each node). Generally, not recommended for use since its memory usage depends on which shards are allocated
on each node and its hard to predict it. The types are:&resident,&soft&and&weak.
All types support the following settings:
Description
index.cache.filter.max_size
The max size (count, not byte size) of the cache (per search segment in a shard). Defaults to not set (-1), which is usually fine with&soft&cache and
proper cacheable filters.
index.cache.filter.expire
A time based setting that expires filters after a certain time of inactivity. Defaults to&-1. For example, can be set to&5m&for a 5 minute expiry.
Field Data Cache
The field data cache is used mainly when sorting on or faceting on a field. It loads all the field values to memory in order to provide fast document based
access to those values. The field data cache can be expensive to build for a field, so its recommended to have enough memory to allocate it, and keep it loaded.
The default type for the field data cache is&resident&(because of the cost of rebuilding it). Other types include&soft.
Description
index.cache.field.max_size
The max size (count, not byte size) of the cache (per search segment in a shard). Defaults to not set (-1).
index.cache.field.expire
A time based setting that expires filters after a certain time of inactivity. Defaults to&-1. For example, can be set to&5m&for a 5 minute expiry.
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：44280次
积分：1255
积分：1255
排名：千里之外
原创：71篇
转载：32篇
(5)(2)(1)(5)(3)(3)(7)(10)(8)(3)(10)(5)(2)(8)(2)(9)(7)(8)(1)(3)(3)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'