• 关于 解决linux服务器访问较慢的问题 的搜索结果

问题

500/502/504错误排查

行者武松 2019-12-01 21:43:48 4664 浏览量 回答数 0

回答

可能原因以及解决方案 源站域名没有备案或者域名没有在高防或者安全网络中配置七层转发规则。 解决方案:请将域名备案。如果负载均衡在高防或者安全网络中,请配置对应的域名规则。 客户端源IP地址被云盾拦截。 测试其他ISP运营商的客户端是否有相同问题,如果仅仅是某个固定运营商网络的客户端访问有问题,一般是运营商封堵导致。 解决方案:通过提交工单反馈给阿里云售后技术支持,抓包确认是否有封堵行为。如果有,请联系运营商解决该问题。 后端ECS安全防护软件阻挡。 100.64.0.0/10(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)是负载均衡服务器IP段,主要用于健康检查和转发请求。例如安装安全软件或者开启系统内部防火墙,可以将此IP加入白名单,避免出现500或502错误。 解决方案:配置杀毒、防火墙软件白名单,或者卸载此类软件快速测试。 后端ECS Linux内核参数配置错误。 对于后端ECS为Linux系统,改成TCP模式时需要注意关闭系统内核参数中rp_filter相关设置。 解决方案:将系统配置文件/etc/sysctl.conf的以下三个配置的值设为0,然后执行sysctl -p。 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 后端ECS性能瓶颈。 例如CPU高,外网带宽跑满均可能导致访问异常。 解决方案:检查后端ECS性能,解决性能瓶颈问题,如果是整体系统容量不够,可以通过扩容后端ECS 的数量消除问题。 健康检查失败导致负载均衡出现502错误 。 健康检查失败,请参见健康检查异常排查进行排查。 此外,未开启负载均衡的健康检查,同时服务器中Web服务无法正常处理HTTP请求,例如Web服务未运行,也会出现502错误。 健康检查正常但Web应用报502错误 。 502 Bad Gateway错误提示表明负载均衡可以将来自客户端的请求转发到后端服务器中,但是服务器中Web应用处理异常抛出该提示,所以排错的方向是针对服务器中Web应用的配置以及运行情况进行分析。例如Web应用处理HTTP请求的时间超过了负载均衡的timeout时间。 在七层HTTP模式下,后端对PHP请求的处理时间超过proxy_read_timeout设置的60秒,此时会出现负载均衡抛出的504 Gateway Time-out。对于四层监听,超时时间为900秒。 解决方案:确保Web服务以及依赖正常运行,检查PHP请求处理情况,优化后端PHP请求处理。下面以Nginx+php-fpm为例进行分析说明: 处理PHP请求的进程数达到上限。 当前服务器中PHP请求总数已经达到了php-fpm中max_children设置的上限,如果后续有新的PHP请求到达服务器中,这种情况下通常502与504的错误码会随机出现: 如果已有的请求被处理完成,新请求被继续处理,一切正常。 如果已有的PHP请求处理较慢,新的PHP一直处于等待状态,直至超过Nginx的fastcgi_read_timeout的值,就会出现504 Gateway timeout的错误。 如果已有的PHP请求处理较慢,新的PHP处于等待状态,超过了Nginx的request_terminate_timeout的值,就会出现502 Bad Gateway的错误。 PHP脚本执行时间处理超时,即如果php-fpm处理PHP脚本的时长超过了Nginx中request_terminate_timeout设置的值,就会出现502 Bad Gateway的错误,同时在Nginx日志中可以查看到如下错误记录: [error] 1760#0: *251777 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: “GET /timeoutmore.php HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000” 健康检查针对的是静态页面,实际处理动态请求的进程异常,例如php-fpm未启动运行。 HTTP头部过大。 Head头信息过大可能导致负载均衡无法正确处理相关数据,进而引发502错误。 解决方案:减少通过Head头传递的数据量或者换成TCP监听。 业务访问逻辑问题。 确保不存在负载均衡后端ECS实例在服务器内部通过负载均衡公网IP地址访问SLB的情况。该情况下,后端业务服务器通过负载均衡地址访问自身所监控的端口后,根据负载均衡调度策略的不同,可能会将相应的请求调度到自身服务器上。导致出现自己访问自己的情况,造成死循环,进而导致相应的请求出现500或502错误。 解决方案:确保负载均衡场景应用正确,避免后端ECS服务器需要访问负载均衡公网IP地址的情况。 排查步骤 检查500/502/504错误截图,判断是负载均衡问题,高防/安全网络配置问题,还是后端ECS配置问题。 如果有高防/安全网络,请确认高防/安全网络的七层转发配置正确。 请确认是所有客户端都有问题,还仅仅是部分客户端有问题。如果仅仅是部分客户端问题,排查该客户端是否被云盾阻挡,或者负载均衡域名或者IP是否被ISP运营商拦截。 检查负载均衡状态,是否有后端ECS健康检查失败的情况,如果有健康检查失败,解决健康检查失败问题。 在客户端用hosts文件将负载均衡的服务地址绑定到后端服务器的IP地址上,确认是否是后端问题。如果5XX错误间断发生,很可能是后端某一台ECS服务器的配置问题。 尝试将七层负载均衡切换为四层负载均衡,查看问题是否会复现。 检查后端ECS服务器是否存在CPU、内存、磁盘或网络等性能瓶颈。 如果确认是后端服务器问题,请检查后端ECS Web服务器日志是否有相关错误,Web服务是否正常运行,确认Web访问逻辑是否有问题,卸载服务器上杀毒软件重启测试。 检查后端ECS Linux操作系统的TCP内核参数是否配置正确。 提交工单 请根据上述排查步骤中的指导逐条排查,详细记录排查测试结果。提交工单时,请您提供上述信息以便售后支持尽快协助您解决问题。 如果问题还未解决,请联系售后技术支持。

保持可爱mmm 2020-03-29 12:06:42 0 浏览量 回答数 0

问题

linux cpu wa值过高怎么办

walkerleaf 2019-12-01 22:08:16 4480 浏览量 回答数 1

中小企业与商标那些事

企业品牌保护从商标开始,如何挑选一家靠谱的渠道注册商标,解读品牌权益维护的重要节点。

回答

