首页 文章 精选 留言 我的

精选列表

搜索[协同工作],共10000篇文章
优秀的个人博客,低调大师

Elasticsearch之es学习工作中遇到的坑

1:es集群脑裂问题(不要用外网ip,节点角色不要混用) 原因1:阿里云服务器,外网有时候不稳定。 解决方案:单独采购服务器,内网安装 原因2:master和node节点没有分开 解决方案: 分角色:master节点(三台),data节点(随着数据增加而增加),client(随着查询压力而增加)节点 Master节点:node.master: true node.data: false Data节点:node.master: false node.data: true Client 节点:node.master: false node.data: false 2:es集群名称的坑(1.4.x版本) 之前在使用1.4版本的时候,这个版本默认是多播协议,可以自动把同一网段的es节点组成一个集群。 所以,在刚开始使用的时候,多种业务部署了多个es集群,结果发现这几个集群莫名其妙搞到一块了。 建议:尽量不要使用集群的默认名称。 不过在2.x的版本中已经默认开启单播协议,不会自动增加同一网段的节点到一个集群。但是也建议修改一下集群名称,改完之后,如果使用java api进行操作,则必须设置cluster.name属性。 3:数据平衡,数据恢复(recover) 假设一个有10个节点的集群。 当重启集群的时候,在启动第二个节点的时候,集群之内的两个节点就开始恢复数据,相互生成副本,当启动第三个节点的时候,这三个节点又重新对数据进行恢复........... 这样非常浪费性能,导致在启动集群的过程当中,做了很多无用功,所以可以设置,当启动集群中5~6个节点的时候再允许进行数据恢复。 建议设置为集群节点数量的一半以上。 gateway.recover_after_nodes: 5 还有一点:es集群要使用内网ip,否则会出现数据恢复缓慢的现象。 4:定时优化索引片段很重要 开始的时候,没有对索引片段进行优化,查询延迟在3S以上,索引优化之后,延迟时间立刻降到1S以内。 5:内存溢出 修改elasticsearch.in.sh脚本 Master节点内存占用不多,CPU稍微高一点。 Data节点内存占用比较多,io操作比较频繁 Client:CPU和内存占用比较平均 6:集群插入数据报错 集群状态为yellow,索引副本数设置为2,但是只有一个节点存活,也就是没有产生副本。插入数据时报错。 7:设置jvm锁住内存时启动警告 当设置bootstrap.mlockall: true时,启动es报警告Unknown mlockall error 0,因为linux系统默认能让进程锁住的内存为64k。 解决方法:设置为无限制,linux命令:ulimit -l unlimited(立刻生效) 或者修改/etc/security/limits.conf(下一次重启开始,永久有效)文件 8:elk中,redis中数据堆积严重 调整logstash内存,使用批量方式向es中索引数据。 9:横向扩展es集群,不要纵向扩展 单纯增加es节点的内存和CPU不会有很大提升,建议多增加节点。 10:目前es集群部署情况 Master:3台(4 core ,16G内存,500G) 192.168.1.20 192.168.1.21 192.168.1.22 Data:8台(4 core 32G内存,2x1T) 192.168.1.31 192.168.1.32 192.168.1.33 192.168.1.34 192.168.1.35 192.168.1.36 192.168.1.37 192.168.1.38 Client:3台(4 core,32G,500G) 192.168.1.10 192.168.1.11 192.168.1.12 11、后续更新 本文转自大数据躺过的坑博客园博客,原文链接:http://www.cnblogs.com/zlslch/p/6619108.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

Grid Control OMS Agent代理工作原理图

我们在使用Grid Control集中化管理OS、Oracle数据库时要求在host上安装Agent代理程序,以便Agent定期收集OS、Oracle信息传输给Oracle Grid Control Management Server(OMS),并执行OMS下达的一系列指令。 大多数人对于Agent的了解仅限于如何安装和启动agent,下图展示了OMS Agent的架构: Agent主要由2个组件(component)部分组成,分别是Collector 收集器和 Metric Engine 度量引擎。 Collector收集器是agent的重要子系统。它负责收集并上传metric data度量数据到OMS(oms最终将这些数据存入数据库中)。Collector 利用collection file中的信息判定针对哪些target目标需要收集metric data以及多久收集一次。 为了获取数据,Collector将查询投递给Metric Engine,而Metric Engine负责实际的metric data的收集。 Metric Engine 本文转自maclean_007 51CTO博客,原文链接:http://blog.51cto.com/maclean/1278223

优秀的个人博客,低调大师

Bossy智能便贴:让工作更有效率

物联网正以星际迷航里博格人那样极高的效率,迅速进军计步器、烟雾警报器,以及酒吧器具等市场。目前,来自巴西一个设计专业的学生 Lucas Neumann de Antonio 选择了一个看似不起眼的市场——便利贴。他设想了一个叫做Bossy的效率工具,为传统的纸质便条加入互联网体验。 Bossy看起来就像是Nest的恒温器被从墙上扯下来放到了桌子上,它可以从一些任务管理软件(如Omnifocus、Wunderlist、Asana或者日历、邮件以及其他一些专注特定任务的定制软件)中获取任务清单,然后将其展示在屏幕上,外表的触摸屏最多可以显示出三个任务列表。Bossy就是要把庞大的任务列表分解成可管理的小块,从而让用户专注于去完成该做的事。 “最初的设想是把任务都积攒起来,就像是往盒子里放弹珠,但是现在只显示三个任务看起来更能够使用

优秀的个人博客,低调大师

从事大数据相关的工作 如何自学打基础?

