Buckets

apache ab压力测试报错（apr_socket_recv: Connection reset by peer (104)） [root@aa~]# This is ApacheBench, Version 2.3 <> Copyright 1996 Adam Twi, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 192.168.1.176 (be patient) Completed 300 requests Completed 600 requests Completed 900 requests apr_socket_recv: Connection reset by peer (104) Total of 1085 requests completed 查看应用服务器和数据库均未报错，连接被重置，bingyi了以下，apr_socket_recv这个是操作系统内核的一个参数，在高并发的情况下，内核会认为系统受到了SYN flood***，会发送cookies（possible SYN flooding on port 80. Sending cookies）

1 Linux 内核调优 1．首先在 root 用户下执行： vi /etc/sysctl.conf 在文件末尾添加如下内容： vm.swappiness = 10 #当系统存在足够内存时，推荐设置为该值以提高性能。 net.ipv4.tcp_syncookies = 1 #开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies来处理 net.ipv4.tcp_tw_reuse = 1 #开启TCP连接复用功能，允许将time_wait sockets重新用于新的TCP连接（主要针对time_wait连接） net.ipv4.tcp_tw_recycle = 1·#开启TCP连接中time_wait sockets的快速回收 net.ipv4.tcp_fin_timeout = 30 #如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60 秒。2.2 内核的通常值是180秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FIN- WAIT-2的危险性比FIN-WAIT-1要小，因为它最多只能吃掉1.5K内存，但是它们的生存期长些 net.ipv4.tcp_keepalive_time = 1200

先看下如何创建数据表 create [external] table if not exists 表名 (列名数据类型 [comment 本列注释],...) [comment 表注释] [partitioned by (列名数据类型 [comment 本列注释],...)] [clustered by(列名,列名,...)] [sorted by (列名 [asc|desc],...)] info num_buckets buckets] [row format row_format][stored as file_format] [location hdfs_path] [tblproperties (property_name=property_value,...)] [as select_statement] 说明： ①external表示创建外部表；hive在创建内部表时，会将数据移动到数据仓库指向的路径；若创建外部表，仅记录数据所在的路径，不对数据的位置做任何改变 ②partitioned by表示创建分区表 ③clustered by创建分桶表 ④sorted by 不常用 ⑤row format delimited [fields terminated by char] [collection items terminated by char] [map keys

HashMap的底层数据结构？ 数组+链表（JDK1.8之前） ， 数组+链表+红黑树（JDK1.8之后） HashMap的存取原理？ 通过获取key对象的hashcode计算出该对象的哈希值，通过改哈希值与数组长度减去1进行位与运算（n-1 & hash）,得到buckets 的位置，当发生hash冲突时，如果value值一样，则会替换旧的key的value，value不一样则新建链表结点，当链表的长度超过8，则转换为红黑树存储。 Java7和Java8的区别？ 在jdk1.8之前创建该对象，会创建一个长度为16的Entry[] table用来存储键值对数据。jdk1.8之后不是在构造方法创建了，而是在第一次调用put方法时才进行创建，创建Node[] table，然后java7中链表的加入时 Java7在多线程操作HashMap时可能引起死循环，原因是扩容转移后前后链表顺序倒置，在转移过程中修改了原来链表中节点的引用关系。 为啥会线程不安全？ Java7在多线程操作HashMap时可能引起死循环，原因是扩容转移后前后链表顺序倒置，在转移过程中修改了原来链表中节点的引用关系。 Java8在同样的前提下并不会引起死循环，原因是扩容转移后前后链表顺序不变，保持之前节点的引用关系。 但是即使不会出现死循环，但是通过源码看到put/get方法都没有加同步锁，多线程情况最容易出现的就是

聚合一般作用在query范围内。不带query的aggregation请求实际上是在match_all{}查询范围内进行统计的： GET /cartxns/ _search { " aggs " : { " all_colors " : { " terms " : { " field " : " color.keyword " } } } } } GET /cartxns/ _search { " query " : { " match_all " : {} }, " aggs " : { " all_colors " : { " terms " : { " field " : " color.keyword " } } } } } 上面这两个请求结果相同： " aggregations " : { " all_colors " : { " doc_count_error_upper_bound " : 0 , " sum_other_doc_count " : 0 , " buckets " : [ { " key " : " red " , " doc_count " : 4 }, { " key " : " blue " , " doc_count " : 2 }, { " key " : " green " , " doc_count " : 2 } ] } }