概述 本文主要介绍无法远程登录Linux实例的案例和排查方法。 详细信息 本文主要通过如下2个方面解决无法远程登录Linux实例的问题。 常见报错案例 排查方法 常见报错案例 SSH无法远程登录Linux实例的常见案例如下所示,可根据实际报错信息选择不同的方案进行排查和处理。 PAM安全框架 Linux系统环境配置 SSH服务及参数配置 SSH服务关联目录或文件配置 SSH服务密钥配置 PAM安全框架 Linux系统的PAM安全框架可以加载相关安全模块,对云服务器的账户策略、登录策略等进行访问控制。如果相关配置存在异常,或触发了相关策略,就可能会导致SSH登录失败。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:pam_listfile(sshd:auth): Refused user root for service sshd SSH登录时出现如下错误:requirement “uid >= 1000” not met by user “root” SSH登录时出现如下错误:Maximum amount of failed attempts was reached SSH登录时出现如下错误:login: Module is unknown Linux系统环境配置 Linux内的系统环境,比如中毒、账户配置、环境变量配置等,如果出现异常,也可能会导致SSH登录失败。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:ssh_exchange_identification: read: Connection reset by peer 中毒导致SSH服务运行异常,出现如下错误:fatal: mm_request_send: write: Broken pipe SSH启动时出现如下错误:main process exited, code=exited SSH连接时出现如下错误:pam_limits(sshd:session):could not sent limit for ‘nofile’ SSH连接时出现如下错误:pam_unix(sshdsession) session closed for user SSH连接时出现如下错误:error Could not get shadow infromation for root SSH服务及参数配置 SSH服务的默认配置文件为/etc/ssh/sshd_config。配置文件中的相关参数配置异常,或启用了相关特性或策略,也可能会导致 SSH登录失败。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:Disconnected:No supported authentication methods available SSH登录时出现如下错误:User root not allowed because not listed in SSH登录时出现如下错误:Permission denied, please try again SSH登录时出现如下错误:Too many authentication failures for root SSH启动时出现如下错误:error while loading shared libraries SSH启动时出现如下错误:fatal: Cannot bind any address SSH启动时出现如下错误:Bad configuration options 云服务器ECS Linux SSH启用UseDNS导致连接速度变慢 Linux实例中由于SELinux服务开启导致SSH远程连接异常 SSH服务关联目录或文件配置 SSH服务基于安全性考虑,在运行时,会对相关目录或文件的权限配置、属组等进行检查。过高或过低的权限配置,都可能会引发服务运行异常,进而导致客户端登录失败。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:No supported key exchange algorithms SSH启动时出现如下错误:must be owned by root and not group or word-writable SSH服务密钥配置 SSH服务采用非对称加密技术,对所传输的数据进行加密。客户端及服务端会交换和校验相关密钥信息的有效性。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:Host key verification failed SSH服务的公私钥异常导致无法SSH登录Linux实例 排查方法 若常见报错案例没有解决问题,可以参考如下流程排查问题。 检查CPU负载、带宽及内存使用情况 客户端排查 中间网络 网络检查 端口检查 安全组检查 示例 提示: 以下操作在CentOS 6.5 64位操作系统中进行过测试,在其他Linux发行版中可能存在差异,具体情况请参阅对应Linux发行版的官方文档。 客户端SSH连接Linux实例是运维操作的主要途径。通过管理终端可以用于临时运维操作,或者在客户端SSH登录异常时,用于问题排查和分析。 下图为SSH登录关联因素示意图。由此可见,通过SSH无法远程登录Linux实例时,可能涉及的关联因素较多。 检查CPU负载、带宽及内存使用情况 确认是否存在CPU负载过高的情况,如果存在,则参考本步骤解决问题,如果不存在,则执行下一步步骤。 提示:您无法主动监控系统内部的程序运行状态,但是可以借助云监控进行查看。 登录云监控控制台,依次选择 主机监控 > 进程监控。 查看应用运行情况,排除CPU负载过高的原因,如何查看CPU负载问题,请参见Linux系统ECS实例CPU使用率较高的排查思路。 提示:在某个时间段CPU负载过高可能导致远程连接失败,建议您查询程序或者实例资源是否不满足现有要求。 无法远程连接可能是公网带宽不足导致的,具体排查方法如下。可通过续费ECS实例,然后重启实例解决。详情参见手动续费或者自动续费。 登录ECS管理控制台。 找到该实例, 单击 管理 进入 实例详情 页面,查看网络监控数据。 检查服务器带宽是否为“1k”或“0k”。如果购买实例时没有购买公网带宽,后来升级了公网带宽,续费的时候没有选择续费带宽,带宽就会变成“1k”。 远程连接输入用户密码登录后,不能正常显示桌面直接退出,也没有错误信息。这种情况可能是服务器内存不足导致的,需要查看一下服务器的内存使用情况。具体操作如下。 使用控制台远程连接功能登录到Linux实例。 查看内存使用情况,具体请参考Linux系统的ECS实例中如何查看物理CPU和内存信息,确认内存不足后,请参考Linux服务器内存消耗过高进行处理。 客户端排查 客户端无法正常登录时,先使用不同的SSH客户端基于相同账户信息进行登录测试。如果能正常登录,则判断是客户端配置问题,需要对客户端配置或软件运行情况做排查分析。关于如何使用客户端SSH登录Linux实例,您可以参考远程连接Linux实例。 步骤一:使用管理终端登录实例 无论何种原因导致无法远程连接实例,请先尝试用阿里云提供的远程连接功能进行连接,确认实例还有响应,没有完全宕机,然后再按原因分类进行故障排查。 登录云服务器管理控制台,单击左侧导航栏中的 实例,然后在目标实例右侧单击 远程连接。 在首次连接或忘记连接密码时,单击 修改远程连接密码,修改远程连接的密码。 然后通过远程连接密码连接实例。 步骤二:检查客户端本地网络是否异常 确认是否存在用户本地无法连接外网的故障。 如果存在,则检查网卡驱动,如果存在异常,则重新安装。使用管理终端登录实例,查看/etc/hosts.deny文件,查看是否存在拦截IP,如果存在则删除此IP配置即可。 如果不存在,则执行下一步步骤。 步骤三:重启实例 在确保登录密码正确的情况下,确认之前是否曾重置过密码。检查重置实例密码后是否未重启实例,如果存在实例密码修改记录,但无重启实例记录,则参考以下操作步骤重启实例。 登录ECS管理控制台,单击左侧导航栏中的 实例。 在页面顶部的选择对应的地域,目标实例右侧单击 更多 > 实例状态 > 重启,再单击 确认 即可。 中间网络 中间网络包括网络检查和端口检查。 网络检查 无法正常远程连接Windows实例时,需要先检查网络是否正常。 用其他网络环境中,不同网段或不同运营商)的电脑连接对比测试,判断是本地网络问题还是服务器端的问题。如果是本地网络问题或运营商问题,请联系本地IT人员或运营商解决。如果是网卡驱动存在异常,则重新安装。排除本地网络故障后进行下一步检查。 在客户端使用ping命令测试与实例的网络连通性。 网络异常时,请参考网络异常时如何抓取数据包进行排查。 当出现ping丢包或ping不通时,请参考使用ping命令丢包或不通时的链路测试方法进行排查。 如果出现间歇性丢包,ECS实例的网络一直处于不稳定状态时,请参考使用ping命令测试ECS实例的IP地址间歇性丢包进行解决。 系统内核没有禁ping的情况下,使用ping命令测试ECS服务器,发现网络不通,请参考Linux系统的ECS中没有禁PING却PING不通的解决方法。 端口检查 网络检查正常后,进一步检查端口是否正常。 使用管理终端登录实例,执行如下命令,编辑SSH配置文件。 vi /etc/ssh/sshd_config 找到“#port 22”所在行,检查默认端口22是否被修改,且前面的“#”是否删除,如果没有删除,可以把前面的“#”删除,然后将22改为其它的端口,再保存退出即可。 注:服务监听能使用的端口范围为0到65535,错误配置监听端口会导致远程桌面服务监听失败。 执行如下命令,重启SSH服务。 /etc/init.d/sshd restart 注:也可执行如下命令,重启SSH服务。 service sshd restart 使用Python自带的Web服务器用于临时创建新的监听端口进行测试。 python -m SimpleHTTPServer [$Port] 如果登录方式改变或者ECS安全组规则中未放行修改后的端口号,则参考如下步骤放行修改后的端口。 注:ECS的安全组规则中默认放行22端口。修改了远程桌面的端口后,需要在安全组规则中放行修改后的端口号。 登录ECS管理控制台。 找到该实例,单击 管理 进入 实例详情 页面,切换到 本实例安全组 标签页,单击 配置规则。 在安全组规则页面,单击 添加安全组规则。 在弹出的页面中,端口范围 输入修改后的远程桌面端口号。授权对象 输入客户端的公网IP地址。比如修改后的远程桌面端口号为2222,则 端口范围 应输入“2222/2222”。填写完成后,单击 确定。 通过上一步获取的端口,参考如下命令,进行端口测试,判断端口是否正常。如果端口测试失败,请参考使用ping命令正常但端口不通时的端口可用性探测说明进行排查。 telnet [$IP] [$Port] 注: [$IP]指Linux实例的IP地址。 [$Port]指Linux实例的SSH端口号。 系统显示类似如下,比如执行telnet 192.168.0.1 22命令,正常情况下,系统会返回服务端中SSH的软件版本号。 安全组检查 检查安全组配置,是否允许远程连接的端口。 参考查询安全组规则,查看安全组规则。如果远程连接端口没有进行配置,则参考Linux实例启用SSH服务后设置对应的安全组策略配置。 确认是否存在无法ping通ECS实例,在排除Iptables和网卡IP配置问题且回滚系统后,仍然无法ping通。可能是ECS实例安全组默认的公网规则被删除,则需要重新配置ECS实例的安全组公网规则,具体操作请参见ECS实例安全组默认的公网规则被删除导致无法ping通。如果不存在,则继续下一步骤检查。 示例 如果根据前述问题场景进行排查和处理后,还是无法正常登录。则建议按照如下步骤逐一排查和分析。 使用不同的客户端SSH及管理终端做对比访问测试,判断是否是个别客户端自身配置或软件运行问题所致。 参阅中间网络问题相关说明,测试网络连通性。 参阅管理终端,登录云服务器,在客户端进行访问测试的同时,执行如下命令,查看相关日志。 tailf /var/log/secure 参考如下命令, 比如ssh -v 192.168.0.1 命令,获取Linux环境中详细的SSH登录交互日志。 ssh -v [$IP] 通过管理终端登录Linux实例,参考如下步骤,检查SSH服务运行状态。 执行如下命令,检查服务运行状态。 service sshd status service sshd restart 正常情况下会返回SSH服务的运行状态及进程PID,系统显示类似如下。 [root@centos ~]# service sshd status openssh-daemon (pid 31350) is running... [root@centos ~]# service sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] 执行如下命令,检查服务监听状态。 netstat -ano | grep 0.0.0.0:22 正常情况下会返回相应端口监听信息,系统显示类似如下。 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN off (0.00/0/0) 通过管理终端登录Linux实例,执行如下命令。如果能正常登录,则推断是系统防火墙或外部安全组策略等配置异常,导致客户端登录失败。 ssh 127.0.0.1 若用阿里云提供的远程连接功能仍无法成功连接实例,请尝试重启实例。重启操作会使实例停止工作,从而中断业务,请谨慎执行。 提示:重启实例前,需给实例创建快照,用于数据备份或者制作镜像。创建快照的方法请参见创建快照。 登录ECS管理控制台,单击左侧导航栏中的 实例。 在页面顶部的选择对应的地域,在目标实例右侧单击 更多 > 实例状态 > 重启,再单击 确认 即可。

1934890530796658 2020-03-26 09:52:57 0 浏览量 回答数 0

问题

怎样优化网站服务器性能

以子之矛 2019-12-01 21:27:14 16743 浏览量 回答数 3

问题

如何将ECS云服务器CentOS 2.6内核升级到3.10

阿里云柳璃 2019-12-01 21:56:35 9494 浏览量 回答数 3

回答

