• 关于

    A B问题未响应

    的搜索结果

回答

以下为压测和调试日志中,常见的 Error 信息: class java.net.SocketTimeoutException:null 表示请求在等待响应或者读取中途(idle)超时。请检查服务端健康状况或者 PTS 的压测 API 超时时间的设置是否合理,另外还有可能是服务端处理能力出现瓶颈。 class java.net.ConnectException:null 表示请求在与远端(被压测端)建立 TCP 连接时就出现失败或者被远端拒绝。请检查服务端健康状况,或者是网络连接层是否有瓶颈。 class java.util.concurrent.TimeoutException:null 表示请求在与远端(被压测端)建立 TCP 连接时就出现失败或者被远端拒绝。请检查服务端健康状况,或者是网络连接层是否有瓶颈。 class org.apache.http.ConnectionClosedException:Connection closed 表示连接异常关闭,服务端主动关闭了连接。 class java.io.IOException:Connection reset by peer 表示连接被重置。若使用了 SLB,请查看 SLB 的配置是否有问题。 class org.apache.http.ConnectionClosedException:Connection closed unexpectedly 表示数据尚未接收完毕,连接就已关闭。可能服务端未及时响应或者提前终止调试或压测。 class java.lang.RuntimeException:java.net.UnknownHostException 表示域名信息无法解析。请检查域名是否已经正常注册并可以解析、未注册的域名是否已进行域名绑定。 建议结合 Timing 瀑布模型查看,各种报错都可以体现在 Timing 瀑布模型中,例如: 建立连接环节超时 等待响应或者读取响应的间隔时间超时 Waiting(TTFB)表示等待第一个响应字节的时间。这个时间包括一次完整的往返和延迟,同时包括了服务器应对响应所用的时间。 class org.apache.http.client.CircularRedirectException 表示请求出现了循环重定向的情况(A -> B -> C -> A),或者跳转超过了10次(A1 -> A2 -> A3... -> A10 ->A11)。建议取消302跳转配置后压测查看原始请求信息,并可结合Timin瀑布流查看跳转具体路径。

保持可爱mmm 2020-03-28 19:41:24 0 浏览量 回答数 0

问题

如何实现错误响应?

青衫无名 2019-12-01 21:57:01 881 浏览量 回答数 0

问题

如何解决coredata多线程的同步问题

a123456678 2019-12-01 20:27:18 967 浏览量 回答数 1

阿里云高校特惠,助力学生创业梦!0元体验,快速入门云计算!

学生动手场景应用,快速了解并掌握云服务器的各种新奇玩法!

问题

什么是错误响应?

青衫无名 2019-12-01 21:58:29 1062 浏览量 回答数 0

回答

问题原因:出现此类情况一般都是由于源站异常导致,由于CDN回源取数据的时候,如果源站在30s内没有响应,CDN就会抛出“504 Gateway Time-out”的报错; 1、如果使用的是阿里云服务器ECS,遇到此类情况时,建议先登陆管理控制台在如下图位置处查看服务器的CPU以及带宽使用是否有异常,参考CPU异常和带宽跑满的不同情况进行分别进行检查; 2、直接修改本地电脑的host文件,将域名直接指向源服务器IP,测试访问是否正常,修改方法请点击查看,如果同样无法访问,需立刻检查源服务器或者程序是否存在异常。 如问题还未解决,请联系售后技术支持 望采纳,谢谢🙏

元芳啊 2019-12-02 00:29:49 0 浏览量 回答数 0

回答

问题定义 A -> B 发起TCP请求,A端为请求侧,B端为服务侧TCP 三次握手已完成TCP 三次握手后双方没有任何数据交互B 在无预警情况下掉线(类似意外掉电重启状态) 问题答案 A侧的TCP链路状态在未发送任何数据的情况下与等待的时间相关,如果在多个超时值范围以内那么状态为established;如果触发了某一个超时的情况那么视情况的不同会有不同的改变。 一般情况下不管是KeepAlive超时还是内核超时,只要出现超时,那么必然会抛出异常,只是这个异常截获的时机会因编码方式的差异而有所不同。(同步异步IO,以及有无使用select、poll、epoll等IO多路复用机制) 原因与相关细节 大前提 基于IP网络的无状态特征,A侧系统不会在无动作情况下收到任何通知获知到B侧掉线的情况(除非AB是直连状态,那么A可以获知到自己网卡掉线的异常) 在此大前提的基础上,会因为链路环境、SOCKET设定、以及内核相关配置的不同,A侧会在不同的时机获知到B侧无响应的结果,但总归是以异常的形式获得这个结果。 <关于内核对待无数据传递SOCKET的方式> 操作系统有一堆时间超级长的兜底用timeout参数,用于在不同的时候给TCP栈一个异常退出的机会,避免无效连接过多而耗尽系统资源 其中,TCP KeepAive 特性能让应用层配置一个远小于内核timeout参数的值,用于在这一堆时间超长的兜底参数生效之前,判断链路是否为有效状态。 <关于超时的各个节点> 以下仅讨论三次握手成功之后的兜底情况 TCP链路在建立之后,内核会初始化一个由<nf_conntrack_tcp_timeout_established>参数控制的计时器(这个计时器在Ubuntu 18.04里面长达5天),以防止在未开启TCP KeepAlive的情况下连接因各种原因导致的长时间无动作而过度消耗系统资源,这个计时器会在每次TCP链路活动后重置 TCP正常传输过程中,每一次数据发送之后,必然伴随对端的ACK确认信息。如果对端因为各种原因失去反应(网络链路中断、意外掉电等)这个ACK将永远不会到来,内核在每次发送之后都会重置一个由<nf_conntrack_tcp_timeout_unacknowledged>参数控制的计时器,以防止对端以外断网导致的资源过度消耗。(这个计时器在Ubuntu 18.04里面是300秒/5分钟) 以上两个计时器作为keepalive参数未指定情况下的兜底参数,为内核自保特性,所以事件都很长,建议实际开发与运维中用更为合理的参数覆盖这些数值 <关于链路异常后发生的操作> A侧在超时退出之后一般会发送一个RST包用于告知对端重置链路,并给应用层一个异常的状态信息,视乎同步IO与异步IO的差异,这个异常获知的时机会有所不同。 B侧重启之后,因为不存有之前A-B之间建立链路相关的信息,这时候收到任何A侧来的数据都会以RST作为响应,以告知A侧链路发生异常 RST的设计用意在于链路发生意料之外的故障时告知链路上的各方释放资源(一般指的是NAT网关与收发两端);FIN的设计是用于在链路正常情况下的正常单向终止与结束。二者不可混淆。 关于阻塞 应用层到底层网卡发送的过程中,数据包会经历多个缓冲区,也会经历一到多次的分片操作,阻塞这一结果的发生是具有从底向上传递的特性。 这一过程中有一个需要强调的关键点:socket.send这个操作只是把数据发送到了内核缓冲区,只要数据量不大那么这个调用必然是在拷贝完之后立即返回的。而数据量大的时候,必然会产生阻塞。 在TCP传输中,决定阻塞与否的最终节点,是TCP的可靠传输特性。此特性决定了必须要有ACK数据包回复响应正确接收的数据段范围,内核才会把对应的数据从TCP发送缓冲区中移除,腾出空间让新的数据可以写入进来。 这个过程意味着,只要应用层发送了大于内核缓冲区可容容纳的数据量,那么必然会在应用层出现阻塞,等待ACK的到来,然后把新数据压入缓冲队列,循环往复,直到数据发送完毕。