在项目中使用jest操作es6.x（搜索）的心得 ： [这篇文章是初学elasticSearch的心得笔记以及遇到的一些问题] 查询方式： 先创建一个SearchSourceBuilder这个是总的查询对象器 // 主查询条件 SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder(); 在创建一个关于业务逻辑的查询构建器，例如：BoolQueryBuilder 布尔类型的构建器 BoolQueryBuilder queryBuilder = QueryBuilders.boolQuery(); 接下来就是对于业务逻辑中各个查询条件的拼接：其实也是BoolQueryBulider之类的构建器作为各个过滤条件 // 单个过滤条件 BoolQueryBuilder stringBuilder = QueryBuilders.boolQuery(); authBuilder.should(QueryBuilders.termQuery("xxx", "xxx")); authBuilder.should(QueryBuilders.termQuery("xxx", "xxx")); queryBuilder.must(authBuilder); //范围过滤条件 BoolQueryBuilder

问题: 没有占用多少流量，但是网络连接很慢，ping超时。已发现被大量不同的机器访问导致tcp连接数非常高，nf_conntrack满了 vim /var/log/message报错 nf_conntrack: table full, dropping packet 先关掉iptables /etc/init.d/iptables stop 查看当前的连接数： # grep nf_conntrack /proc/slabinfo 查出目前 nf_conntrack 的排名： $ cat /proc/net/nf_conntrack | cut -d ' ' -f 10 | cut -d '=' -f 2 | sort | uniq -c | sort -nr | head -n 10 优化参数 状态跟踪表的最大行数的设定，理论最大值 CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32) 以64G的64位操作系统为例，CONNTRACK_MAX = 64*1024*1024*1024/16384/2 = 2097152 即时生效请执行： sysctl –w net.netfilter.nf_conntrack_max = 524288 （16G） 其哈希表大小通常为总表的1/8，最大为1/2。CONNTRACK

0、算法概述 0.1 算法分类 十种常见排序算法可以分为两大类： 比较类排序 ：通过比较来决定元素间的相对次序，由于其时间复杂度不能突破O(nlogn)，因此也称为非线性时间比较类排序。 非比较类排序 ：不通过比较来决定元素间的相对次序，它可以突破基于比较排序的时间下界，以线性时间运行，因此也称为线性时间非比较类排序。 0.2 算法复杂度 0.3 相关概念 稳定 ：如果a原本在b前面，而a=b，排序之后a仍然在b的前面。 不稳定 ：如果a原本在b的前面，而a=b，排序之后 a 可能会出现在 b 的后面。 时间复杂度 ：对排序数据的总的操作次数。反映当n变化时，操作次数呈现什么规律。 空间复杂度： 是指算法在计算机 内执行时所需存储空间的度量，它也是数据规模n的函数。 1、冒泡排序（Bubble Sort） 冒泡排序是一种简单的排序算法。它重复地走访过要排序的数列，一次比较两个元素，如果它们的顺序错误就把它们交换过来。走访数列的工作是重复地进行直到没有再需要交换，也就是说该数列已经排序完成。这个算法的名字由来是因为越小的元素会经由交换慢慢“浮”到数列的顶端。 1.1 算法描述 比较相邻的元素。如果第一个比第二个大，就交换它们两个； 对每一对相邻元素作同样的工作，从开始第一对到结尾的最后一对，这样在最后的元素应该会是最大的数； 针对所有的元素重复以上的步骤，除了最后一个； 重复步骤1

聚合一般作用在query范围内。不带query的aggregation请求实际上是在match_all{}查询范围内进行统计的： GET /cartxns/ _search { " aggs " : { " all_colors " : { " terms " : { " field " : " color.keyword " } } } } } GET /cartxns/ _search { " query " : { " match_all " : {} }, " aggs " : { " all_colors " : { " terms " : { " field " : " color.keyword " } } } } } 上面这两个请求结果相同： " aggregations " : { " all_colors " : { " doc_count_error_upper_bound " : 0 , " sum_other_doc_count " : 0 , " buckets " : [ { " key " : " red " , " doc_count " : 4 }, { " key " : " blue " , " doc_count " : 2 }, { " key " : " green " , " doc_count " : 2 } ] } }

mysqldump一次备份多个库 一个数据库实例中有20+个库，本次备份需要备份其中的10+个库，使用mysqldump直接进行备份踩到一个warning和一个error。 数据库版本：5.7.26 过程如下： action1 mysqldump -hrm-2ze04c849v9m32bzj.mysql.rds.aliyuncs.com -uadminroot -p'BDm4w%qqGf3Zx!J5' --single-transaction --quick --databases db1 db2 db3 db4 ... > /tmp/test.sql Warning： Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.