如果Linux系统的ECS实例CPU持续保持高使用率,则会对系统稳定性和业务运行造成影响。可以按如下步骤进行处理。 定位问题。找到影响CPU使用率过高的具体进程。 分析处理。查看影响CPU使用率过高的进程是否正常,并分类进行处理。 对于正常进程:您需要对程序进行优化或者升级服务器配置。 对于异常进程:您可以手动对进程进行查杀,也可以使用第三方安全工具去查杀。 CPU负载的查询分析 在Linux系统中,查看进程的常用命令如下所示。本文主要介绍vmstat和top。 vmstat top ps -aux ps -ef 使用vmstat命令查看 通过vmstat命令,从系统维度查看CPU资源的使用情况。命令格式类似如下,表示结果一秒刷新一次。 vmstat -n 1 示例如下。 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 2684984 310452 2364304 0 0 5 17 19 35 4 2 94 0 0 0 0 0 2687504 310452 2362268 0 0 0 252 1942 4326 5 2 93 0 0 0 0 0 2687356 310460 2362252 0 0 0 68 1891 4449 3 2 95 0 0 0 0 0 2687252 310460 2362256 0 0 0 0 1906 4616 4 1 95 0 0 注:返回结果中的主要数据列说明如下。 r:表示系统中CPU等待处理的线程。一个CPU每次只能处理一个线程,所以该数值越大,通常表示系统运行越慢。 us:用户模式消耗的CPU时间百分比。该值较高时,说明用户进程消耗的CPU时间比较多。如果该值长期超过50%,则需要对程序算法或代码等进行优化。 sy:内核模式消耗的CPU时间百分比。 wa:IO等待消耗的CPU时间百分比。该值较高时,说明IO等待比较严重,这可能磁盘大量作随机访问造成的,也可能是磁盘性能出现了瓶颈。 id:处于空闲状态的CPU时间百分比。如果该值持续为0,同时sy是us的两倍,则通常说明系统面临CPU资源短缺。 使用top命令查看 登录Linux实例,关于如何登录Linux实例,请参考使用管理终端连接Linux实例。 执行如下命令,从进程纬度来查看CPU、内存等资源的使用情况。命令格式类似如下。 top 系统显示类似如下。 top - 17:27:13 up 27 days, 3:13, 1 user, load average: 0.02, 0.03, 0.05 Tasks: 94 total, 1 running, 93 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.3 us, 0.1 sy, 0.0 ni, 99.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.1 st KiB Mem: 1016656 total, 946628 used, 70028 free, 169536 buffers KiB Swap: 0 total, 0 used, 0 free. 448644 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 41412 3824 2308 S 0.0 0.4 0:19.01 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.04 kthreadd 针对负载问题,您只需关注回显的第一行和第三行信息,详细说明如下。 top命令的第一行显示的内容17:27:13 up 27 days, 3:13, 1 user, load average: 0.02, 0.03, 0.05,依次为系统当前时间、系统到目前为止已运行的时间、当前登录系统的用户数量、系统负载,这与直接执行uptime命令查询结果一致。 top命令的第三行会显示当前CPU资源的总体使用情况,下方会显示各个进程的资源占用情况。 通过 P 键,可以对CPU使用率进行倒序排列,进而定位系统中占用CPU较高的进程。 提示:通过 M 键,您可以对系统内存使用情况进行排序。如果有多核CPU,数字键1可以显示每核CPU的负载状况。 执行如下命令,可以查看每个进程ID对应的程序文件。 ll /proc/PID/exe 操作案例 案例一:使用top命令终止CPU消耗较大的进程 通过top命令查看系统的负载问题,并定位耗用较多CPU资源的进程,在运行界面快速终止相应的异常进程。 想要终止某个进程,先键入小写字母 k。 输入想要终止的进程PID,默认为输出结果的第一个PID。如下图所示,假如想要终止PID为23的进程,输入23后回车。 操作成功后,界面会出现类似Send pid 23 signal [15/sigterm]的提示信息让用户进行确认。按回车确认即可。 案例二:CPU使用率较低但负载较高 问题描述 当前Linux系统没有业务程序运行。通过top命令观察,发现CPU很空闲,但是load average却非常高,如下图所示。 处理办法 load average是对CPU负载进行评估的,其值越高说明其任务队列越长,处于等待执行的任务越多。出现此种情况时,可能是由于僵死进程导致的。可以通过ps -axjf命令查看是否存在 D+ 状态进程,该状态是指不可中断的睡眠状态。处于该状态的进程无法终止,也无法自行退出。只能通过恢复其依赖的资源或者重启系统来解决。 案例三:kswapd0进程占用CPU较高 操作系统使用分页机制来管理物理内存。操作系统将磁盘的一部分划出来作为虚拟内存,由于内存的速度要比磁盘快得多,所以操作系统要按照某种换页机制将不需要的页面换到磁盘中,将需要的页面调到内存中。由于内存持续不足,这个换页动作持续进行。kswapd0是虚拟内存管理中负责换页的进程,当服务器内存不足的时候kswapd0会执行换页操作,这个换页操作是十分消耗主机CPU资源的。如果通过top命令发现该进程持续处于非睡眠状态,且运行时间较长,可以初步判定系统在持续的进行换页操作,可以将问题转向内存不足的原因来排查。 问题描述 kswapd0进程占用了系统大量CPU资源。 处理办法 执行如下命令,查看kswapd0进程。 top 系统显示类似如下,发现kswapd0进程持续处于非睡眠状态,且运行时间较长并持续占用较高CPU资源,则通常是由于系统在持续的进行换页操作所致。 通过free 、ps等指令进一步查询系统及系统内进程的内存占用情况,做进一步排查分析。 针对系统当前内存不足的问题,您可以重启一些服务,释放内存。 提示:从长远的角度来看,您需要对内存大小进行升级。

1934890530796658 2020-03-26 00:48:16 0 浏览量 回答数 0

问题

云服务器 ECS Linux 系统 CPU 占用率较高问题如何排查

boxti 2019-12-01 22:02:38 1978 浏览量 回答数 0

问题

阿里云云虚拟主机终于可以开启原生 HTTPS 访问了

妙正灰 2019-12-01 21:43:36 15590 浏览量 回答数 31

问题

【阿里云产品评测】个人WP站的云体验

cnsjw 2019-12-01 20:54:27 22207 浏览量 回答数 25

回答

Re为什么每天一到10点左右,主机就超卡? ------------------------- ReRe为什么每天一到10点左右,主机就超卡? 引用第1楼lujiev5于2012-11-01 10:44发表的 Re为什么每天一到10点左右,主机就超卡? : 确实打不开 打开内页网站很慢 嗯,基本要卡一个小时左右速度才会恢复正常。 不知道是不是阿里云的IO有问题。 就连静态页面也卡。。。 ------------------------- Re为什么每天一到10点左右,主机就超卡? 延迟情况 ------------------------- Re为什么每天一到10点左右,主机就超卡? 每天早上都是被监控宝的报警短信吵醒,无奈啊,又解决不了,只能等。。。。 ------------------------- Re回楼主chenghua的帖子 引用第7楼ap2836i0b于2012-11-01 10:55发表的 回 楼主(chenghua) 的帖子 : 用阿里云自己的工具看看CPU使用情况,CPU使用率这么高不正常,可能是中木马了 看你的工具截图?你这不是阿里云自己的工具吧 我是用监控宝的监控。 阿里云监控好像不准,阿里云的监控看着很正常。 但是是一到卡了,监控宝那边就能监控到CPU90%以上。 [attachment=30128] ------------------------- ReRe为什么每天一到10点左右,主机就超卡? 引用第4楼lepig于2012-11-01 10:52发表的 Re为什么每天一到10点左右,主机就超卡? : 10点高峰期么  苦逼 10点不是高峰期呀,下面是百度统计 [attachment=30129] ------------------------- Re为什么每天一到10点左右,主机就超卡? 我提交了工单,好像现在客服在处理中,现在网站速度又恢复正常了。 ------------------------- Re回8楼chenghua的帖子 引用第11楼ap2836i0b于2012-11-01 11:04发表的 回 8楼(chenghua) 的帖子 : 不建议用站外的数据检测,站外的检测会增加服务器负担 我用的服务器系统是CentOS,是用监控宝的SNMP监控,其它服务器也是用SNMP监控,都没问题啊。 ------------------------- Re为什么每天一到10点左右,主机就超卡? 又开始卡了。。。。 ------------------------- ReRe回8楼chenghua的帖子 引用第12楼chenghua于2012-11-01 11:08发表的 Re回8楼chenghua的帖子 : 我用的服务器系统是CentOS,是用监控宝的SNMP监控,其它服务器也是用SNMP监控,都没问题啊。 而且我的这台阿里云主机,用监控宝的SNMP监控已经6个月以上了,都没问题,就是从 10月30日起,开始每天一卡。。 ------------------------- Re回12楼chenghua的帖子 引用第15楼ap2836i0b于2012-11-01 11:17发表的 回 12楼(chenghua) 的帖子 : 你暂时关闭下站外的检测,看是否恢复正常 当然,看你这种情况,估计程序问题或受到小流量CC攻击的可能性较大 你可以看看带宽情况及在线的访问用户情况,linux系统可以查看到的 ....... 嗯,我现在已经关闭了监控宝的监测 每天一到卡的时候,我都有分析访客记录,然后对比日志,看看有没有异常访问的情况。但都没发现问题。 [attachment=30131] ------------------------- Re回12楼chenghua的帖子 引用第15楼ap2836i0b于2012-11-01 11:17发表的 回 12楼(chenghua) 的帖子 : 你暂时关闭下站外的检测,看是否恢复正常 当然,看你这种情况,估计程序问题或受到小流量CC攻击的可能性较大 你可以看看带宽情况及在线的访问用户情况,linux系统可以查看到的 ....... 一到卡的时候CPU的wait就占超高、、网上找了资料别人说:“wait表示cpu在等待磁盘IO,,应该是存储太差。或者存储没有被很好的平衡” ------------------------- Re为什么每天一到10点左右,主机就超卡? 先去吃饭了。。。 ------------------------- Re为什么每天一到10点左右,主机就超卡? 流量天天跌,无奈啊 ------------------------- Re为什么每天一到10点左右,主机就超卡? 又开始卡了,上图是今天的CPU运行情况,基本都在wait,也就是说一卡就是在IO等待。。 ------------------------- Re为什么每天一到10点左右,主机就超卡? 这是磁盘的IO数据,最高也就1M/s啊。 为什么啊?

chenghua 2019-12-01 23:53:55 0 浏览量 回答数 0

问题

性能测试:软件测试的重中之重

云效平台 2019-12-01 21:45:09 5839 浏览量 回答数 1

回答