九旬 2020-05-24 22:22:41 0 浏览量 回答数 0

问题

某政务网站性能优化

猫饭先生 2019-12-01 21:25:38 1412 浏览量 回答数 0

问题

健康检查原理

行者武松 2019-12-01 21:36:16 1626 浏览量 回答数 0

回答

web压力测试通过产生真实压力来发现问题需要关注以下方面: 1、对要测试的系统进行分析,明确需要对哪一块做压力测试。比如:淘宝网站双十一期间,秒杀跟支付,此模式用户操作中占比比较大 再比如:游戏,登录--开始战斗--结束战斗这种混合模式在用户操作中占比较大 那么就可以针对这种占比比较大的模式进行压力测试 2、明确了要测试的点后,如何对这些测试点进行施压呢? 第一种方式可以通过写脚本产生压力机器人对服务器进行发包收包操作; 第二种方式就是借助一些压力测试工具如:JMeter或LoadRunner 3、如何对这些测试点进行正确的施压呢? 那么就需要用压力测试工具或者其它方法来录制脚本,模拟用户的操作 4、对测试点该施加多大的压力比较合适?该施加多少的数据才能找出系统的瓶颈? 那么就需要明确压力测试所限制的数量,即用户并发量,这里分3种情况来明确: 1)根据上级的明确规定数量,来设定最确大值,然后根据情况往上或往下增减 2)上级未规定,由自己判断,从1开始慢慢递增。如:1,5,10,20等等 3)若做过压力测试,则可以根据上次的压力测试结果为基数进行测试 5、测试完之后,如何通过这些数据来定位性能问题呢? 虽然通过这些测试结果我们可以得到TPS(吞吐量),平均响应时间等这些数据,可判断出服务器是否存在问题,但却不能定位问题。 答案来源于网络

养狐狸的猫 2019-12-02 03:02:01 0 浏览量 回答数 0

问题

劝大家别用阿里的cdn了

猴哥派来的 2019-12-01 21:17:57 4610 浏览量 回答数 3

问题

【重要安全预警】Memcached被利用UDP反射攻击漏洞预警

正禾 2019-12-01 21:44:07 12474 浏览量 回答数 3

回答

Nginx服务器错误一般有以下几点原因: 1、请求的header过大。nginx默认的header长度上限是4k,如果超过了这个值,nginx会直接返回400错误. 解决方法:配置nginx.conf相关设置。可以通过以下2个参数来调整header上限: client_header_buffer_size 16k;large_client_header_buffers 4 16k。 2、上传文件过程中出现错误。这时浏览器显示“413 Request Entity Too Large”。这是因为没有设置client_max_body_size,这个参数默认只是1M,也就是说发布的文章内容大小不能超过1M。 解决方法:增加如下两行到nginx.conf的http{}段, 增大nginx上传文件大小限制:设置允许发布内容为8M:client_max_body_size 8M;client_body_buffer_size 128k。 另外如果运行的是php,那么还要检查php.ini,这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误:post_max_size = 8M;upload_max_filesize = 6M。 修改完配置后,别忘记重新加载。 3、客户端在为等到服务器相应返回前就关闭了客户端描述符。一般出现在客户端设置超时后,服务器主动关闭。 解决方法:根据实际Nginx后端服务器的处理时间修改客户端超时时间。 4、脚本错误(php语法错误、lua语法错误)。 解决方法:查看nginx_err_log php_err_log。 5、访问量过大,系统资源限制,不能打开过多文件。 磁盘空间不足。(access log开启可能导致磁盘满溢,服务器主动关闭)。 解决方法:修改/etc/sysctl.conf文件,并使用下面的命令确认: #sysctl -p。要使 limits.conf 文件配置生效,必须要确保 pam_limits.so 文件被加入到启动文件中。 6、后端服务无法处理,业务中断。 解决方法:从后端日志获取错误原因,解决后端服务器问题。 7、后端服务器在超时时间内,未响应Nginx代理请求。 解决方法:根据后端服务器实际处理情况,调正后端请求超时时间。 8、网站页面缓存过大。 解决方法:配置nginx.conf相关设置:fastcgi_buffers 8 128k;send_timeout 60。 “答案来源于网络,供您参考” 希望以上信息可以帮到您!

牧明 2019-12-02 02:17:24 0 浏览量 回答数 0

问题

优客服开源客服系统通信功能介绍 1.1   优客服功能? 400 报错

爱吃鱼的程序员 2020-06-03 16:49:27 2 浏览量 回答数 1

问题

CDN的range功能分析

云栖徒骇 2019-12-01 21:36:00 10325 浏览量 回答数 1

问题

性能测试技术怎么进行?

猫饭先生 2019-12-01 21:26:08 1341 浏览量 回答数 0

问题

CDN 如何实现鉴权配置?

青衫无名 2019-12-01 22:02:14 5539 浏览量 回答数 0

问题

API调用方式

云栖大讲堂 2019-12-01 21:07:55 1412 浏览量 回答数 0

问题

【精品问答】python技术1000问(2)

问问小秘 2019-12-01 22:03:02 3129 浏览量 回答数 1

回答