海量数据分成两块,一是系统建设技术,二,海量数据应用。 先说系统建设,现在主流的技术是HADOOP,主要基于mapreduce的分布式框架。目前可以先学习这个。但是我的观点,在分布式系统出来之前,主要是集中式架构,如DB2,oracle。为什么现在用分布式架构,那是因为现在集中式架构受限于IO性能,出来速度慢,如果又一种硬件技术,可以很快地处理海量数据,性能上能满足需求,那么集中式架构优于分布式架构,因为集中式架构稳定,运维压力小。现在的集中式架构要么性能达不到要求,要么就是过于昂贵。我期待一种技术出现,可以非常快地传输和处理数据,那么集中式架构将再次进入人们眼球。再说海量数据应用。海量数据应用主要是数据挖掘和机器算法。具体有不同的应用场景,如个性化搜索和推荐,社交网络发现,精准营销,精准广告,实时最优路径,人工智能等等。看你想做系统支撑技术还是与业务结合的应用技术。 如果现在学系统建设技术,可以读下如下书籍: 如果学数据挖掘和机器算法,推荐先看数据挖掘导论,统计分析原理,Mahout,R,MATLAB 本文作者:佚名 来源:51CTO

优秀的个人博客,低调大师

NB-IOT物联网平台是如何工作的

近期NB-IOT成为业界火热的话题,物联网无比渴望着一个强有力的蜂窝物联网基础网络,而 NB-IoT无疑是这个基础网络最佳的选择。工信部发文要求加快NB-IoT在国内落地,到今年年底建成基站规模40万个,到2020年建成基站规模150万个。 NB-IoT作为一种广域网连接技术,能把终端直接接入已广泛覆盖的蜂窝网络中,且支持良好的移动性,可满足远程抄表、移动设备追踪、智慧农业、智能停车等行业应用。到底什么NB-IOT基站,网络如何组成,数据如何传输呢? NB-IOT网络包括NB-IOT终端,NB-IOT基站,NB-IOT分组核心网,IOT连接管理平台,和行业应用服务器。需要升级现网基站支持NB-IOT业务,部署NB-IOT业务专用的EPC(CloudEdge),需要新部署IOT连接管理平台。IOT连接管理平台的功能:提供对各种传感器、SIM卡的数据采集、管理功能,同时可以把数据开放给第三方应用系统,让各种应用能快速构建自己的物联网业务。 NB-IOT基站是移动通信中组成蜂窝小区的基本单元,主要完成移动通信网和UE之间的通信和管理功能。即通过运营商网络连接的NB-IOT 用户终端设备必须在基站信号的覆盖范围内才能进行通信。基站不是孤立存在的,属于网络架构中的一部分,是连接移动通信网和UE的桥梁。基站一般由机房、信号处理设备、室外的射频模块、收发信号的天线、GPS、各种传输线缆等组成。 NB-IOT基站 通过COAP协议或者UDP协议来链接的 COAP协议:MCU(NB设备)—NB模块(UE)--eNode—核心网—IOT平台—APP 服务器—手机终端app UDP协议:MCU(NB设备)—NB模块(UE)--eNode—核心网—UDP 服务器—手机终端 数据上报是物联网业务中最基础的一项,这里先把几个术语解释下。 南向设备:开发者自行开发的终端硬件设备(包含多个传感器和MCU)。 北向应用:开发者自行开发的服务端应用(基于华为OceanConnect物联网平台提供的RESTful接口)。 NB-IoT:这不用解释了吧,窄带物联网,华为等公司主推的物联网通讯用蜂巢网络。 NB-IoT芯片/模组:类似于3G/4G通信模组,将设备端数据打包发送到指定平台的硬件模块。 SoftRadio:用于模拟NB-IOT模组、基站、核心网的PC端软件,可用于在缺乏NB模组和NB实网环境时的设备对接调试。 OceanConnect:物联网全联接平台,南向设备和北向应用通过该平台交换数据和信令。 设备Profile文件:描述设备“是什么”、“能干什么”的json格式文件,上传到OceanConnect平台(上传时是zip包格式),设备绑定平台和提供服务的关键配置文件。 编解码插件:用来对NB设备上报的数据进行解码,同时对下发给NB设备的信令进行编码的插件,对接前需上传到OceanConnect平台。 终端设备将需要上报的数据通过NB-IoT网络发送到华为物联网平台,而后北向应用通过RESTful接口获取这些数据(或平台主动推送已订阅的数据)。 数据上报流程 流程: 1,南向设备采集数据、并将数据按自定义规则进行编码,例如:将温湿度实时数据编码成000102; 2,设备通过串口,以AT命令的形式,发送已编码数据到NB-IoT模组或SoftRadio模拟器。 3, NB-IoT芯片/模组或SoftRadio模拟器,接收到AT命令后,将payload后,自动封装为CoAP协议的消息,并发送给事先配置的物联网平台; 4, 物联网平台收到数据后,自动解析CoAP协议包,根据设备profile文件,找到匹配的编解码插件,对payload进行解析,解析为与设备profile中描述的service匹配的json数据,并存于平台之上; 5, 应用服务器通过北向数据查询接口(RESTful)获取平台上的数据;同时也可以提前调用订阅接口,对数据变化进行订阅,则之后所有的数据变化,平台都会通过POST消息。 2017年将是中国NB-IoT产业发展非常关键的一年,NB-IoT要取得成功,必须有生态系统中各个产业平台的支持。基于NB-IoT标准优势和市场应用趋势,可以看到NB-IoT的商用条件已经成熟,整个产业链也将一触即发,从运营商、设备商、芯片厂商以及终端厂商都在为商用备战。 本文由航大物联网编辑整理(www.lrist.com),如有侵权请联系本站。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册