概念 Apache Tomcat最早是由Sun Microsystems开发的一个Servlet容器,在1999年被捐献给ASF(Apache Software Foundation),隶属于Jakarta项目,现在已经独立为一个顶级项目。Tomcat主要实现了Java EE中的Servlet、JSP规范,同时也提供HTTP服务,是市场上非常流行的Java Web容器。 目录结构 以Tomcat-8.5为例,分析下各个目录都有哪些文件、有哪些作- 1. 用。 bin:主要存放tomcat的操作命令,根据操作系统可以分为两大类:一是以.bat结尾(Windows);二是以.sh结尾(Linux)。比如可以通过startup启动,shutdown关闭Tomcat。 conf:全局配置文件 一个策略文件:catalina.policy 定义了安全策略。 两个属性文件:catalina.properties 和 logging.properties 。 四个XML配置文件: server.xml:Tomcat的主要配置文件,配置整个服务器信息,如修改连接器端口号(默认为8080)。不能动态重加载,文件修改之后必须重启服务器才能生效。 web.xml:全局的web应用程序部署描述文件,如可以设置tomcat支持的文件类型。 context.xml:Tomcat的一些特定配置项,针对所有应用程序生效。 tomcat-users.xml:配置Tomcat的用户名、密码,管理身份验证以及访问控制权限。 lib:Tomcat运行依赖的一些Jar文件,比如常见的servlet-api.jar、jsp-api.jar。所有的应用程序可用,可以放置一些公用的Jar文件,如MySQL JDBC驱动(mysql-connector-java-5.1.{xx}-bin.jar)。 logs:运行中产生的日志文件。包含引擎(engine)日志文件 Catalina.{yyyy-mm-dd}.log,主机日志文件localhost.{yyyy-mm-dd}.log,以及一些其他应用日志文件如manager、host-manager。访问日志也保存在此目录下。 temp:临时文件目录,清空不会影响Tomcat运行 webapps:默认的应用程序根目录,Tomcat启动时会自动加载该目录下的应用程序,可以以文件夹、war包、jar包的形式发布(启动时会自动解压成相应的文件夹)。也可以把应用程序放置在其他路径下,需要在文件中配置路径映射。 work:用来存放tomcat在运行时的编译后文件,如JSP编译后的文件。清空work目录,然后重启tomcat,可以达到清除缓存的作用。 架构 Tomcat是一个HTTP服务器,同时也是一个Servlet容器(可以执行Servlet文件,JSP、JSF会被转换成Servlet),支持多种功能,因此采用了分层、模块化的设计。 查看conf文件夹中的server.xml文件,可以发现上图的层次结构。 <Server> <Service> <Connector/> <Engine> <Host></Host> </Engine> </Service> </Server> Server Server是一个顶级组件,代表了一个Tomcat实例,一个JVM进程中只能有一个Server实例。Tomcat提供了一个实现了 org.apache.catalina.Server接口的 org.apache.catalina.core.StandardServer默认类,读取Server元素配置。 Server是配置文件中的最外层元素,支持以下属性: className:指定要使用的实现类(必须实现org.apache.catalina.Server接口)名称。如果不指定,默认使用标准实现类StandardServer。 address:等待shutdown命令的服务器IP地址,默认是localhost。 port:等待shutdown命令的监听端口,如果设置为-1,表示关闭shutdown端口。 shutdown:指定终止Tomcat服务器运行时,发给Tomcat服务器的shutdown监听端口的字符串.该属性必须设置 。   启动Tomcat,打开命令行工具,通过telnet命令:telnet localhost 8005 连接服务器 输入SHUTDOWN命令,即可关闭Tomcat Cluster Cluster可以解决应用之间session共享、上下文属性共享,以及在集群内共同部署应用程序的问题。元素可以包含在或者元素下。 Context Host元素定义了虚拟主机,Context则是虚拟主机下的具体应用。Tomcat启动后,webapps目录下的所有应用程序都会自动运行,访问某个具体项目需要在URL中指定项目名称,如 http://localhost:8080/examples/ ,ROOT目录除外。想要通过 http://localhost:8080 来访问自定义项目,可以把应用程序直接放到ROOT目录中(让ROOT做为项目的根目录),也可以通过Context来配置映射。 <!-- path:访问项目时的URL,加在localhost:8080后 docBase:path对应的项目目录 reloadable:监视 /WEB-INF/classes/ 和 /WEB-INF/lib目录中的类文件,更改后自动重载应用程序, 生成环境不建议使用,默认为“false” -->  更改server.xml文件后,重新启动Tomcat,在浏览器中输入 http://localhost:8080 即可访问examples应用。 Host 一个Host元素代表了一个虚拟主机,默认主机名为localhost,支持多个Context。 <!-- appBase:定义了应用程序的根目录,默认是webapps unpackWARS:定义了是否解压webapps中的WAR文件,如果指定为“false”,会从WAR文件直接运行程序,执行较慢 autoDeploy:把应用程序直接拖到webapps目录下,是否自动运行 -->

问问小秘 2020-04-30 17:01:07 0 浏览量 回答数 0

问题

ECS故障处理百问合集

yq传送门 2019-12-01 19:35:27 15348 浏览量 回答数 11

问题

超越 MySQL 热:报错

kun坤 2020-06-05 22:43:07 0 浏览量 回答数 1

问题

超越 MySQL 热,数据库报错

python小菜菜 2020-06-01 19:55:39 0 浏览量 回答数 1

回答