分布式事务的解决方案有如下几种: 全局消息基于可靠消息服务的分布式事务TCC最大努力通知方案1:全局事务(DTP模型)全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务,需要三种角色: AP:Application 应用系统 它就是我们开发的业务系统,在我们开发的过程中,可以使用资源管理器提供的事务接口来实现分布式事务。 TM:Transaction Manager 事务管理器 分布式事务的实现由事务管理器来完成,它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器,通过它们提供的XA接口来同一调度这些资源管理器,以实现分布式事务。DTP只是一套实现分布式事务的规范,并没有定义具体如何实现分布式事务,TM可以采用2PC、3PC、Paxos等协议实现分布式事务。RM:Resource Manager 资源管理器 能够提供数据服务的对象都可以是资源管理器,比如:数据库、消息中间件、缓存等。大部分场景下,数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力,它们通过XA接口,将本数据库的提交、回滚等能力提供给事务管理器调用,以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口,用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范,RM具体的实现是由数据库厂商来完成的。有没有基于DTP模型的分布式事务中间件?DTP模型有啥优缺点?方案2:基于可靠消息服务的分布式事务这种实现分布式事务的方式需要通过消息中间件来实现。假设有A和B两个系统,分别可以处理任务A和任务B。此时系统A中存在一个业务流程,需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。 title 在系统A处理任务A前,首先向消息中间件发送一条消息消息中间件收到后将该条消息持久化,但并不投递。此时下游系统B仍然不知道该条消息的存在。消息中间件持久化成功后,便向系统A返回一个确认应答;系统A收到确认应答后,则可以开始处理任务A;任务A处理完成后,向消息中间件发送Commit请求。该请求发送完成后,对系统A而言,该事务的处理过程就结束了,此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失,从而消息中间件并不会向系统B投递这条消息,从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成,下文会介绍。消息中间件收到Commit指令后,便向系统B投递该消息,从而触发任务B的执行;当任务B执行完成后,系统B向消息中间件返回一个确认应答,告诉消息中间件该消息已经成功消费,此时,这个分布式事务完成。上述过程可以得出如下几个结论: 消息中间件扮演者分布式事务协调者的角色。 系统A完成任务A后,到任务B执行完成之间,会存在一定的时间差。在这个时间差内,整个系统处于数据不一致的状态,但这短暂的不一致性是可以接受的,因为经过短暂的时间后,系统又可以保持数据一致性,满足BASE理论。 上述过程中,如果任务A处理失败,那么需要进入回滚流程,如下图所示: title 若系统A在处理任务A时失败,那么就会向消息中间件发送Rollback请求。和发送Commit请求一样,系统A发完之后便可以认为回滚已经完成,它便可以去做其他的事情。消息中间件收到回滚请求后,直接将该消息丢弃,而不投递给系统B,从而不会触发系统B的任务B。此时系统又处于一致性状态,因为任务A和任务B都没有执行。 上面所介绍的Commit和Rollback都属于理想情况,但在实际系统中,Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候,消息中间件是如何保证数据一致性呢?——答案就是超时询问机制。 title 系统A除了实现正常的业务流程外,还需提供一个事务询问的接口,供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时,如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话,就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果: 提交 若获得的状态是“提交”,则将该消息投递给系统B。回滚 若获得的状态是“回滚”,则直接将条消息丢弃。处理中 若获得的状态是“处理中”,则继续等待。消息中间件的超时询问机制能够防止上游系统因在传输过程中丢失Commit/Rollback指令而导致的系统不一致情况,而且能降低上游系统的阻塞时间,上游系统只要发出Commit/Rollback指令后便可以处理其他任务,无需等待确认应答。而Commit/Rollback指令丢失的情况通过超时询问机制来弥补,这样大大降低上游系统的阻塞时间,提升系统的并发度。 下面来说一说消息投递过程的可靠性保证。 当上游系统执行完任务并向消息中间件提交了Commit指令后,便可以处理其他任务了,此时它可以认为事务已经完成,接下来消息中间件一定会保证消息被下游系统成功消费掉!那么这是怎么做到的呢?这由消息中间件的投递流程来保证。 消息中间件向下游系统投递完消息后便进入阻塞等待状态,下游系统便立即进行任务的处理,任务处理完成后便向消息中间件返回应答。消息中间件收到确认应答后便认为该事务处理完毕! 如果消息在投递过程中丢失,或消息的确认应答在返回途中丢失,那么消息中间件在等待确认应答超时之后就会重新投递,直到下游消费者返回消费成功响应为止。当然,一般消息中间件可以设置消息重试的次数和时间间隔,比如:当第一次投递失败后,每隔五分钟重试一次,一共重试3次。如果重试3次之后仍然投递失败,那么这条消息就需要人工干预。 title title 有的同学可能要问:消息投递失败后为什么不回滚消息,而是不断尝试重新投递? 这就涉及到整套分布式事务系统的实现成本问题。 我们知道,当系统A将向消息中间件发送Commit指令后,它便去做别的事情了。如果此时消息投递失败,需要回滚的话,就需要让系统A事先提供回滚接口,这无疑增加了额外的开发成本,业务系统的复杂度也将提高。对于一个业务系统的设计目标是,在保证性能的前提下,最大限度地降低系统复杂度,从而能够降低系统的运维成本。 不知大家是否发现,上游系统A向消息中间件提交Commit/Rollback消息采用的是异步方式,也就是当上游系统提交完消息后便可以去做别的事情,接下来提交、回滚就完全交给消息中间件来完成,并且完全信任消息中间件,认为它一定能正确地完成事务的提交或回滚。然而,消息中间件向下游系统投递消息的过程是同步的。也就是消息中间件将消息投递给下游系统后,它会阻塞等待,等下游系统成功处理完任务返回确认应答后才取消阻塞等待。为什么这两者在设计上是不一致的呢? 首先,上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道,用户体验尤为重要,因此这种异步通信方式能够极大程度地降低用户等待时间。此外,异步通信相对于同步通信而言,没有了长时间的阻塞等待,因此系统的并发性也大大增加。但异步通信可能会引起Commit/Rollback指令丢失的问题,这就由消息中间件的超时询问机制来弥补。 那么,消息中间件和下游系统之间为什么要采用同步通信呢? 异步能提升系统性能,但随之会增加系统复杂度;而同步虽然降低系统并发度,但实现成本较低。因此,在对并发度要求不是很高的情况下,或者服务器资源较为充裕的情况下,我们可以选择同步来降低系统的复杂度。 我们知道,消息中间件是一个独立于业务系统的第三方中间件,它不和任何业务系统产生直接的耦合,它也不和用户产生直接的关联,它一般部署在独立的服务器集群上,具有良好的可扩展性,所以不必太过于担心它的性能,如果处理速度无法满足我们的要求,可以增加机器来解决。而且,即使消息中间件处理速度有一定的延迟那也是可以接受的,因为前面所介绍的BASE理论就告诉我们了,我们追求的是最终一致性,而非实时一致性,因此消息中间件产生的时延导致事务短暂的不一致是可以接受的。 方案3:最大努力通知(定期校对)最大努力通知也被称为定期校对,其实在方案二中已经包含,这里再单独介绍,主要是为了知识体系的完整性。这种方案也需要消息中间件的参与,其过程如下: title 上游系统在完成任务后,向消息中间件同步地发送一条消息,确保消息中间件成功持久化这条消息,然后上游系统可以去做别的事情了;消息中间件收到消息后负责将该消息同步投递给相应的下游系统,并触发下游系统的任务执行;当下游系统处理成功后,向消息中间件反馈确认应答,消息中间件便可以将该条消息删除,从而该事务完成。上面是一个理想化的过程,但在实际场景中,往往会出现如下几种意外情况: 消息中间件向下游系统投递消息失败上游系统向消息中间件发送消息失败对于第一种情况,消息中间件具有重试机制,我们可以在消息中间件中设置消息的重试次数和重试时间间隔,对于网络不稳定导致的消息投递失败的情况,往往重试几次后消息便可以成功投递,如果超过了重试的上限仍然投递失败,那么消息中间件不再投递该消息,而是记录在失败消息表中,消息中间件需要提供失败消息的查询接口,下游系统会定期查询失败消息,并将其消费,这就是所谓的“定期校对”。 如果重复投递和定期校对都不能解决问题,往往是因为下游系统出现了严重的错误,此时就需要人工干预。 对于第二种情况,需要在上游系统中建立消息重发机制。可以在上游系统建立一张本地消息表,并将 任务处理过程 和 向本地消息表中插入消息 这两个步骤放在一个本地事务中完成。如果向本地消息表插入消息失败,那么就会触发回滚,之前的任务处理结果就会被取消。如果这量步都执行成功,那么该本地事务就完成了。接下来会有一个专门的消息发送者不断地发送本地消息表中的消息,如果发送失败它会返回重试。当然,也要给消息发送者设置重试的上限,一般而言,达到重试上限仍然发送失败,那就意味着消息中间件出现严重的问题,此时也只有人工干预才能解决问题。 对于不支持事务型消息的消息中间件,如果要实现分布式事务的话,就可以采用这种方式。它能够通过重试机制+定期校对实现分布式事务,但相比于第二种方案,它达到数据一致性的周期较长,而且还需要在上游系统中实现消息重试发布机制,以确保消息成功发布给消息中间件,这无疑增加了业务系统的开发成本,使得业务系统不够纯粹,并且这些额外的业务逻辑无疑会占用业务系统的硬件资源,从而影响性能。 因此,尽量选择支持事务型消息的消息中间件来实现分布式事务,如RocketMQ。 方案4:TCC(两阶段型、补偿型)TCC即为Try Confirm Cancel,它属于补偿型分布式事务。顾名思义,TCC实现分布式事务一共有三个步骤: Try:尝试待执行的业务 这个过程并未执行业务,只是完成所有业务的一致性检查,并预留好执行所需的全部资源Confirm:执行业务 这个过程真正开始执行业务,由于Try阶段已经完成了一致性检查,因此本过程直接执行,而不做任何检查。并且在执行的过程中,会使用到Try阶段预留的业务资源。Cancel:取消执行的业务 若业务执行失败,则进入Cancel阶段,它会释放所有占用的业务资源,并回滚Confirm阶段执行的操作。下面以一个转账的例子来解释下TCC实现分布式事务的过程。 假设用户A用他的账户余额给用户B发一个100元的红包,并且余额系统和红包系统是两个独立的系统。 Try 创建一条转账流水,并将流水的状态设为交易中将用户A的账户中扣除100元(预留业务资源)Try成功之后,便进入Confirm阶段Try过程发生任何异常,均进入Cancel阶段Confirm 向B用户的红包账户中增加100元将流水的状态设为交易已完成Confirm过程发生任何异常,均进入Cancel阶段Confirm过程执行成功,则该事务结束Cancel 将用户A的账户增加100元将流水的状态设为交易失败在传统事务机制中,业务逻辑的执行和事务的处理,是在不同的阶段由不同的部件来完成的:业务逻辑部分访问资源实现数据存储,其处理是由业务系统负责;事务处理部分通过协调资源管理器以实现事务管理,其处理由事务管理器来负责。二者没有太多交互的地方,所以,传统事务管理器的事务处理逻辑,仅需要着眼于事务完成(commit/rollback)阶段,而不必关注业务执行阶段。 TCC全局事务必须基于RM本地事务来实现全局事务TCC服务是由Try/Confirm/Cancel业务构成的, 其Try/Confirm/Cancel业务在执行时,会访问资源管理器(Resource Manager,下文简称RM)来存取数据。这些存取操作,必须要参与RM本地事务,以使其更改的数据要么都commit,要么都rollback。 这一点不难理解,考虑一下如下场景: title 假设图中的服务B没有基于RM本地事务(以RDBS为例,可通过设置auto-commit为true来模拟),那么一旦[B:Try]操作中途执行失败,TCC事务框架后续决定回滚全局事务时,该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB:假设[B:Try]业务有5个写库操作,[B:Cancel]业务则需要逐个判断这5个操作是否生效,并将生效的操作执行反向操作。 不幸的是,由于[B:Cancel]业务也有n(0<=n<=5)个反向的写库操作,此时一旦[B:Cancel]也中途出错,则后续的[B:Cancel]执行任务更加繁重。因为,相比第一次[B:Cancel]操作,后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n(0<=n<=5)个写库中哪几个已经执行、哪几个还没有执行,这就涉及到了幂等性问题。而对幂等性的保障,又很可能还需要涉及额外的写库操作,该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。可想而知,如果不基于RM本地事务,TCC事务框架是无法有效的管理TCC全局事务的。 反之,基于RM本地事务的TCC事务,这种情况则会很容易处理:[B:Try]操作中途执行失败,TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时,在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下,根本无需执行[B:Cancel]操作。 换句话说,基于RM本地事务实现TCC事务框架时,一个TCC型服务的cancel业务要么执行,要么不执行,不需要考虑部分执行的情况。 TCC事务框架应该提供Confirm/Cancel服务的幂等性保障一般认为,服务的幂等性,是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求,二者具有相同的副作用。 在TCC事务模型中,Confirm/Cancel业务可能会被重复调用,其原因很多。比如,全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时,可能会出现如网络中断的故障而使得全局事务不能完成。因此,故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务,这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。 既然Confirm/Cancel业务可能会被多次调用,就需要保障其幂等性。 那么,应该由TCC事务框架来提供幂等性保障?还是应该由业务系统自行来保障幂等性呢? 个人认为,应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话,那么由业务系统来负责也是可以的;然而,这是一类公共问题,毫无疑问,所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决;而且,考虑一下由业务系统来负责幂等性需要考虑的问题,就会发现,这无疑增大了业务系统的复杂度。

1210119897362579 2019-12-02 00:14:25 0 浏览量 回答数 0

问题

使用HTTPDNS时该如何API访问

猫饭先生 2019-12-01 21:51:27 1353 浏览量 回答数 0

问题

支付宝的性能测试

云效平台 2019-12-01 21:47:13 5472 浏览量 回答数 1

问题

小试用,大学问菜鸟也要知道如何去试用之云服务器测评

universitylife 2019-12-01 21:31:33 15660 浏览量 回答数 10

问题

小试用,大学问菜鸟也要知道如何去试用之云服务器测评

universitylife 2019-12-01 21:15:34 33359 浏览量 回答数 19

问题

Nginx性能为什么如此吊

小柒2012 2019-12-01 21:20:47 15038 浏览量 回答数 3

问题

【推荐】Windows Update补丁更新失败应该如何处理

boxti 2019-12-01 22:07:16 1737 浏览量 回答数 0

问题

云计算之路-黎明前的黑暗:20130424网站故障经过

cnblogs 2019-12-01 21:13:14 11839 浏览量 回答数 12

回答

adb介绍: Android Debug Bridge(安卓调试桥) tools。它就是一个命令行窗口,用于通过电脑端与模拟器或者是设备之间的交互。 ADB是一个C/S架构的应用程序,由三部分组成: 运行在pc端的adb client: 命令行程序”adb”用于从shell或脚本中运行adb命令。首先,“adb”程序尝试定位主机上的ADB服务器,如果找不到ADB服务器,“adb”程序自动启动一个ADB服务器。接下来,当设备的adbd和pc端的adb server建立连接后,adb client就可以向ADB servcer发送服务请求; 运行在pc端的adb server: ADB Server是运行在主机上的一个后台进程。它的作用在于检测USB端口感知设备的连接和拔除,以及模拟器实例的启动或停止,ADB Server还需要将adb client的请求通过usb或者tcp的方式发送到对应的adbd上; 运行在设备端的常驻进程adb demon (adbd): 程序“adbd”作为一个后台进程在Android设备或模拟器系统中运行。它的作用是连接ADB服务器,并且为运行在主机上的客户端提供一些服务。 adb下载及安装: 一共有两种方法: 首先第一种就是最简单的方法,只下载adb压缩包去解压即可:链接:https://pan.baidu.com/s/1SKu24yyShwg16lyIupO5VA 提取码:ih0i (备注:如果下载放入到D盘去解压,打开dos窗口那么就要进入到D盘,然后再去执行adb命令,输入adb查看它是否安装成功) 第二种方法前提是已安装了Android Studio,它本身带有adb命令,如果配置好的Android Studio 一般都是可以直接调用adb命令的;如果不行,找到adb在SDK里的绝对路径,放入环境变量path中(绝对路径不带入adb.exe) 然后输入adb version 查看版本 可以看出是否安装成功,如下就已经成功了。 启动 adb server 命令:adb start-server 停止 adb server 命令:adb kill-server 查询已连接设备/模拟器:adb devices 该命令经常出现以下问题: offline —— 表示设备未连接成功或无响应; device —— 设备已连接; no device —— 没有设备/模拟器连接; List of devices attached 设备/模拟器未连接到 adb 或无响应 USB连接: 在手机“设置”-“关于手机”连续点击“版本号”7 次,可以进入到开发者模式;然后可以到“设置”-“开发者选项”-“调试”里打开USB调试以及允许ADB的一些权限;连接时手机会弹出“允许HiSuite通过HDB连接设备”点击允许/接受即可; 驱动也是必须安装的,可以用豌豆荚,或者是手机商家提供的手机助手,点进去驱动器安装即可(部分电脑双击无法直接进入到驱动器里,可以使用右键找到进入点击即可) 再次输入adb devices验证是否连接成功,连接成功即如下图: 也可以进行无线连接,其中非root权限也需借助USB线进行操作,完成后即可断开USB线;root用户可以进行无线连接,具体步骤可以参考网上资源。 **查看是否有root权限:**输入adb shell,然后输入su KaTeX parse error: Expected 'EOF', got '#' at position 5: 如果变为#̲则成功,如果仍为则未有root权限;恢复命令:adb unroot 查看应用列表: 查看所有应用列表:adb shell pm list packages 查看系统应用列表:adb shell pm list packages -s 查看第三方应用列表:adb shell pm list packages -3: 安装apk:adb install “-lrtsdg” “path_to_apk” “-lrtsdg”: -l:将应用安装到保护目录 /mnt/asec; -r:允许覆盖安装; -t:允许安装 AndroidManifest.xml 里 application 指定 android:testOnly=“true” 的应用; -s:将应用安装到 sdcard; -d:允许降级覆盖安装; -g:授予所有运行时权限; path_to_apk:apk的绝对路径。 示例安装淘宝apk:adb install -l /data/local/tmp/taobao.apk 卸载apk:adb uninstall -k “packagename” “packagename”:表示应用的包名,以下相同; -k 参数可选,表示卸载应用但保留数据和缓存目录。 示例卸载 手机淘宝:adb uninstall com.taobao.taobao 清除应用数据与缓存命令:adb shell pm clear “packagename” 相当于在设置里的应用信息界面点击「清除缓存」和「清除数据」。 示例:adb shell pm clear com.taobao.taobao 表示清除 手机淘宝数据和缓存。 Android四大组件有Activity,Service服务,Content Provider内容提供,BroadcastReceiver广播接收器,具体不做多讲,常用的有以下: 查看前台 Activity命令:adb shell dumpsys activity activities | grep mFocusedActivity 查看正在运行的 Services命令:adb shell dumpsys activity services “packagename” 其中参数不是必须的,指定 “packagename” 表示查看与某个包名相关的 Services,不指定表示查看所有 Services。 查看应用详细信息命令:adb shell dumpsys package “packagename” 调起 Activity命令格式:adb shell am start [options] 例如:adb shell am start -n com.tencent.mm/.ui.LauncherUI表示调起微信主界面 调起 Service命令格式:adb shell am startservice [options] 例如:adb shell am startservice -n com.tencent.mm/.plugin.accountsync.model.AccountAuthenticatorService 表示调起微信的某 Service。 强制停止应用命令:adb shell am force-stop “packagename” 例如强制停止淘宝:adb shell am force-stop com.taobao.taobao 模拟按键/输入:adb shell input keyevent keycode 不同的 keycode有不同的功能: keycode 含义 3 HOME 键 4 返回键 5 打开拨号应用 6 挂断电话 26 电源键 27 拍照(需要在相机应用里) 61 Tab键 64 打开浏览器 67 退格键 80 拍照对焦键 82 菜单键 85 播放/暂停 86 停止播放 92 向上翻页键 93 向下翻页键 111 ESC键 112 删除键 122 移动光标到行首或列表顶部 123 移动光标到行末或列表底部 124 插入键 164 静音 176 打开系统设置 207 打开联系人 208 打开日历 209 打开音乐 220 降低屏幕亮度 221 提高屏幕亮度 223 系统休眠 224 点亮屏幕 224 点亮屏幕 224 点亮屏幕 231 打开语音助手 276 如果没有 wakelock 则让系统休眠 滑动解锁:如果锁屏没有密码,是通过滑动手势解锁,那么可以通过 input swipe 来解锁。 命令:adb shell input swipe 300 1000 300 500 (其中参数 300 1000 300 500 分别表示起始点x坐标 起始点y坐标 结束点x坐标 结束点y坐标。) 输入文本:在焦点处于某文本框时,可以通过 input 命令来输入文本。 命令:adb shell input text *** (***即为输入内容) 打印日志: Android 的日志分为如下几个优先级(priority): V —— Verbose(最低,输出得最多) D —— Debug I —— Info W —— Warning E —— Error F—— Fatal S —— Silent(最高,啥也不输出) 按某级别过滤日志则会将该级别及以上的日志输出。 比如,命令:adb logcat *:W 会将 Warning、Error、Fatal 和 Silent 日志输出。 (注: 在 macOS 下需要给 :W 这样以 作为 tag 的参数加双引号,如 adb logcat “:W”,不然会报错 no matches found: :W。) adb logcat 打印当前设备上所有日志 adb logcat :W 过滤打印严重级别W及以上的日志 adb logcat l findstr ***> F:\log.txt 把仅含的日志保存到F盘的log.txt文件中 adb logcat -c 清除屏幕上的日志记录 adb logcat -c && adb logcat -s ActivityManager l grep "Displayed” 客户端程序启动时间获取日志 adb logcat > F:\log.txt 打印当前设备上所有日志保存到F盘的log.txt文件中 adb logcat l findstr *** 打印过滤仅含的日志 adb logcat l findstr ***> F:\log.txt 把仅含**的日志保存到F盘的log.txt文件中 按 tag 和级别过滤日志:命令:adb logcat ActivityManager:I MyApp:D *:S 表示输出 tag ActivityManager 的 Info 以上级别日志,输出 tag MyApp 的 Debug 以上级别日志,及其它 tag 的 Silent 级别日志(即屏蔽其它 tag 日志)。 日志格式可以用:adb logcat -v 选项指定日志输出格式。 日志支持按以下几种 :默认格式brief、process、tag、raw、time、long 指定格式可与上面的过滤同时使用。比如:adb logcat -v long ActivityManager:I *:S 清空日志:adb logcat -c 内核日志:adb shell dmesg 查看设备情况: 查看设备信息型号命令:adb shell getprop ro.product.model 电池状况命令:adb shell dumpsys battery 屏幕分辨率命令:adb shell wm size 如果使用命令修改过,那输出可能是: Physical size: 1080x1920 Override size: 480x1024 表明设备的屏幕分辨率原本是 1080px * 1920px,当前被修改为 480px * 1024px。 屏幕密度命令:adb shell wm density 如果使用命令修改过,那输出可能是: Physical density: 480 Override density: 160 表明设备的屏幕密度原来是 480dpi,当前被修改为 160dpi。 显示屏参数:adb shell dumpsys window displays 输出示例: WINDOW MANAGER DISPLAY CONTENTS (dumpsys window displays) Display: mDisplayId=0 init=1080x1920 420dpi cur=1080x1920 app=1080x1794 rng=1080x1017-1810x1731 deferred=false layoutNeeded=false 其中 mDisplayId 为 显示屏编号,init 是初始分辨率和屏幕密度,app 的高度比 init 里的要小,表示屏幕底部有虚拟按键,高度为 1920 - 1794 = 126px 合 42dp。 android_id查看命令:adb shell settings get secure android_id 查看Android 系统版本:adb shell getprop ro.build.version.release 查看设备ip地址:adb shell ifconfig | grep Mask或者adb shell netcfg 查看CPU 信息命令:adb shell cat /proc/cpuinfo 查看内存信息命令:adb shell cat /proc/meminfo 更多硬件与系统属性: 设备的更多硬件与系统属性可以通过如下命令查看:adb shell cat /system/build.prop 单独查看某一硬件或系统属性:adb shell getprop <属性名> 属性名 含义 ro.build.version.sdk SDK 版本 ro.build.version.release Android 系统版本 ro.product.model 型号 ro.product.brand 品牌 ro.product.name 设备名 ro.product.board 处理器型号 persist.sys.isUsbOtgEnabled 是否支持 OTG dalvik.vm.heapsize 每个应用程序的内存上限 ro.sf.lcd_density 屏幕密度 rro.build.version.security_patch Android 安全补丁程序级别 修改设置: 修改设置之后,运行恢复命令有可能显示仍然不太正常,可以运行 adb reboot 重启设备,或手动重启。 修改设置的原理主要是通过 settings 命令修改 /data/data/com.android.providers.settings/databases/settings.db 里存放的设置值。 修改分辨率命令:adb shell wm size 480x1024 恢复原分辨率命令:adb shell wm size reset 修改屏幕密度命令:adb shell wm density 160 表示将屏幕密度修改为 160dpi;恢复原屏幕密度命令:adb shell wm density reset 修改显示区域命令:adb shell wm overscan 0,0,0,200 四个数字分别表示距离左、上、右、下边缘的留白像素,以上命令表示将屏幕底部 200px 留白。恢复原显示区域命令:adb shell wm overscan reset 关闭 USB 调试模式命令:adb shell settings put global adb_enabled 0 需要手动恢复:「设置」-「开发者选项」-「Android 调试」 状态栏和导航栏的显示隐藏:adb shell settings put global policy_control 可由如下几种键及其对应的值组成,格式为 =:=。 key 含义 immersive.full 同时隐藏 immersive.status 隐藏状态栏 immersive.navigation 隐藏导航栏 immersive.preconfirms ? 这些键对应的值可则如下值用逗号组合: value 含义 apps 所有应用 * 所有界面 packagename 指定应用 -packagename 排除指定应用 举例:adb shell settings put global policy_control immersive.full=* 表示设置在所有界面下都同时隐藏状态栏和导航栏。 举例:adb shell settings put global policy_control immersive.status=com.package1,com.package2:immersive.navigation=apps,-com.package3 表示设置在包名为 com.package1 和 com.package2 的应用里隐藏状态栏,在除了包名为 com.package3 的所有应用里隐藏导航栏。 恢复正常模式:adb shell settings put global policy_control null 实用功能: 截图保存到电脑:adb exec-out screencap -p > sc.png 然后将 png 文件导出到电脑:adb pull /sdcard/sc.png 录制屏幕:录制屏幕以 mp4 格式保存到 /sdcard:adb shell screenrecord /sdcard/filename.mp4 需要停止时按 Ctrl-C,默认录制时间和最长录制时间都是 180 秒。 如果需要导出到电脑:adb pull /sdcard/filename.mp4 挂载、查看连接过的 WiFi 密码、开启/关闭 WiFi、设置系统日期和时间都需要root权限,不做多说。 使用 Monkey 进行压力测试:Monkey 可以生成伪随机用户事件来模拟单击、触摸、手势等操作,可以对正在开发中的程序进行随机压力测试。 简单用法:adb shell monkey -p < packagename > -v 500 表示向 指定的应用程序发送 500 个伪随机事件。 查看进程:adb shell ps 查看实时资源占用情况:adb shell top 查看进程 UID:adb shell dumpsys package | grep userId=