134题 其实就是水平扩容了,Zookeeper在这方面不太好。两种方式:全部重启:关闭所有Zookeeper服务,修改配置之后启动。不影响之前客户端的会话。逐个重启:这是比较常用的方式。 133题 集群最低3(2N+1)台,保证奇数,主要是为了选举算法。一个由 3 台机器构成的 ZooKeeper 集群,能够在挂掉 1 台机器后依然正常工作,而对于一个由 5 台服务器构成的 ZooKeeper 集群,能够对 2 台机器挂掉的情况进行容灾。注意,如果是一个由6台服务器构成的 ZooKeeper 集群,同样只能够挂掉 2 台机器,因为如果挂掉 3 台,剩下的机器就无法实现过半了。 132题 基于“过半”设计原则,ZooKeeper 在运行期间,集群中至少有过半的机器保存了最新的数据。因此,只要集群中超过半数的机器还能够正常工作,整个集群就能够对外提供服务。 131题 不是。官方声明:一个Watch事件是一个一次性的触发器,当被设置了Watch的数据发生了改变的时候,则服务器将这个改变发送给设置了Watch的客户端,以便通知它们。为什么不是永久的,举个例子,如果服务端变动频繁,而监听的客户端很多情况下,每次变动都要通知到所有的客户端,这太消耗性能了。一般是客户端执行getData(“/节点A”,true),如果节点A发生了变更或删除,客户端会得到它的watch事件,但是在之后节点A又发生了变更,而客户端又没有设置watch事件,就不再给客户端发送。在实际应用中,很多情况下,我们的客户端不需要知道服务端的每一次变动,我只要最新的数据即可。 130题 数据发布/订阅,负载均衡,命名服务,分布式协调/通知,集群管理,Master 选举,分布式锁,分布式队列 129题 客户端 SendThread 线程接收事件通知, 交由 EventThread 线程回调 Watcher。客户端的 Watcher 机制同样是一次性的, 一旦被触发后, 该 Watcher 就失效了。 128题 1、服务端接收 Watcher 并存储; 2、Watcher 触发; 2.1 封装 WatchedEvent; 2.2 查询 Watcher; 2.3 没找到;说明没有客户端在该数据节点上注册过 Watcher; 2.4 找到;提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher; 3、调用 process 方法来触发 Watcher。 127题 1.调用 getData()/getChildren()/exist()三个 API,传入 Watcher 对象 2.标记请求 request,封装 Watcher 到 WatchRegistration 3.封装成 Packet 对象,发服务端发送 request 4.收到服务端响应后,将 Watcher 注册到 ZKWatcherManager 中进行管理 5.请求返回,完成注册。 126题 Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听,当服务端的一些指定事件触发了这个 Watcher,服务端会向指定客户端发送一个事件通知来实现分布式的通知功能,然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。工作机制:(1)客户端注册 watcher(2)服务端处理 watcher(3)客户端回调 watcher 125题 服务器具有四种状态,分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。 LOOKING:寻 找 Leader 状态。当服务器处于该状态时,它会认为当前集群中没有 Leader,因此需要进入 Leader 选举状态。 FOLLOWING:跟随者状态。表明当前服务器角色是 Follower。 LEADING:领导者状态。表明当前服务器角色是 Leader。 OBSERVING:观察者状态。表明当前服务器角色是 Observer。 124题 Zookeeper 有三种部署模式:单机部署:一台集群上运行;集群部署:多台集群运行;伪集群部署:一台集群启动多个 Zookeeper 实例运行。 123题 Paxos算法是分布式选举算法,Zookeeper使用的 ZAB协议(Zookeeper原子广播),二者有相同的地方,比如都有一个Leader,用来协调N个Follower的运行;Leader要等待超半数的Follower做出正确反馈之后才进行提案;二者都有一个值来代表Leader的周期。不同的地方在于:ZAB用来构建高可用的分布式数据主备系统(Zookeeper),Paxos是用来构建分布式一致性状态机系统。Paxos算法、ZAB协议要想讲清楚可不是一时半会的事儿,自1990年莱斯利·兰伯特提出Paxos算法以来,因为晦涩难懂并没有受到重视。后续几年,兰伯特通过好几篇论文对其进行更进一步地解释,也直到06年谷歌发表了三篇论文,选择Paxos作为chubby cell的一致性算法,Paxos才真正流行起来。对于普通开发者来说,尤其是学习使用Zookeeper的开发者明确一点就好:分布式Zookeeper选举Leader服务器的算法与Paxos有很深的关系。 122题 ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议(paxos算法的一种实现)。ZAB协议包括两种基本的模式:崩溃恢复和消息广播。当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时,所有进程(服务器)进入崩溃恢复模式,首先选举产生新的Leader服务器,然后集群中Follower服务器开始与新的Leader服务器进行数据同步,当集群中超过半数机器与该Leader服务器完成数据同步之后,退出恢复模式进入消息广播模式,Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。 121题 Zookeeper本身也是集群,推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时,其他节点会继续提供服务。如果是一个Follower宕机,还有2台服务器提供访问,因为Zookeeper上的数据是有多个副本的,数据并不会丢失;如果是一个Leader宕机,Zookeeper会选举出新的Leader。ZK集群的机制是只要超过半数的节点正常,集群就能正常提供服务。只有在ZK节点挂得太多,只剩一半或不到一半节点能工作,集群才失效。所以,3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5),2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)。 120题 选完Leader以后,zk就进入状态同步过程。1、Leader等待server连接;2、Follower连接leader,将最大的zxid发送给leader;3、Leader根据follower的zxid确定同步点;4、完成同步后通知follower 已经成为uptodate状态;5、Follower收到uptodate消息后,又可以重新接受client的请求进行服务了。 119题 在zookeeper集群中也是一样,每个节点都会投票,如果某个节点获得超过半数以上的节点的投票,则该节点就是leader节点了。zookeeper中有三种选举算法,分别是LeaderElection,FastLeaderElection,AuthLeaderElection, FastLeaderElection此算法和LeaderElection不同的是它不会像后者那样在每轮投票中要搜集到所有结果后才统计投票结果,而是不断的统计结果,一旦没有新的影响leader结果的notification出现就返回投票结果。这样的效率更高。 118题 zk的负载均衡是可以调控,nginx只是能调权重,其他需要可控的都需要自己写插件;但是nginx的吞吐量比zk大很多,应该说按业务选择用哪种方式。 117题 Zookeeper 的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和 leader的状态同步以后,恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 116题 有临时节点和永久节点,分再细一点有临时有序/无序节点,有永久有序/无序节点。当创建临时节点的程序结束后,临时节点会自动消失,临时节点上的数据也会一起消失。 115题 在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行,其他的机器可以共享这个结果,这样可以大大减少重复计算,提高性能,这就是主节点存在的意义。 114题 ZooKeeper 实现分布式事务,类似于两阶段提交,总共分为以下 4 步:客户端先给 ZooKeeper 节点发送写请求;ZooKeeper 节点将写请求转发给 Leader 节点,Leader 广播给集群要求投票,等待确认;Leader 收到确认,统计投票,票数过半则提交事务;事务提交成功后,ZooKeeper 节点告知客户端。 113题 ZooKeeper 实现分布式锁的步骤如下:客户端连接 ZooKeeper,并在 /lock 下创建临时的且有序的子节点,第一个客户端对应的子节点为 /lock/lock-10000000001,第二个为 /lock/lock-10000000002,以此类推。客户端获取 /lock 下的子节点列表,判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是则认为获得锁,否则监听刚好在自己之前一位的子节点删除消息,获得子节点变更通知后重复此步骤直至获得锁;执行业务代码;完成业务流程后,删除对应的子节点释放锁。 112题 ZooKeeper 特性如下:顺序一致性(Sequential Consistency):来自相同客户端提交的事务,ZooKeeper 将严格按照其提交顺序依次执行;原子性(Atomicity):于 ZooKeeper 集群中提交事务,事务将“全部完成”或“全部未完成”,不存在“部分完成”;单一系统镜像(Single System Image):客户端连接到 ZooKeeper 集群的任意节点,其获得的数据视图都是相同的;可靠性(Reliability):事务一旦完成,其产生的状态变化将永久保留,直到其他事务进行覆盖;实时性(Timeliness):事务一旦完成,客户端将于限定的时间段内,获得最新的数据。 111题 ZooKeeper 通常有三种搭建模式:单机模式:zoo.cfg 中只配置一个 server.id 就是单机模式了,此模式一般用在测试环境,如果当前主机宕机,那么所有依赖于当前 ZooKeeper 服务工作的其他服务器都不能进行正常工作;伪分布式模式:在一台机器启动不同端口的 ZooKeeper,配置到 zoo.cfg 中,和单机模式相同,此模式一般用在测试环境;分布式模式:多台机器各自配置 zoo.cfg 文件,将各自互相加入服务器列表,上面搭建的集群就是这种完全分布式。 110题 ZooKeeper 主要提供以下功能:分布式服务注册与订阅:在分布式环境中,为了保证高可用性,通常同一个应用或同一个服务的提供方都会部署多份,达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑,比较典型的服务注册与订阅,如 Dubbo。分布式配置中心:发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到 ZooKeeper 节点上,供订阅者获取数据,实现配置信息的集中式管理和动态更新。命名服务:在分布式系统中,通过命名服务客户端应用能够根据指定名字来获取资源、服务地址和提供者等信息。分布式锁:这个主要得益于 ZooKeeper 为我们保证了数据的强一致性。 109题 Dubbo是 SOA 时代的产物,它的关注点主要在于服务的调用,流量分发、流量监控和熔断。而 Spring Cloud诞生于微服务架构时代,考虑的是微服务治理的方方面面,另外由于依托了 Spirng、Spirng Boot的优势之上,两个框架在开始目标就不一致,Dubbo 定位服务治理、Spirng Cloud 是一个生态。 108题 Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo还提供服务黑白名单,来控制服务所允许的调用方。 107题 Dubbo超时时间设置有两种方式: 服务提供者端设置超时时间,在Dubbo的用户文档中,推荐如果能在服务端多配置就尽量多配置,因为服务提供者比消费者更清楚自己提供的服务特性。 服务消费者端设置超时时间,如果在消费者端设置了超时时间,以消费者端为主,即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时,服务端线程不会定制,会产生警告。 106题 Random LoadBalance: 随机选取提供者策略,有利于动态调整提供者权重。截面碰撞率高,调用次数越多,分布越均匀; RoundRobin LoadBalance: 轮循选取提供者策略,平均分布,但是存在请求累积的问题; LeastActive LoadBalance: 最少活跃调用策略,解决慢提供者接收更少的请求; ConstantHash LoadBalance: 一致性Hash策略,使相同参数请求总是发到同一提供者,一台机器宕机,可以基于虚拟节点,分摊至其他提供者,避免引起提供者的剧烈变动; 缺省时为Random随机调用。 105题 Consumer(消费者),连接注册中心 ,并发送应用信息、所求服务信息至注册中心。 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。 Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。 Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer。 104题 Provider:暴露服务的服务提供方。 Consumer:调用远程服务的服务消费方。 Registry:服务注册与发现的注册中心。 Monitor:统计服务的调用次调和调用时间的监控中心。 Container:服务运行容器。 103题 主要就是如下3个核心功能: Remoting:网络通信框架,提供对多种NIO框架抽象封装,包括“同步转异步”和“请求-响应”模式的信息交换方式。 Cluster:服务框架,提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。 Registry:服务注册,基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。 102题 透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。 101题 垂直分表定义:将一个表按照字段分成多表,每个表存储其中一部分字段。水平分表是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中。 100题 垂直分库是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念是专库专用。水平分库是把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上。 99题 QPS:每秒查询数。TPS:每秒处理事务数。Uptime:服务器已经运行的时间,单位秒。Questions:已经发送给数据库查询数。Com_select:查询次数,实际操作数据库的。Com_insert:插入次数。Com_delete:删除次数。Com_update:更新次数。Com_commit:事务次数。Com_rollback:回滚次数。 98题 如果需要跨主机进行JOIN,跨应用进行JOIN,或者数据库不能获得较好的执行计划,都可以自己通过程序来实现JOIN。 例如:SELECT a.,b. FROM a,b WHERE a.col1=b.col1 AND a.col2> 10 ORDER BY a.col2; 可以利用程序实现,先SELECT * FROM a WHERE a.col2>10 ORDER BY a.col2;–(1) 利用(1)的结果集,做循环,SELECT * FROM b WHERE b.col1=a.col1; 这样可以避免排序,可以在程序里控制执行的速度,有效降低数据库压力,也可以实现跨主机的JOIN。 97题 搭建复制的必备条件:复制的机器之间网络通畅,Master打开了binlog。 搭建复制步骤:建立用户并设置权限,修改配置文件,查看master状态,配置slave,启动从服务,查看slave状态,主从测试。 96题 Heartbeat方案:利用Heartbeat管理VIP,利用crm管理MySQL,MySQL进行双M复制。(Linux系统下没有分库的标准方案)。 LVS+Keepalived方案:利用Keepalived管理LVS和VIP,LVS分发请求到MySQL,MySQL进行双M复制。(Linux系统下无分库无事务的方案)。 Cobar方案:利用Cobar进行HA和分库,应用程序请求Cobar,Cobar转发请求道数据库。(有分库的标准方案,Unix下唯一方案)。 95题 聚集(clustered)索引,也叫聚簇索引,数据行的物理顺序与列值(一般是主键的那一列)的逻辑顺序相同,一个表中只能拥有一个聚集索引。但是,覆盖索引可以模拟多个聚集索引。存储引擎负责实现索引,因此不是所有的存储索引都支持聚集索引。当前,SolidDB和InnoDB是唯一支持聚集索引的存储引擎。 优点:可以把相关数据保存在一起。数据访问快。 缺点:聚集能最大限度地提升I/O密集负载的性能。聚集能最大限度地提升I/O密集负载的性能。建立在聚集索引上的表在插入新行,或者在行的主键被更新,该行必须被移动的时候会进行分页。聚集表可会比全表扫描慢,尤其在表存储得比较稀疏或因为分页而没有顺序存储的时候。第二(非聚集)索引可能会比预想的大,因为它们的叶子节点包含了被引用行的主键列。 94题 以下原因是导致mysql 表毁坏的常见原因: 服务器突然断电导致数据文件损坏; 强制关机,没有先关闭mysql 服务; mysqld 进程在写表时被杀掉; 使用myisamchk 的同时,mysqld 也在操作表; 磁盘故障;服务器死机;mysql 本身的bug 。 93题 1.定位慢查询 首先先打开慢查询日志设置慢查询时间; 2.分析慢查询(使用explain工具分析sql语句); 3.优化慢查询 。

游客ih62co2qqq5ww 2020-06-15 13:55:41 0 浏览量 回答数 0

问题

社区系统 Icarus 1.3.0

寒喵 2019-12-01 21:51:20 1292 浏览量 回答数 0

回答