问问小秘 2020-04-29 15:55:55 0 浏览量 回答数 0

回答

合理的监控设置能极大减轻云上业务的运维成本和压力。设置合理的监控可以让您实时了解系统业务的运行情况,并能帮助您提前发现问题,避免可能会出现的业务故障。同时,告警机制能让您在故障发生后第一时间发现问题,缩短故障处理时间,以便尽快恢复业务。 前提条件 在开始设置云监控前,您需要完成以下操作: 已注册阿里云账号。如还未注册,请先完成账号注册。 检查ECS监控插件运行情况,确保监控信息能够正常采集。如果安装失败需要手动安装,请参见云监控插件安装指南。 提前添加报警联系人和联系组,建议设置至少2人以上的联系人,互为主备,以便及时响应监控告警。监控选项的设定,具体请参见报警联系人/报警联系组管理和云服务资源使用概览和报警概览。 背景信息 利用云监控的Dashboard功能,给您业务系统的云资源设置一个全局监控总览,可随时检查整个业务系统资源的健康状态。 为了更好地监控大屏展示效果,这里将ECS的CPU、内存、磁盘的使用率单独分组展示;将RDS的四项指标分两组展示。 指标展示效果图 本文中以一个网站为示例,介绍如何配置使用云监控。本示例中,使用了ECS、RDS、OSS和负载均衡。架构图 设置报警阈值和报警规则 建议您根据实际业务情况设置各项监控指标的报警阈值。阈值太低会频繁触发报警,影响监控服务体验。阈值太高,在触发阈值后没有足够的预留时间来响应和处理告警。 以CPU使用率为例,因为需要给服务器预留部分处理性能保障服务器正常运行,所以建议您将CPU告警阈值设置为70%,连续三次超过阈值后开始报警。设置CPU告警阈值 如果您还需要设置其他资源的报警规则,单击添加报警规则,继续设置内存或磁盘的报警规则和报警通知人。示例如下: 设置RDS监控 建议将RDS的CPU使用率报警阈值设置为70%,连续三次超过阈值后开始报警。您可以根据实际情况设置硬盘使用率、IOPS使用率、连接数等其他监控项。监控项的详细介绍请参见监控项。 设置RDS监控 设置负载均衡监控 为了更好使用负载均衡的云监控服务,您需要先开启负载均衡的健康检查,将负载均衡带宽值的70%作为告警阈值,如下图所示。设置负载均衡监控 设置进程监控 对于常见的web应用,设置进程监控,不仅可以实时监控应用进程的运行情况,还有助于排查处理故障,下图是Java进程的相关监控示例。具体操作请参见添加进程监控。设置进程监控 设置站点监控 在云服务器外层的监控服务,站点监控主要用于模拟真实用户访问情况,实时测试业务可用性,有助于排查处理故障。 设置站点监控 如果以上监控选项不能满足您的实际业务监控需求,您可以使用自定义监控。详情请参见自定义监控概览。