Go 的优势在于能够将简单的和经过验证的想法结合起来,同时避免了其他语言中出现的许多问题。本文概述了 Go 背后的一些设计原则和工程智慧,作者认为,Go 语言具备的所有这些优点,将共同推动其成为接替 Java 并主导下一代大型软件开发平台的最有力的编程语言候选。很多优秀的编程语言只是在个别领域比较强大,如果将所有因素都纳入考虑,没有其他语言能够像 Go 语言一样“全面开花”,在大型软件工程方面,尤为如此。 基于现实经验 Go 是由经验丰富的软件行业老手一手创建的,长期以来,他们对现有语言的各种缺点有过切身体会的痛苦经历。几十年前,Rob Pike 和 Ken Thompson 在 Unix、C 和 Unicode 的发明中起到了重要作用。Robert Griensemer 在为 JavaScript 和 Java 开发 V8 和 HotSpot 虚拟机之后,在编译器和垃圾收集方面拥有数十年的经验。有太多次,他们不得不等待 Google 规模的 C++/Java 代码库进行编译。于是,他们开始着手创建新的编程语言,将他们半个世纪以来的编写代码所学到的一切经验包含进去。 专注于大型工程 小型工程项目几乎可以用任何编程语言来成功构建。当成千上万的开发人员在数十年的持续时间压力下,在包含数千万行代码的大型代码库上进行协作时,就会发生真正令人痛苦的问题。这样会导致一些问题,如下: 较长的编译时间导致中断开发。代码库由几个人 / 团队 / 部门 / 公司所拥有,混合了不同的编程风格。公司雇佣了数千名工程师、架构师、测试人员、运营专家、审计员、实习生等,他们需要了解代码库,但也具备广泛的编码经验。依赖于许多外部库或运行时,其中一些不再以原始形式存在。在代码库的生命周期中,每行代码平均被重写 10 次,被弄得千疮百痍,而且还会发生技术偏差。文档不完整。 Go 注重减轻这些大型工程的难题,有时会以使小型工程变得更麻烦为代价,例如,代码中到处都需要几行额外的代码行。 注重可维护性 Go 强调尽可能多地将工作转给自动化的代码维护工具中。Go 工具链提供了最常用的功能,如格式化代码和导入、查找符号的定义和用法、简单的重构以及代码异味的识别。由于标准化的代码格式和单一的惯用方式,机器生成的代码更改看起来非常接近 Go 中人为生成的更改并使用类似的模式,从而允许人机之间更加无缝地协作。 保持简单明了 初级程序员为简单的问题创建简单的解决方案。高级程序员为复杂的问题创建复杂的解决方案。伟大的程序员找到复杂问题的简单解决方案。 ——Charles Connell 让很多人惊讶的一点是,Go 居然不包含他们喜欢的其他语言的概念。Go 确实是一种非常小巧而简单的语言,只包含正交和经过验证的概念的最小选择。这鼓励开发人员用最少的认知开销来编写尽可能简单的代码,以便许多其他人可以理解并使用它。 使事情清晰明了 良好的代码总是显而易见的,避免了那些小聪明、难以理解的语言特性、诡异的控制流和兜圈子。 许多语言都致力提高编写代码的效率。然而,在其生命周期中,人们阅读代码的时间却远远超过最初编写代码所需的时间(100 倍)。例如,审查、理解、调试、更改、重构或重用代码。在查看代码时,往往只能看到并理解其中的一小部分,通常不会有完整的代码库概述。为了解释这一点,Go 将所有内容都明确出来。 错误处理就是一个例子。让异常在各个点中断代码并在调用链上冒泡会更容易。Go 需要手动处理和返回每个错误。这使得它可以准确地显示代码可以被中断的位置以及如何处理或包装错误。总的来说,这使得错误处理编写起来更加繁琐,但是也更容易理解。 简单易学 Go 是如此的小巧而简单,以至于人们可以在短短几天内就能研究通整个语言及其基本概念。根据我们的经验,培训用不了一个星期(相比于掌握其他语言需要几个月),初学者就能够理解 Go 专家编写的代码,并为之做出贡献。为了方便吸引更多的用户,Go 网站提供了所有必要的教程和深入研究的文章。这些教程在浏览器中运行,允许人们在将 Go 安装到本地计算机上之前就能够学习和使用 Go。 解决之道 Go 强调的是团队之间的合作,而不是个人的自我表达。 在 Go(和 Python)中,所有的语言特性都是相互正交和互补的,通常有一种方法可以做一些事情。如果你想让 10 个 Python 或 Go 程序员来解决同一个问题,你将会得到 10 个相对类似的解决方案。不同的程序员在彼此的代码库中感觉更自在。在查看其他人的代码时,国骂会更少,而且人们的工作可以更好地融合在一起,从而形成了一致的整体,人人都为之感到自豪,并乐于工作。这还避免了大型工程的问题,如: 开发人员认为良好的工作代码很“混乱”,并要求在开始工作之前进行重写,因为他们的思维方式与原作者不同。 不同的团队成员使用不同的语言子集来编写相同代码库的部分内容。 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/e64418f1455d46aaacfdd03fa949f16d.png) 简单、内置的并发性 Go 专为现代多核硬件设计。 目前使用的大多数编程语言(Java、JavaScript、Python、Ruby、C、C++)都是 20 世纪 80 年代到 21 世纪初设计的,当时大多数 CPU 只有一个计算内核。这就是为什么它们本质上是单线程的,并将并行化视为边缘情况的马后炮。通过现成和同步点之类的附加组件来实现,而这些附加组件既麻烦又难以正确使用。第三方库虽然提供了更简单的并发形式,如 Actor 模型,但是总有多个可用选项,结果导致了语言生态系统的碎片化。今天的硬件拥有越来越多的计算内核,软件必须并行化才能高效运行。Go 是在多核处理器时代编写的,并且在语言中内置了简单、高级的 CSP 风格并发性。 面向计算的语言原语 就深层而言,计算机系统接收数据,对其进行处理(通常要经过几个步骤),然后输出结果数据。例如,Web 服务器从客户端接收 HTTP 请求,并将其转换为一系列数据库或后端调用。一旦这些调用返回,它就将接收到的数据转换成 HTML 或 JSON 并将其输出给调用者。Go 的内置语言原语直接支持这种范例: 结构表示数据 读和写代表流式 IO 函数过程数据 goroutines 提供(几乎无限的)并发性 在并行处理步骤之间传输管道数据 因为所有的计算原语都是由语言以直接形式提供的,因此 Go 源代码更直接地表达了服务器执行的操作。 OO — 好的部分 更改基类中的某些内容的副作用 面向对象非常有用。过去几十年来,面向对象的使用富有成效,并让我们了解了它的哪些部分比其他部分能够更好地扩展。Go 在面向对象方面采用了一种全新的方法,并记住了这些知识。它保留了好的部分,如封装、消息传递等。Go 还避免了继承,因为它现在被认为是有害的,并为组合提供了一流的支持。 现代标准库 目前使用的许多编程语言(Java、JavaScript、Python、Ruby)都是在互联网成为当今无处不在的计算平台之前设计的。因此,这些语言的标准库只提供了相对通用的网络支持,而这些网络并没有针对现代互联网进行优化。Go 是十年前创建的,当时互联网已全面发展。Go 的标准库允许在没有第三方库的情况下创建更复杂的网络服务。这就避免了第三方库的常见问题: 碎片化:总是有多个选项实现相同的功能。 膨胀:库常常实现的不仅仅是它们的用途。 依赖地狱:库通常依赖于特定版本的其他库。 未知质量:第三方代码的质量和安全性可能存在问题。 未知支持:第三方库的开发可能随时停止支持。 意外更改:第三方库通常不像标准库那样严格地进行版本控制。 关于这方面更多的信息请参考 Russ Cox 提供的资料 标准化格式 Gofmt 的风格没有人会去喜欢,但人人都会喜欢 gofmt。 ——Rob Pike Gofmt 是一种以标准化方式来格式化 Go 代码的程序。它不是最漂亮的格式化方式,但却是最简单、最不令人生厌的格式化方式。标准化的源代码格式具有惊人的积极影响: 集中讨论重要主题: 它消除了围绕制表符和空格、缩进深度、行长、空行、花括号的位置等一系列争论。 开发人员在彼此的代码库中感觉很自在, 因为其他代码看起来很像他们编写的代码。每个人都喜欢自由地按照自己喜欢的方式进行格式化代码,但如果其他人按照自己喜欢的方式格式化了代码,这么做很招人烦。 自动代码更改并不会打乱手写代码的格式,例如引入了意外的空白更改。 许多其他语言社区现在正在开发类似 gofmt 的东西。当作为第三方解决方案构建时,通常会有几个相互竞争的格式标准。例如,JavaScript 提供了 Prettier 和 StandardJS。这两者都可以用,也可以只使用其中的一个。但许多 JS 项目并没有采用它们,因为这是一个额外的决策。Go 的格式化程序内置于该语言的标准工具链中,因此只有一个标准,每个人都在使用它。 快速编译 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/8a76f3f07f484266af42781d9e7b8692.png) 对于大型代码库来说,它们长时间的编译是促使 Go 诞生的原因。Google 主要使用的是 C++ 和 Java,与 Haskell、Scala 或 Rust 等更复杂的语言相比,它们的编译速度相对较快。尽管如此,当编译大型代码库时,即使是少量的缓慢也会加剧编译的延迟,从而激怒开发人员,并干扰流程。Go 的设计初衷是为了提高编译效率,因此它的编译器速度非常快,几乎没有编译延迟的现象。这给 Go 开发人员提供了与脚本类语言类似的即时反馈,还有静态类型检查的额外好处。 交叉编译 由于语言运行时非常简单,因此它被移植到许多平台,如 macOS、Linux、Windows、BSD、ARM 等。Go 可以开箱即用地为所有这些平台编译二进制文件。这使得从一台机器进行部署变得很容易。 快速执行 Go 的运行速度接近于 C。与 JITed 语言(Java、JavaScript、Python 等)不同,Go 二进制文件不需要启动或预热的时间,因为它们是作为编译和完全优化的本地代码的形式发布的。Go 的垃圾收集器仅引入微秒量级的可忽略的停顿。除了快速的单核性能外,Go 还可以轻松利用所有的 CPU 内核。 内存占用小 像 JVM、Python 或 Node 这样的运行时不仅仅在运行时加载程序代码,每次运行程序时,它们还会加载大型且高度复杂的基础架构,以进行编译和优化程序。如此一来,它们的启动时间就变慢了,并且还占用了大量内存(数百兆字节)。而 Go 进程的开销更小,因为它们已经完全编译和优化,只需运行即可。Go 还以非常节省内存的方式来存储数据。在内存有限且昂贵的云环境中,以及在开发过程中,这一点非常重要。我们希望在一台机器上能够快速启动整个堆栈,同时将内存留给其他软件。 部署规模小 Go 的二进制文件大小非常简洁。Go 应用程序的 Docker 镜像通常比用 Java 或 Node 编写的等效镜像要小 10 倍,这是因为它无需包含编译器、JIT,以及更少的运行时基础架构的原因。这些特点,在部署大型应用程序时很重要。想象一下,如果要将一个简单的应用程序部署到 100 个生产服务器上会怎么样?如果使用 Node/JVM 时,我们的 Docker 注册表就必须提供 100 个 docker 镜像,每个镜像 200MB,那么一共就需要 20GB。要完成这些部署就需要一些时间。想象一下,如果我们想每天部署 100 次的话,如果使用 Go 服务,那么 Docker 注册表只需提供 10 个 docker 镜像,每个镜像只有 20MB,共只需 2GB 即可。大型 Go 应用程序可以更快、更频繁地部署,从而使得重要更新能够更快地部署到生产环境中。 独立部署 Go 应用程序部署为一个包含所有依赖项的单个可执行文件,并无需安装特定版本的 JVM、Node 或 Python 运行时;也不必将库下载到生产服务器上,更无须对运行 Go 二进制文件的机器进行任何更改。甚至也不需要讲 Go 二进制文件包装到 Docker 来共享他们。你需要做的是,只是将 Go 二进制文件放到服务器上,它就会在那里运行,而不用关心服务器运行的是什么。前面所提到的那些,唯一的例外是使用net和os/user包时针对对glibc的动态链接。 供应依赖关系 Go 有意识避免使用第三方库的中央存储库。Go 应用程序直接链接到相应的 Git 存储库,并将所有相关代码下载(供应)到自己的代码库中。这样做有很多好处: 在使用第三方代码之前,我们可以对其进行审查、分析和测试。该代码就和我们自己的代码一样,是我们应用程序的一部分,应该遵循相同的质量、安全性和可靠性标准。 无需永久访问存储依赖项的各个位置。从任何地方(包括私有 Git repos)获取第三方库,你就能永久拥有它们。 经过验收后,编译代码库无需进一步下载依赖项。 若互联网某处的代码存储库突然提供不同的代码,这也并不足为奇。 即使软件包存储库速度变慢,或托管包不复存在,部署也不会因此中断。 兼容性保证 Go 团队承诺现有的程序将会继续适用于新一代语言。这使得将大型项目升级到最新版本的编译器会非常容易,并且可从它们带来的许多性能和安全性改进中获益。同时,由于 Go 二进制文件包含了它们需要的所有依赖项,因此可以在同一服务器上并行运行使用不同版本的 Go 编译器编译的二进制文件,而无需进行复杂的多个版本的运行时设置或虚拟化。 文档 在大型工程中,文档对于使软件可访问性和可维护性非常重要。与其他特性类似,Go 中的文档简单实用: 由于它是嵌入到源代码中的,因此两者可以同时维护。 它不需要特殊的语法,文档只是普通的源代码注释。 可运行单元测试通常是最好的文档形式。因此 Go 要求将它们嵌入到文档中。 所有的文档实用程序都内置在工具链中,因此每个人都使用它们。 Go linter 需要导出元素的文档,以防止“文档债务”的积累。 商业支持的开源 当商业实体在开放式环境下开发时,那么一些最流行的、经过彻底设计的软件就会出现。这种设置结合了商业软件开发的优势——一致性和精细化,使系统更为健壮、可靠、高效,并具有开放式开发的优势,如来自许多行业的广泛支持,多个大型实体和许多用户的支持,以及即使商业支持停止的长期支持。Go 就是这样发展起来的。 缺点 当然,Go 也并非完美无缺,每种技术选择都是有利有弊。在决定选择 Go 之前,有几个方面需要进行考虑考虑。 未成熟 虽然 Go 的标准库在支持许多新概念(如 HTTP 2 Server push 等)方面处于行业领先地位,但与 JVM 生态系统中的第三方库相比,用于外部 API 的第三方 Go 库可能不那么成熟。 即将到来的改进 由于清楚几乎不可能改变现有的语言元素,Go 团队非常谨慎,只在新特性完全开发出来后才添加新特性。在经历了 10 年的有意稳定阶段之后,Go 团队正在谋划对语言进行一系列更大的改进,作为 Go 2.0 之旅的一部分。 无硬实时 虽然 Go 的垃圾收集器只引入了非常短暂的停顿,但支持硬实时需要没有垃圾收集的技术,例如 Rust。 结语 本文详细介绍了 Go 语言的一些优秀的设计准则,虽然有的准则的好处平常看起来没有那么明显。但当代码库和团队规模增长几个数量级时,这些准则可能会使大型工程项目免于许多痛苦。总的来说,正是这些设计准则让 Go 语言成为了除 Java 之外的编程语言里,用于大型软件开发项目的绝佳选择。

有只黑白猫 2020-01-07 14:11:38 0 浏览量 回答数 0

回答

在Logstore列表页面单击诊断可以查看当前Logstore的所有日志采集报错,本文档介绍具体报错类型及对应的处理方式。 若您遇到其他问题,请提交工单处理。 错误类型 错误说明 处理方式 LOGFILE_PERMINSSION_ALARM Logtail无权限读取指定文件。 检查服务器Logtail的启动账户,建议以root方式启动。 SPLIT_LOG_FAIL_ALARM 行首正则与日志行首匹配失败,无法对日志做分行。 检查行首正则正确性,如果是单行日志可以配置为.*。 MULTI_CONFIG_MATCH_ALARM 同一个文件,只能被一个Logtail的配置收集,不支持同时被多个Logtail配置收集。 说明 Docker标准输出可以被多个Logtail配置采集。 检查一个文件是否在多个配置中被收集,并删除多余的配置。 REGEX_MATCH_ALARM 正则表达式解析模式下,日志内容和正则表达式不匹配。 复制错误内容中的日志样例重新尝试匹配,并生成新的解析正则式。 PARSE_LOG_FAIL_ALARM JSON、分隔符等解析模式下,由于日志格式不符合定义而解析失败。 请单击错误信息,查看匹配失败的详细报错。 CATEGORY_CONFIG_ALARM Logtail采集配置不合法。 常见的错误为正则表达式提取文件路径作为Topic失败,其它错误请提工单解决。 LOGTAIL_CRASH_ALARM Logtail因超过服务器资源使用上限而崩溃。 请参考配置启动参数修改CPU、内存使用上限,如有疑问请提工单。 REGISTER_INOTIFY_FAIL_ALARM Linux下注册日志监听失败,可能由于没有文件夹权限或文件夹被删除。 检查Logtail是否有权限访问该文件夹或该文件夹是否被删除。 DISCARD_DATA_ALARM 配置Logtail使用的CPU资源不够或网络发送流控。 请参考配置启动参数修改CPU使用上限或网络发送并发限制,如有疑问请提工单解决。 SEND_DATA_FAIL_ALARM 主账号未创建任何AccessKey。 Logtail客户端机器与日志服务的服务器端无法连通或者网络链路质量较差。 服务器端写入配额不足。 主账号创建AK。 检查本地配置文件/usr/local/ilogtail/ilogtail_config.json,执行curl <服务器地址>,查看是否有内容返回。 为Logstore增加Shard数目,以支持更大数据量的写入。 REGISTER_INOTIFY_FAIL_ALARM Logtail为日志目录注册的inotify watcher失败。 请检查目录是否存在以及目录权限设置。 SEND_QUOTA_EXCEED_ALARM 日志写入流量超出限制。 在控制台扩容分区。 READ_LOG_DELAY_ALARM 日志采集进度落后于日志产生进度,一般是由于配置Logtail使用的CPU资源不够或是网络发送流控导致。 请参考Logtail配置启动参数修改CPU使用上限或网络发送并发限制,如有疑问请提工单。 DROP_LOG_ALARM 日志采集进度落后于日志产生进度,且未处理的日志轮转超过20个,一般是由于配置Logtail使用的CPU资源不够或是网络发送流控导致。 请参考Logtail配置启动参数修改CPU使用上限或网络发送并发限制,如有疑问请提工单。 LOGDIR_PERMINSSION_ALARM 没有日志监控目录读取权限。 请检查日志监控目录是否存在,若存在请检查目录权限设置。 ENCODING_CONVERT_ALARM 编码转换失败。 请检查日志编码格式配置是否与日志编码格式一致。 OUTDATED_LOG_ALARM 过期的日志,日志时间落后超过12小时。可能原因: 日志解析进度落后超过12小时。 用户自定义时间字段配置错误。 日志记录程序时间输出异常。 查看是否存在READ_LOG_DELAY_ALARM。如存在按照READ_LOG_DELAY_ALARM处理方式解决,若不存在请检查时间字段配置。 检查时间字段配置。若时间字段配置正确,请检查日志记录程序时间输出是否正常。 如有疑问请提工单。 STAT_LIMIT_ALARM 日志采集配置目录中的文件数超限。 检查采集配置目录是否有较多的文件和子目录,合理设置监控的根目录和目录最大监控深度。 DROP_DATA_ALARM 进程退出时日志落盘到本地超时,此时会丢弃未落盘完毕的日志。 该报错通常为采集严重阻塞导致,请参考Logtail配置启动参数修改CPU使用上限或网络发送并发限制,如有疑问请提工单。 INPUT_COLLECT_ALARM 输入源采集异常。 请参考错误提示处理。 HTTP_LOAD_ADDRESS_ALARM http输入的address不合法。 请检查address合法性。 HTTP_COLLECT_ALARM http采集异常。 请根据错误提示排查,一般由于超时导致。 FILTER_INIT_ALARM 过滤器初始化异常。 一般由于过滤器的正则表达式非法导致,请根据提示修复。 INPUT_CANAL_ALARM MySQL binlog运行异常。 请根据错误提示排查。在配置更新时canal服务可能重启,服务重启的错误可以忽略。 CANAL_INVALID_ALARM MySQL binlog内部状态异常。 此错误一般由于运行时表的schema信息变更导致meta不一致,请确认报错期间是否在修改表的schema。其他情况请提工单。 MYSQL_INIT_ALARM MySQL初始化异常。 请参考错误提示处理。 MYSQL_CHECKPOING_ALARM MySQL checkpoint格式异常。 请确认是否修改该配置中的checkpoint相关配置,其他情况请提工单。 MYSQL_TIMEOUT_ALARM MySQL查询超时。 请确认MySQL服务器和网络是否异常。 MYSQL_PARSE_ALARM MySQL查询结果解析失败。 请确认MySQL配置的checkpoint格式是否匹配对应字段的格式。 AGGREGATOR_ADD_ALARM 向队列中添加数据失败。 这种情况是由于数据发送过快,若真实数据量很大,则无需关心。 ANCHOR_FIND_ALARM anchor插件错误、配置错误或存在不符合配置的日志。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据详细报错中的信息,检查相应的配置是否存在问题。 anchor cannot find key:配置中指定了SourceKey但日志中不存在对应的字段。 anchor no start:无法从SourceKey的值中找到Start对应的内容。 anchor no stop:无法从 SourceKey 的值中找到Stop对应的内容。 ANCHOR_JSON_ALARM anchor插件错误,对已配置的Start和Stop所确定的内容执行JSON展开时发生错误。 请单击错误查看详细报错,检查所处理的内容以及相关的配置,确定是否有配置错误或不合法日志。 CANAL_RUNTIME_ALARM binlog插件运行时错误。 请单击错误查看详细报错,根据错误信息进行进一步地排查,错误一般与所连接的MySQL master相关。 CHECKPOINT_INVALID_ALARM 插件内Checkpoint解析失败。 请单击错误查看详细报错,根据其中的检查点键、检查点内容(前 1024 个字节)以及具体的错误信息进行进一步排查。 DIR_EXCEED_LIMIT_ALARM Logtail同时监听的目录数超出限制。 检查当前Logstore的采集配置以及该Logtail上应用的其他配置是否会包含较多的目录数,合理设置监控的根目录和目录最大监控深度。 DOCKER_FILE_MAPPING_ALARM 执行Logtail命令添加Docker文件映射失败。 请单击错误查看详细报错,根据其中的命令以及具体的错误信息进行进一步排查。 DOCKER_FILE_MATCH_ALARM 无法在Docker容器中查找到指定文件。 请单击错误查看详细报错,根据其中的容器信息以及查找的文件路径进行进一步排查。 DOCKER_REGEX_COMPILE_ALARM docker stdout插件错误,根据配置中的BeginLineRegex构建正则表达式失败。 请单击错误查看详细报错,检查其中的正则表达式是否正确。 DOCKER_STDOUT_INIT_ALARM docker stdout采集初始化失败。 请单击错误查看详细报错,报错根据内容分为以下几类: host...version...error:请检查配置中指定的Docker engine是否可访问。 load checkpoint error:加载检查点失败,如无影响可忽略此错误。 container...:指定容器存在非法label值,目前仅允许配置stdout和stderr。请结合详细错误进行检查。 DOCKER_STDOUT_START_ALARM Docker stdout初始化采集时,stdout文件大小超过限制。 一般由于首次采集时stdout文件已存在,可忽略。 DOCKER_STDOUT_STAT_ALARM Docker stdout无法检查到stdout文件。 一般由于容器退出时无法访问到文件,可忽略。 FILE_READER_EXCEED_ALARM Logtail同时打开的文件对象数量超过限制。 一般由于当前处于采集状态的文件数过多,请检查采集配置是否合理。 GEOIP_ALARM geoip插件错误。 请单击错误查看详细报错,报错根据内容分为以下几类: invalid ip...:获取IP地址失败,请检查配置中的 SourceKey 是否正确或是否存在不合法日志。 parse ip...:根据IP地址解析城市失败,请查看详细错误信息进行排查。 cannot find key...:无法从日志中查看到指定的SourceKey,请检查配置是否正确或是否存在不合法日志。 HTTP_INIT_ALARM http插件错误,配置中指定的ResponseStringMatch正则表达式编译错误。 请单击错误查看详细报错,检查其中的正则表达式是否正确。 HTTP_PARSE_ALARM http插件错误,获取HTTP响应失败。 请单击错误查看详细报错,根据其中的具体错误信息对配置内容或所请求的HTTP服务器进行检查。 INIT_CHECKPOINT_ALARM binlog插件错误,加载检查点失败,插件将忽略检查点并从头开始处理。 请单击错误查看详细报错,根据其中的具体错误信息来确定是否可忽略此错误。 LOAD_LOCAL_EVENT_ALARM Logtail执行了本地事件处理。 此警告一般不会出现,如果非人为操作引起此警告,才需要进行错误排查。请单击错误查看详细报错,根据其中的文件名、配置名、project、logstore等信息进行进一步地排查。 LOG_REGEX_FIND_ALARM processor_split_log_regex以及 processor_split_log_string插件错误,无法从日志中获取到配置中指定的 SplitKey。 请单击错误查看详细报错,检查是否存在配置错误的情况。 LUMBER_CONNECTION_ALARM service_lumberjack插件错误,停止插件时关闭服务器错误。 请单击错误查看详细报错,根据其中的具体错误信息进行进一步排查,此错误一般可忽略。 LUMBER_LISTEN_ALARM service_lumberjack插件错误,初始化进行监听时发生错误。 请单击错误查看详细报错,报错根据内容分为以下几类: init tls error...:请结合具体的错误信息检查 TLS 相关的配置是否正确 listen init error...:请结合具体的错误信息检查地址相关的配置是否正确。 LZ4_COMPRESS_FAIL_ALARM Logtail执行LZ4压缩发生错误。 请单击错误查看详细报错,根据其中的log lines、project、category、region等值来进行进一步排查。 MYSQL_CHECKPOINT_ALARM MySQL插件错误,检查点相关错误。 请单击错误查看详细报错,报错根据内容分为以下几类: init checkpoint error...:初始化检查点失败,请根据错误信息检查配置指定的检查点列以及所获取的值是否正确。 not matched checkpoint...:检查点信息不匹配,请根据错误信息检查是否是由于配置更新等人为原因导致的错误,如果是则可忽略。 NGINX_STATUS_COLLECT_ALARM nginx_status插件错误,获取状态发生错误。 请单击错误查看详细报错,根据其中的URL以及具体的错误信息来进行进一步排查。 NGINX_STATUS_INIT_ALARM nginx_status插件错误,初始化解析配置中指定的URL失败。 请单击错误查看详细报错,根据其中的URL检查地址是否正确配置。 OPEN_FILE_LIMIT_ALARM Logtail已打开文件数量超过限制,无法打开新的文件。 请单击错误查看详细报错,根据其中的日志文件路径、Project、Logstore等信息进行进一步排查。 OPEN_LOGFILE_FAIL_ALARM Logtail打开文件出错。 请单击错误查看详细报错,根据其中的日志文件路径、Project、Logstore等信息进行进一步排查。 PARSE_DOCKER_LINE_ALARM service_docker_stdout插件错误,解析日志失败。 请单击错误查看详细报错,报错根据内容分为以下几类: parse docker line error: empty line:日志为空。 parse json docker line error...:以JSON格式解析日志失败,请根据错误信息以及日志的前512个字节进行排查。 parse cri docker line error...:以CRI格式解析日志失败,请根据错误信息以及日志的前512个字节进行排查。 PLUGIN_ALARM 插件初始化及相关调用发生错误。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据具体的错误信息进行进一步排查。 init plugin error...:初始化插件失败。 hold on error...:暂停插件运行失败。 resume error...:恢复插件运行失败。 start service error...:启动 service input类型的插件失败。 stop service error...:停止 service input类型的插件失败。 PROCESSOR_INIT_ALARM regex插件错误,编译配置中指定的Regex正则表达式失败。 请单击错误查看详细报错,检查其中的正则表达式是否正确。 PROCESS_TOO_SLOW_ALARM Logtail日志解析速度过慢。 单击错误查看详细报错,根据其中的日志数量、缓冲区大小、解析时间来确定是否正常。 如果不正常,检查Logtail所在节点是否有其他进程占用了过多的CPU资源或是存在效率较低的正则表达式等不合理的解析配置。 REDIS_PARSE_ADDRESS_ALARM redis插件错误,配置中提供的ServerUrls存在解析失败的情况。 请单击错误查看详细报错,对其中报错的URL进行检查。 REGEX_FIND_ALARM regex 插件错误,无法从日志中找到配置中SourceKey指定的字段。 请单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。 REGEX_UNMATCHED_ALARM regex插件错误,匹配失败。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据具体的错误信息进行进一步地排查,例如检查配置是否正确。 unmatch this log content...:日志无法匹配配置中的正则表达式 match result count less...:匹配的结果数量少于配置中指定的 Keys 数量。 SAME_CONFIG_ALARM 同一个Logstore下存在同名的配置,后发现的配置会被抛弃。 请单击错误查看详细报错,根据其中的配置路径等信息排查是否存在配置错误的情况。 SPLIT_FIND_ALARM split_char以及split_string插件错误,无法从日志中找到配置中SourceKey指定的字段。 请单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。 SPLIT_LOG_ALARM processor_split_char以及processor_split_string插件错误,解析得到的字段数量与SplitKeys中指定的不相同。 请单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。 STAT_FILE_ALARM 插件内通过LogFileReader对象进行文件采集时发生错误。 请单击错误查看详细报错,根据其中的文件路径、错误信息进行进一步排查。 SERVICE_SYSLOG_INIT_ALARM service_syslog插件错误,初始化失败。 请单击错误查看详细报错,检查配置中的Address是否正确。 SERVICE_SYSLOG_STREAM_ALARM service_syslog插件错误,通过TCP采集时发生错误。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据详细报错中的具体错误信息进行排查。 accept error...:执行Accept时发生错误,插件将等待一段时间后重试。 setKeepAlive error...:设置 Keep Alive失败,插件将跳过此错误并继续运行。 connection i/o timeout...:通过TCP读取时超时,插件将重设超时并继续读取。 scan error...:TCP 读取错误,插件将等待一段时间后重试。 SERVICE_SYSLOG_PACKET_ALARM service_syslog插件错误,通过UDP采集时发生错误。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据详细报错中的具体错误信息进行排查。 connection i/o timeout...:通过UDP读取时超时,插件将重设超时并继续读取。 read from error...:UDP读取错误,插件将等待一段时间后重试。

保持可爱mmm 2020-03-26 23:02:18 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 云栖号物联网 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 云栖号弹性计算 阿里云云栖号 云栖号案例 云栖号直播