1934890530796658 2020-03-25 18:41:25 0 浏览量 回答数 0

回答

本文详细列出了从云服务器ECS(Linux)访问SMB文件系统时的常见问题、原因与解决方案。 无法挂载SMB文件系统 通常原因: 使用了低版本或者不兼容的Linux操作系统版本,SMB文件系统支持如下的Linux分发版本。 CentOS 7.6 64bit (3.10.0-957.5.1.el7.x86_64) Ubuntu 18.04 64bit(4.15.0-48-generic) Debian 9.9 64bit(4.9.0-9-amd64) Suse Enterprise Server 12 SP2 64bit(4.4.74-92.35-default) OpenSUSE 42.3 64bit(4.4.90-28-default) Aliyun Linux(4.19.34-11.al7.x86_64) CoreOS(4.19.43-coreos VersionID=2079.4.0) 客户端上未安装CIFS挂载工具(cifs-utils)或者mount.cifs不在PATH指定的命令搜寻目录中。 云服务器ECS(Linux)和SMB文件系统的网络不通。 云服务器ECS(Linux)和SMB文件系统不属于同一个阿里云用户。 云服务器ECS(Linux)和SMB文件系统不在同一个阿里云地域(region)。 云服务器ECS(Linux)和SMB文件系统不处于可连通的网络(VPC或经典网络)中。 说明 NAS支持本地挂载,如果Linux客户端在用户IDC中,可能是该IDC和SMB文件系统所处的的网络(VPC或经典网络)没有通过阿里云高速通道连接成功。 SMB文件系统的白名单设置不允许云服务器ECS(Linux)连接。 云服务器ECS(Linux)防火墙设置为不允许访问SMB文件系统的IP地址或445端口。 云服务器ECS(Linux)试图通过不受支持的TCP端口连接,现在SMB只支持445端口。 说明 您可以通过ping 和 telnet 445检查连通性。 如果端口445未打开,请在目标ECS实例的安全组中添加关于端口445的安全组规则,详情请参见添加安全组规则。 云服务器ECS(Linux)管理员没有root权限或者没有被设置为有mount命令的sudo权限。 挂载时使用的文件系统类型不是cifs。 挂载时使用的vers选项不是2.0。 挂载时没有指定guest方式挂载。 挂载时指定的uid、gid、dir_mode或者file_mode不正确。 挂载的目标目录的SELINUX设置不正确。 云服务器ECS(Linux)挂载连接数太多,超过了单文件系统挂载上限(1000)。这个在容器场景较容易发生。 解决方案: 参见通过云服务器ECS(Linux)访问SMB文件系统及上述可能原因,自行排查。 检查/var/log/messages和dmesg输出,自行排查。 联系阿里云NAS团队排查。 同时请提供Linux版本信息、具体挂载命令、/var/log/messages和dmesg输出。 文件系统性能不佳 如果SMB文件系统性能不佳,您可以从以下方面进行排查。 原因1:SMB单个文件系统的吞吐能力与存储量是相联系的。单文件系统的吞吐(读+写)上限与当前存储量呈线性关系。 解决方案:使用fio工具来测试SMB文件系统性能,详情请参见NAS性能测试。 原因2:云服务器ECS(Linux)的单机网络带宽较小。 解决方案:使用多个云服务器ECS(Linux)达到文件系统的总体预期性能。 原因3:禁用了SMB文件系统的客户端缓存。 解决方案:在挂载SMB文件系统时,cache=none表示禁用缓存,默认或者cache=strict表示使用缓存;您可以通过sudo mount | grep cifs命令检查所用的选项是否正确。 原因4:没有设置合适的SMB客户端的I/O大小。 解决方案:根据业务需求调整rsize/wsize,缺省值:1048576。 原因5:云服务器ECS(Linux)的CPU或内存的规格过低,或被其它业务占有过多。 解决方案:选择合适的云服务器ECS(Linux)规格、检查系统其它应用资源,确保系统满足CPU和内存要求。 您可以通过top命令检查系统cpu、mem使用情况。 原因6:挂载时使用了atime选项。 解决方案:如果您的业务不是对文件的访问时间(atime)极为敏感请不要在挂载时使用atime选项。 原因7:遇到大量小文件频繁读、少量写但需要写时通知的WebServer场景。 解决方案:您可以在客户端配置该WebServer(如Apache)产品特定的缓存机制或者联系阿里云NAS团队开通WebServer场景加速功能。 迁移/复制文件系统中的文件时速度缓慢 如果已经排除了上述文件系统本身的性能问题,则可能原因是您没有使用并发式迁移/复制文件。您可以通过以下开源工具进行迁移/复制。 GNU Parallel 说明 根据系统资源,选择合适的线程数。 示例:find * -type | parallel --will-cite -j 10 cp {} /mnt/smb/ & Fpart Fpsync multi 访问文件系统时,报错:Permission denied 原因:Linux管理员在挂载时使用了不正确的uid、gid、file_mode、dir_mode。 解决方案:检查是否正确设置了uid、gid、file_mode、dir_mode等挂载选项,详情请参见通过云服务器ECS(Linux)访问SMB文件系统。 文件名大小写变更 SMB文件系统对文件名大小写不敏感,和Windows系统保持一致。但在文件名大小写改名这个场景暂时没有支持。 您可以先从大写文件名改成一个其它名字的文件,再改成小写文件名,反之亦然。 不能改变文件owner,文件/目录mode 现在暂时不支持动态改变,只能在挂载时指定,详情请参见通过云服务器ECS(Linux)访问SMB文件系统。 并发访问同一文件时,客户端出现无响应35s现象 原因:当前Linux SMB 内核驱动有缺陷,会造成在使用vers=2.1 or 3.0挂载时,在某些并发场景不能发出服务器端期待的SMB BreakAck协议包,导致服务器端无响应35s。 解决方案:挂载文件系统时,使用vers=2.0 协议。 不能使用ACL 暂时不支持使用ACL,如果您有强烈需求,请联系阿里云NAS团队。 SMB挂载点无响应 原因:在Linux内核为3.10.0-514之前的Linux分发版中,SMB内核驱动在并发场景有时会crash(内核stack如下所示),导致挂载点无法被访问。内核日志中有如下类似信息: ... [ ] cifs_oplock_break+0x1f1/0x270 [cifs] [ ] process_one_work+0x17a/0x440 [ ] rescuer_thread+0x294/0x3c0 ... 解决方案: 使用cache=none重新挂载(性能会受影响)。 升级云服务器ECS(Linux)的操作系统。

1934890530796658 2020-03-31 22:23:33 0 浏览量 回答数 0

问题

ECS Windows 系统 SVCHOST.EXE进程占用资源(CPU,内存)较高的处理是什么

boxti 2019-12-01 22:06:56 2057 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站