• 关于

    时间数据库常见问题及解决方法

    的搜索结果

回答

详细解答可以参考官方帮助文档调用Access程序问题(最常见)原因:Access数据库大小超过30M,频繁调用时耗用系统资源。解决方法:将数据库大小压缩到30M以内,或者升级到 SQL Server 数据库。SQL Server是基于客户/服务器结构,这意味着服务器不用再执行客户端的任务,而Access并不是基于客户/服务器结构,除了处理数据库任务外,其还必须在各个客户端活动间划分处理器时间,因此也会造成系统负载非常大,严重时还会导致ASP进程死锁,影响所有用户访问ASP页面。  ASP、Perl、cgi、SqlServer程序问题原因:程序BUG导致解决方法: 注意优化程序,在处理循环、跳转等语句时尤其小心,注意释放资源。 优化数据库,避免使用全部查询(select * 之类)。 对于网上的免费程序,不能拿来就用,需要测试其性能及安全问题,尤其是计算器、论坛程序。  
2019-12-01 23:21:11 0 浏览量 回答数 0

问题

【教程免费下载】R语言数据分析

前  言 自20多年前发源于学术界以来,R语言已经成为统计分析的通用语言,活跃于众多产业领域。目前,越来越多的商业项目开始使用R,兼之R用户开发了数以千计易于上手的开发包&#x...
玄学酱 2019-12-01 22:07:40 1232 浏览量 回答数 0

问题

阿里云大数据专业认证考试形式和试卷结构是什么?

阿里云大数据专业认证(ACP级-Alibaba Cloud Certified Professional)考试形式和试卷结构 一、试卷满分及考试时间 试卷满分为100分,考试时间为120...
nicenelly 2019-12-01 21:24:01 1124 浏览量 回答数 0

Quick BI 数据可视化分析平台

2020年入选全球Gartner ABI魔力象限,为中国首个且唯一入选BI产品

问题

阿里云大数据专业认证考试形式和试卷结构是什么?

阿里云大数据专业认证(ACP级-Alibaba Cloud Certified Professional)考试形式和试卷结构 一、试卷满分及考试时间 试卷满分为100分,考试时间为120...
nicenelly 2019-12-01 21:06:16 1447 浏览量 回答数 0

回答

在工程实践上,为了保障系统的可用性,互联网系统大多将强一致性需求转换成最终一致性的需求,并通过系统执行幂等性的保证,保证数据的最终一致性。但在电商等场景中,对于数据一致性的解决方法和常见的互联网系统(如 MySQL 主从同步)又有一定区别,分成以下 6 种解决方案。(一)规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说,则可以将服务 A、B、C 整合为一个服务 D 给业务,这个服务 D 再通过转换为本地事务的方式,比如服务 D 包含本地服务和服务 E,而服务 E 是本地服务 A ~ C 的整合。优点:解决(规避)了分布式事务。缺点:显而易见,把本来规划拆分好的业务,又耦合到了一起,业务职责不清晰,不利于维护。由于这个方法存在明显缺点,通常不建议使用。(二)经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因,如果接口不能保证幂等性,数据的唯一性将很难保证。eBay 方式的主要思路如下。Base:一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章,是一篇解释 BASE 原则,或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择,那么如何实现可用性呢?答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子:如果将用户分区在 5 个数据库服务器上,BASE 设计鼓励类似的处理方式,一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法,不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景,如果产生了一笔交易,需要在交易表增加记录,同时还要修改用户表的金额。这两个表属于不同的远程服务,所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法,将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题,达到多次重试的幂等性,增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法,在第一阶段,通过本地的数据库的事务保障,增加了 transaction 表及消息队列 。在第二阶段,分别读出消息队列(但不删除),通过判断更新记录表 updates_applied 来检测相关记录是否被执行,未被执行的记录会修改 user 表,然后增加一条操作记录到 updates_applied,事务执行成功之后再删除队列。通过以上方法,达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。(三)去哪儿网分布式事务方案随着业务规模不断地扩大,电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里,现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢?最开始的单体应用所有功能都在一起,存储也在一起。比如运营要取消某个订单,那直接去更新订单表状态,然后更新库存表就 ok 了。因为是单体应用,库在一起,这些都可以在一个事务里,由关系数据库来保证一致性。但拆分之后就不同了,不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库,而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了,而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过,使用异步消息 Consumer 端需要实现幂等。幂等有两种方式,一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成,如果当前状态是支付完成,则再收到一个支付成功的消息则说明消息重复了,直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等,则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库,发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出,而是向消息库插入一条消息记录,然后在事务提交的时候再异步将消息发出,发送消息如果成功则将消息库里的消息删除,如果遇到消息队列服务异常或网络问题,消息没有成功发出那么消息就留在这里了,会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式,事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似,每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B,C。A 本地事务成功的时候更新本地事务记录状态,B 和 C 同样。如果有一次 A 调用 B 失败了,这个失败可能是 B 真的失败了,也可能是调用超时,实际 B 成功。则由一个中心服务对比三方的事务记录表,做一个最终决定。假设现在三方的事务记录是 A 成功,B 失败,C 成功。那么最终决定有两种方式,根据具体场景:重试 B,直到 B 成功,事务记录表里记录了各项调用参数等信息;执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明:比如 B 是扣库存服务,在第一次调用的时候因为某种原因失败了,但是重试的时候库存已经变为 0,无法重试成功,这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库,会对业务侵入,业务还要关心这个库,是否一个合理的设计?实际上可以依靠运维的手段来简化开发的侵入,我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库,通过框架层(消息的客户端或事务 RPC 框架)透明的在背后操作这个库,业务开发人员只需要关心自己的业务逻辑,不需要直接访问这个库。总结起来,其实两种方式的根本原理是类似的,也就是将分布式事务转换为多个本地事务,然后依靠重试等方式达到最终一致性。(四)蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点,每个功能点都可以有多个实现(具体的实现之间有组合/互斥关系)。把各个功能点按照一定流程串起来,就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢?比如锁定优惠券服务调用超时了,不能确定到底有没有锁券成功,该如何处理?再比如锁券成功了,但是扣减库存失败了,该如何处理?方案选型服务依赖过多,会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务,9 个都执行成功了,最后一个执行失败了,那么是不是前面 9 个都要回滚掉?这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下,对于非实时、非强一致性的关联业务写入,在本地事务执行成功后,我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功;且消息通知后,接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决;后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性,所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦,通过订阅方消费 MQ 消息时的 ACK 机制,保证消息一定消费成功,达到最终一致性。由于消息可能会被重发,消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中,锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致,乍一看,必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升;在电商领域,绝对的强一致是过于理想化的,我们可以选择准实时的最终一致性。我们在交易创建流程中,首先创建一个不可见订单,然后在同步调用锁券和扣减库存时,针对调用异常(失败或者超时),发出废单消息到MQ。如果消息发送失败,本地会做时间阶梯式的异步重试;优惠券系统和库存系统收到消息后,会进行判断是否需要做业务回滚,这样就准实时地保证了多个本地事务的最终一致性。(五)支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案,由支付宝在 2PC 的基础上改进而来。主要思路如下,大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架,用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分,前者是一个嵌入客户端应用的 JAR 包,主要负责事务数据的写入和处理;后者是一个独立的系统,主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下,ACID 模型能有效保障数据的完整性,但是在大规模分布式环境下,一个业务往往会跨越多个数据库,如何保证这多个数据库之间的数据一致性,需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题,但是 2PC 是反可伸缩模式,也就是说,在事务处理过程中,参与者需要一直持有资源直到整个分布式事务结束。这样,当业务规模达到千万级以上时,2PC 的局限性就越来越明显,系统可伸缩性会变得很差。基于此,我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案,这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求,其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说,DTS 框架有如下特性:最终一致:事务处理过程中,会有短暂不一致的情况,但通过恢复系统,可以让事务的数据达到最终一致的目标。协议简单:DTS 定义了类似 2PC 的标准两阶段接口,业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关:在 SOA 架构下,一个或多个 DB 操作往往被包装成一个一个的 Service,Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上,与底层协议无关。与底层事务实现无关: DTS 是一个抽象的基于 Service 层的概念,与底层事务实现无关,也就是说在 DTS 的范围内,无论是关系型数据库 MySQL,Oracle,还是 KV 存储 MemCache,或者列存数据库 HBase,只要将对其的操作包装成 DTS 的参与者,就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在活动提交时确认所有的两阶段事务的 confirm 操作,在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较,没有单独的 Prepare 阶段,降低协议成本。系统故障容忍度高,恢复简单(六)农信网数据一致性方案电商业务公司的支付部门,通过接入其它第三方支付系统来提供支付服务给业务部门,支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说,电商部门的订单支付,需要调用支付平台的支付接口来处理订单;同时需要调用积分中心的接口,按照业务规则,给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性,也就是支付成功必须加积分。我们采用的方式是同步调用,首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付,由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分,再调用支付平台进行支付处理,如果处理失败,catch 方法调用积分平台的回撤方法,将本次处理的积分订单回撤。用户信息变更公司的用户信息,统一由用户中心维护,而用户信息的变更需要同步给各业务子系统,业务子系统再根据变更内容,处理各自业务。用户中心作为 MQ 的 producer,添加通知给 MQ。APP Server 订阅该消息,同步本地数据信息,再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制,目前主要使用 ActiveMQ,基于 Virtual Topic 的订阅方式,保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多,特别是我们基于消息、日志的最终一致性方案,需要考虑消息的积压、消费情况、监控、报警等。
小川游鱼 2019-12-02 01:46:40 0 浏览量 回答数 0

问题

【精品问答】PHP常见面试题50问(附答案)

PHP常见面试题50问 1.什么是面向对象? 2.面向对象主要特征是什么? 3.SESSION 与 COOKIE的区别是什么,从协议,产生的原因与作用说明? 4.HTTP 状态中302...
珍宝珠 2019-12-01 21:59:27 1373 浏览量 回答数 1

问题

立足GitHub学编程:13个不容错过的Java项目

GitHub可谓一座程序开发的大宝库,有些素材值得fork,有些则能帮助我们改进自有代码或者学习编程技能。无论如何,开发工作当中我们几乎不可能绕得开GitHub。 下面,我们将一同分...
技术小菜鸟 2019-12-01 21:48:13 2674 浏览量 回答数 1

问题

MaxCompute常见问题:MaxCompute 其他使用问题

mapjoin中大表和小表可以互换位置吗?MaxCompute 运行报错:OpenJDK 64-Bit Server VM warning: Insufficient space for shared memor...
行者武松 2019-12-01 22:09:48 1989 浏览量 回答数 1

问题

编辑器测试

PHP常见面试题50问 1.什么是面向对象? 2.面向对象主要特征是什么? 3.SESSION 与 COOKIE的区别是什么,从协议,产生的原因与作用说明? 4.HTTP 状态中302...
养狐狸的猫 2019-12-01 22:01:10 72 浏览量 回答数 0

问题

服务器出现宕机可能的原因及解决方法

[font=-apple-system, "]服务器宕机是指服务器因为某些原因而导致服务器无法运转,造成网络无法正常使用。 对于网站来说,服务器宕机所造成影响很大,它不但造成访客无妨...
dd防护专家 2019-12-01 21:24:52 1336 浏览量 回答数 0

问题

该来的终于来了:“第一起”基于 IPv6 的 DDoS 攻击

作者介绍 杨彪,蚂蚁金服技术专家,《分布式服务架构:原理、设计与实战》和《可伸缩服务架构:框架与中间件》作者。近10年互联网和游戏行业工作经验,曾在酷我音乐盒、人人游戏...
驻云科技 2019-12-01 21:44:35 4186 浏览量 回答数 1

回答

回 2楼(zc_0101) 的帖子 您好,       您的问题非常好,SQL SERVER提供了很多关于I/O压力的性能计数器,请选择性能计算器PhysicalDisk(LogicalDisk),根据我们的经验,如下指标的阈值可以帮助你判断IO是否存在压力: 1.  % Disk Time :这个是磁盘时间百分比,这个平均值应该在85%以下 2.  Current Disk Queue Length:未完成磁盘请求数量,这个每个磁盘平均值应该小于2. 3.  Avg. Disk Queue Length:磁盘请求队列的平均长度,这个每个磁盘平均值也应该小于2 4.  Disk Transfers/sec:每次磁盘传输数量,这个每个磁盘的最大值应该小于100 5.  Disk Bytes/sec:每次磁盘传入字节数,这个在普通的磁盘上应该在10M左右 6.  Avg. Disk Sec/Read:从磁盘读取的平均时间,这个平均值应该小于10ms(毫秒) 7.  Avg. Disk Sec/Write:磁盘写入的平均时间,这个平均值也应该小于10ms(毫秒) 以上,请根据自己的磁盘系统判断,比如传统的机械臂磁盘和SSD有所不同。 一般磁盘的优化方向是: 1. 硬件优化:比如使用更合理的RAID阵列,使用更快的磁盘驱动器,添加更多的内存 2. 数据库设置优化:比如创建多个文件和文件组,表的INDEX和数据放到不同的DISK上,将数据库的日志放到单独的物理驱动器,使用分区表 3. 数据库应用优化:包括应用程序的设计,SQL语句的调整,表的设计的合理性,INDEX创建的合理性,涉及的范围很广 希望对您有所帮助,谢谢! ------------------------- 回 3楼(鹰舞) 的帖子 您好,      根据您的描述,由于查询产生了副本REDO LOG延迟,出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁: 架构锁分成两类: 1. SCH-M:架构更改锁,主要发生在数据库SCHEMA的修改上,从你的描述看,没有更改SCHEMA,那么可以排除这个因素 2. SCH-S:架构稳定锁,主要发生在数据库的查询编译等活动 根据你的情况,应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息,未参数化的SQL语句等等 对于INDEX和SQL语句方面应,我想应该不会有太多问题。 我们重点关注一下统计信息:SQL SERVER 2012 AG副本的统计信息维护有两种: 1. 主体下发到副本 2. 临时统计信息存储在TEMPDB 对于主体下发的,我们可以设置统计信息的更新行为,自动更新时,可以设置为异步的(自动更新统计信息必须首先打开): USE [master] GO ALTER DATABASE [Test_01]     SET AUTO_UPDATE_STATISTICS_ASYNC ON WITH NO_WAIT GO 这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。 对于临时统计信息存储在TEMPDB里面也是很重要的,再加上ALWAYSON的副本数据库默认是快照隔离,优化TEMPDB也是必要的,关于优化TEPDB这个我想大部分都知道,这里只是提醒一下。 除了从统计信息本身来解决,在查询过程中,可以降低查询的时间,以尽量减少LOCK的时间和范围,这需要优化你的SQL语句或者应用程序。 以上,希望对您有所帮助。谢谢! ------------------------- 回 4楼(leamonjxl) 的帖子 这是一个关于死锁的问题,为了能够提供帮助一些。请根据下列建议进行: 1.    跟踪死锁 2.    分析死锁链和原因 3.    一些解决办法 关于跟踪死锁,我们首先需要打开1222标记,例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息: 如果发生了死锁,需要分析死锁发生的根源在哪里?我们不是很清楚你的具体发生死锁的形态是怎么样的。 关于死锁的实例也多,这里不再举例。 这里只是提出一些可以解决的思路: 1.    减少锁的争用 2.    减少资源的访问数 3.    按照相同的时间顺序访问资源 减少锁的争用,可以从几个方面入手 1.    使用锁提示,比如为查询语句添加WITH (NOLOCK), 但这还取决于你的应用是否允许,大部分分布式的系统都是可以加WITH (NOLOCK), 金融行业可能需要慎重。 2.    调整隔离级别,使用MVCC,我们的数据库默认级别是READ COMMITED. 建议修改为读提交快照隔离级别,这样的话可以尽量读写不阻塞,只不过MVCC的ROW VERSION保存到TEMPDB下面,需要维护好TEMPDB。当然如果你的整个数据库隔离级别可以设置为READUNCOMMINTED,这些就不必了。 减少资源的访问数,可以从如下几个方面入手: 1.    使用聚集索引,非聚集INDEX的叶子页面与堆或者聚集INDEX的数据页面分离。因此,如果对非聚集INDEX 操作的话,会产生两个锁,一个是基本表,一个是非聚集INDEX。而聚集INDEX就不一样,聚集INDEX的叶子页面和表的数据页面相同,他只需要一个LOCK。 2.    查询语句尽量使用覆盖INDEX, 使用全覆盖INDEX,就不需要访问基本表。如果没有全覆盖,还会通过RID或者CLUSTER INDEX访问基本表,这样产生的LOCK可能会与其他SESSION争用。 按照相同的时间顺序访问资源: 确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问,第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK,但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。 ------------------------- 回 4楼(leamonjxl) 的帖子 两种方式看你的业务怎么应用。这里不仅是分表的问题,还可能存在分库,分服务器的问题。取决与你的架构方案。 物理分表+视图,这是一种典型的冷热数据分离的方案,大致的做法如下: 1.    保留最近3个月的数据为当前表,也即就是我们说的热数据 2.    将其他数据按照某种规则分表,比如按照年或者季度或者月,这部分是相对冷的数据 分表后,涉及到几个问题: 第一问题是,转移数据的过程,一般是晚上业务比较闲来转移,转移按照一定的规则来做,始终保持3个月,这个定时任务本身也很消耗时间 再者,关于查询部分,我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧,主库我觉得压力不会太大,主要是插入或者更新,只读需要做视图来包含全部的数据,但通过UNION ALL所有分表的数据,最后可能还是非常大,在某些情况下,性能不一定好。这个是不是业务上可以解决。比如,对于1年前的历史数据,放在单独的只读上,相对热的数据放在一起,这样压力也会减少。 分区表的话,因为涉及到10亿数据,要有好的分区方案,相对比较简单一点。但对于10亿的大表,始终是个棘手的问题,无论分多少个分区,单个服务器的资源也是有限的。可扩展性方面也存在问题,比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。 现在很多企业都在做分库分表,这些的要解决一些高并发,数据量大的问题。不知是否考虑过类似于中间件的方案,比如阿里巴巴的TDDL类似的方案,如果你有兴趣,可以查询相关资料。 ------------------------- 回 9楼(jiangnii) 的帖子 阿里云数据库不仅提供一个数据库,还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署,还提供了数据库高可用性架构,备份服务,性能诊断服务,监控服务,专家服务等等,保证用户放心、方便、省心地使用数据库,就像水电一样。以前的运维繁琐的事,全部由阿里云接管,用户只需要关注数据库的使用和具体的业务就好。 关于优化和在云数据库上处理大数据量或复杂的数据操作方面,在云数据库上是一样的,没有什么特别的地方,不过我们的云数据库是使用SSD磁盘,这个比普通的磁盘要快很多,IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务,比如索引诊断,连接诊断,容量分析,空间诊断等等,这些工作可能是专业的DBA才能完成的,以后我们会提供自动化的服务来为客户创造价值,希望能帮助到客户。 谢谢! ------------------------- 回 12楼(daniellin17) 的帖子 这个问题我不知道是否是两个问题,一个是并行度,另一个是并发,我更多理解是吞吐量,单就并行度而言。 提高并行度需要考虑的因素有: 1.    可用于SQL SERVER的CPU数量 2.    SQL SERVER的版本(32位/64位) 3.    可用内存 4.    执行的查询类型 5.    给定的流中处理的行数 6.    活动的并发连接数量 7.    sys.configurations参数:affinity mask/max server memory (MB)/ max degree of parallelism/ cost threshold for parallelism 以DOP的参数控制并行度为例,设置如下: SELECT * FROM sys.configurations WITH (NOLOCK) WHERE name = 'max degree of parallelism' EXEC sp_configure 'max degree of parallelism',2 RECONFIGURE WITH OVERRIDE 经过测试,DOP设置为2是一个比较适中的状态,特别是OLTP应用。如果设置高了,会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是:CXPACKET 你可以用下列语句去测试: DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR) SELECT * FROM sys.dm_os_wait_stats WITH (NOLOCK) ORDER BY 2 DESC ,3 DESC 如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话,大多根据业务量来预估,然后考虑以下: 1.    RAID的划分,RAID1适合存放事务日志文件(顺序写),RAID10/RAID5适合做数据盘,RAID10是条带化并镜像,RAID5条带化并奇偶校验 2.    数据库设置,比如并行度,连接数,BUFFER POOL 3.    数据库文件和日志文件的存放规则,数据库文件的多文件设置规则 4.    TEMPDB的优化原则,这个很重要的 5.    表的设计方面根据业务类型而定 6.    CLUSTERED INDEX和NONCLUSTERED INDEX的设计 7.    阻塞分析 8.    锁和死锁分析 9.    执行计划缓冲分析 10.    存储过程重编译 11.    碎片分析 12.    查询性能分析,这个有很多可以优化的方式,比如OR/UNION/类型转换/列上使用函数等等 我这里列举一个高并发的场景: 比如,我们的订单,比如搞活动的时候,订单刷刷刷地增长,单个实例可能每秒达到很高很高,我们分析到最后最常见的问题是HOT PAGE问题,其等待类型是PAGE LATCH竞争。这个过程可以这么来处理,简单列几点,可以参考很多涉及高并发的案例: 1.    数据库文件和日志文件分开,存放在不同的物理驱动器磁盘上 2.    数据库文件需要与CPU个数形成一定的比例 3.    表设计可以使用HASH来作为表分区 4.    表可以设置无序的KEY/INDEX,比如使用GUID/HASH VALUE来定义PRIMARY KEY CLUSTER INDEX 5.    我们不能将自增列设计为聚集INDEX 这个场景只是针对高并发的插入。对于查询而言,是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。 ------------------------- 回 13楼(zuijh) 的帖子 ECS上现在有两种磁盘,一种是传统的机械臂磁盘,另一种是SSD,请先诊断你的IO是否出现了问题,本帖中有提到如何判断磁盘出现问题的相关话题,请参考。如果确定IO出现问题,可以尝试使用ECS LOCAL SSD。当然,我们欢迎你使用云数据库的产品,云数据库提供了很多有用的功能,比如高可用性,灵活的备份方案,灵活的弹性方案,实用的监控报警等等。 ------------------------- 回 17楼(豪杰本疯子) 的帖子 我们单个主机或者单个实例的资源总是有限的,因为涉及到很大的数据量,对于存储而言是个瓶颈,我曾使用过SAN和SAS存储,SAN存储的优势确实可以解决数据的灵活扩展,但是SAN也分IPSAN和FIBER SAN,如果IPSAN的话,性能会差一些。即使是FIBER SAN,也不是很好解决性能问题,这不是它的优势,同时,我们所有DB SERVER都连接到SAN上,如果SAN有问题,问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大,是造成性能问题的直接原因,因为我们不管怎么优化,一旦数据量太大,优化的能力总是有限的,所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。 所以现在很多企业在向分布式系统发展,对于数据库而言,其实有很多形式。我们最常见的是读写分离,比如SQL SERVER而言,我们可以通过复制来完成读写分离,SQL SERVER 2012及以后的版本,我们可以使用ALWAYSON来实现读写分离,但这只能解决性能问题,那空间问题怎么解决。我们就涉及到分库分表,这个分库分表跟应用结合得紧密,现在很多公司通过中间件来实现,比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分,那么DB也可以由此拆分开来。举个简单例子,我们一个典型的电子商务系统,有订单,有促销,有仓库,有配送,有财务,有秒杀,有商品等等,很多公司在初期,都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后,就会出现性能和硬件资源问题,这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。 ------------------------- 回 21楼(dt) 的帖子 问: 求大数据量下mysql存储,优化方案 分区好还是分表好,分的过程中需要考虑事项 mysql高并发读写的一些解决办法 答: 分区:对于应用来说比较简单,改造较少 分表: 应用需较多改造,优点是数据量太大的情况下,分表可以拆分到多个实例上,而分区不可以。 高并发优化,有两个建议: 1.    优化事务逻辑 2.    解决mysql高并发热点,这个可以看看阿里的一个热点补丁: http://www.open-open.com/doc/view/d58cadb4fb68429587634a77f93aa13f ------------------------- 回 23楼(aelven) 的帖子 对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势,比如磁盘是性能超好的SSD,自动转移的高可用性,没有任何单点,自动灵活的备份方案,实用的监控报警,性能监控服务等等,省去DBA很多基础性工作。 你第二个问题,看起来是一个高并发的场景,这种高并发的场景容易出现大量的LOCK甚至死锁,我不是很清楚你的业务,但可以建议一下,首先可以考虑快照隔离级别,实现行多版本控制,让读写不要阻塞。至于写写过程,需要加锁的粒度降低最低,同时这种高并发也容易出现死锁,关于死锁的分析,本帖有提到,请关注。 第三个问题,你用ECS搭建自己的应用也是可以的,RDS数据库提供了很多功能,上面已经讲到了。安全问题一直是我们最看重的问题,肯定有超好的防护的。 ------------------------- 回 26楼(板砖大叔) 的帖子 我曾经整理的关于索引的设计与规范,可以供你参考: ----------------------------------------------------------------------- 索引设计与规范 1.1    使用索引 SQL SERVER没有索引也可以检索数据,只不过检索数据时扫描这个表而异。存储数据的目的,绝大多数都是为了再次使用,而一般数据检索都是带条件的检索,数据查询在数据库操作中会占用较大的比例,提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构,最小优化了定位所需要的键值的访问页面量,包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起,它决定表中数据存储的物理顺序,其叶子节点为数据行。 1.2    聚集索引 1.2.1    关于聚集索引 没聚集索引的表叫堆。堆是一种没有加工的数据,以行标示符作为指向数据存储位置的指针,数据没有顺序。聚集索引的叶子页面和表的数据页面相同,因此表行物理上按照聚集索引列排序,表数据的物理顺序只有一种,所以一个表只有一个聚集索引。 1.2.2    与非聚集索引关系 非聚集索引的一个索引行包含指向表对应行的指针,这个指针称为行定位器,行定位器的值取决于数据页保存为堆还是被聚集。若是堆,行定位器指向的堆中数据行的行号指针,若是聚集索引表,行定位器是聚集索引键值。 1.2.3    设计聚集索引注意事项     首先创建聚集索引     聚集索引上的列需要足够短     一步重建索引,不要使用先DROP再CREATE,可使用DROP_EXISTING     检索一定范围和预先排序数据时使用,因为聚集索引的叶子与数据页面相同,索引顺序也是数据物理顺序,读取数据时,磁头是按照顺序读取,而不是随机定位读取数据。     在频繁更新的列上不要设计聚集索引,他将导致所有的非聚集所有的更新,阻塞非聚集索引的查询     不要使用太长的关键字,因为非聚集索引实际包含了聚集索引值     不要在太多并发度高的顺序插入,这将导致页面分割,设置合理的填充因子是个不错的选择 1.3    非聚集索引 1.3.1    关于非聚集索引 非聚集索引不影响表页面中数据的顺序,其叶子页面和表的数据页面时分离的,需要一个行定位器来导航数据,在将聚集索引时已经有说明,非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型,比如覆盖索引,过滤索引等。 1.3.2    设计非聚集索引     频繁更新的列,不适合做聚集索引,但可以做非聚集索引     宽关键字,例如很宽的一列或者一组列,不适合做聚集索引的列可作非聚集索引列     检索大量的行不宜做非聚集索引,但是可以使用覆盖索引来消除这种影响 1.3.3    优化书签查找 书签会访问索引之外的数据,在堆表,书签查找会根据RID号去访问数据,若是聚集索引表,一般根据聚集索引去查找。在查询数据时,要分两个部分来完成,增加了读取数据的开销,增加了CPU的压力。在大表中,索引页面和数据页面一般不会临近,若数据只存在磁盘,产生直接随机从磁盘读取,这导致更多的消耗。因此,根据实际需要优化书签查找。解决书签查找有如下方法:     使用聚集索引避免书签查找     使用覆盖索引避免书签查找     使用索引连接避免数据查找 1.4    聚集与非聚集之比较 1.4.1    检索的数据行 一般地,检索数据量大的一般使用聚集索引,因为聚集索引的叶子页面与数据页面在相同。相反,检索少量的数据可能非聚集索引更有利,但注意书签查找消耗资源的力度,不过可考虑覆盖索引解决这个问题。 1.4.2    数据是否排序 如果数据需要预先排序,需要使用聚集索引,若不需要预先排序就那就选择聚集索引。 1.4.3    索引键的宽度 索引键如果太宽,不仅会影响数据查询性能,还影响非聚集索引,因此,若索引键比较小,可以作为聚集索引,如果索引键够大,考虑非聚集索引,如果很大的话,可以用INCLUDE创建覆盖索引。 1.4.4    列更新的频度 列更新频率高的话,应该避免考虑所用非聚集索引,否则可考虑聚集索引。 1.4.5    书签查找开销 如果书签查找开销较大,应该考虑聚集索引,否则可使用非聚集索引,更佳是使用覆盖索引,不过得根据具体的查询语句而看。 1.5    覆盖索引 覆盖索引可显著减少查询的逻辑读次数,使用INCLUDE语句添加列的方式更容易实现,他不仅减小索引中索引列的数据,还可以减少索引键的大小,原因是包含列只保存在索引的叶子级别上,而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生,与聚集索引类似,因为聚集索引值发生一次锁,非覆盖索引可能发生两次,一次锁数据,一次锁索引,以确保数据的一致性。覆盖索引相当于数据的一个拷贝,与数据页面隔离,因此也只发生一次锁。 1.6    索引交叉 如果一个表有多个索引,那么可以拥有多个索引来执行一个查询,根据每个索引检索小的结果集,然后就将子结果集做一个交叉,得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。 1.7    索引连接 几乎是跟索引交叉类似,是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询,SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。 1.8    过滤索引 用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效,创建索引时,可以像写T-SQL语句一样加个WHERE条件,以排除某部分数据而检索。 1.9    索引视图 索引视图在OLAP系统上可能有胜算,在OLTP会产生过大的开销和不可操作性,比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构,索引视图要求企业版,这些限制导致不可操作性。 1.10    索引设计建议 1.10.1    检查WHERE字句和连接条件列 检查WHERE条件列的可选择性和数据密度,根据条件创建索引。一般地,连接条件上应当考虑创建索引,这个涉及到连接技术,暂时不说明。 1.10.2    使用窄的索引 窄的索引有可减少IO开销,读取更少量的数据页。并且缓存更少的索引页面,减少内存中索引页面的逻辑读取大小。当然,磁盘空间也会相应地减少。 1.10.3    检查列的唯一性 数据分布比较集中的列,种类比较少的列上创建索引的有效性比较差,如果性别只有男女之分,最多还有个UNKNOWN,单独在上面创建索引可能效果不好,但是他们可以为覆盖索引做出贡献。 1.10.4    检查列的数据类型 索引的数据类型是很重要的,在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型,在数据长度较小的类型上创建又比在长度较长的类型上更有效。 1.10.5    考虑列的顺序 对于包含多个列的索引,列顺序很重要。索引键值在索引上的第一上排序,然后在前一列的每个值的下一列做子排序,符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性,列宽度,列的数据类型来做权衡。 1.10.6    考虑索引的类型 使用索引类型前面已经有较多的介绍,怎么选择已经给出。不再累述。 ------------------------- 回 27楼(板砖大叔) 的帖子 这两种都可以吧。看个人的喜好,不过微软现在的统一风格是下划线,比如表sys.all_columns/sys.tables,然后你再看他的列全是下划线连接,name     /object_id    /principal_id    /schema_id    /parent_object_id      /type    /type_desc    /create_date    /modify_date 我个人的喜好也是喜欢下划线。    
石沫 2019-12-02 01:34:30 0 浏览量 回答数 0

问题

【每日一题】Java知识大测验 | 持续更新

每天更新一题 让大家在休息时间可以轻松学习! 下面是关于JAVA的题目,每日更新~ (PS:大家要看清题号,需要答案的同学可以看下方留言) 1-24题链接 93--题链接 92...
游客ih62co2qqq5ww 2020-03-27 23:52:17 473 浏览量 回答数 1

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:06 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:06 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:06 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:05 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:05 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:05 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:06 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:05 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:06 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:05 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档  耗资源(客户程序故障)停权通知 尊敬的客户: 由于贵网站严重影响了服务器性能,因此对您的网站采取了处理措施。我们很高兴能够为您服务,但同时请您严格遵守我们签定的主机合同,以保证我们合作的正常进行,保证我们能为更多的用户提供稳定的主机服务。由于我们是对主机服务器进行实时监控的,出现问题后必须马上采取措施,否则将会导致服务器宕机,所以发出此通知信的同时,已将您的网站暂停,希望您能理解,因此给您带来的不便向您表示深深的歉意。   何谓耗资源(客户程序故障)? 即程序占用 CPU 及内存过多,是对资源的一种浪费。客户使用虚拟主机时程序编写的不合理、错误严重,造成服务器负载急剧上升,极大的影响了正常客户的使用,就是耗资源(客户程序故障)。耗资源(客户程序故障)分为耗用 CPU 资源和内存资源二种。   为什么会出现耗资源(客户程序故障)? 程序编写有问题(一般为 ASP 程序变量没有清空)。 数据库调用频繁(常见的是 Access 数据库问题)。 由于访问量或流量过大导致的耗内存问题引起的耗资源(客户程序故障)(此情况一般为大流量主机)。   耗资源(客户程序故障)的影响。 影响较轻的,会使单个客户网站访问慢。 严重的会使服务器宕机,服务器上的所有网站无法访问。   耗资源(客户程序故障)处理方法? 通过观察程度客户耗资源(客户程序故障)的程度,进行处理:  程度较轻:重启程序池或站点。  程度较重:关闭整个站点。   耗资源(客户程序故障)客户的解决办法? 发生占用资源过大问题被关停后,需要排查超额占用资源的具体链接和文件,下面介绍如何排查。 1. 从主机控制台下载关停当天的访问日志文件,具体下载路径:登录 阿里云虚拟主机管理页面 >  管理 > 文件管理 > 网站日志下载 > 下载当天的日志,通过 FTP 打开该日志: 2. 查看日志,下图为示例: 3. 具体排查方法: 站点在关停后是没有访问日志的,因此需要查看关停之前的1-2分钟的访问日志。 看服务器响应请求的时间,就是访问日志的最后一列,这里的时间单位是微秒,例如上图的示例中,访问时间不到一秒(1秒=1000000微秒),一般访问时间不应超过3秒(3000000微秒),访问时间长同样会导致并发访问量过大,适当的优化程序可以减少服务器的具体响应时间。具体访问的文件也在网站日志中有展示。如上图,如果网站访问日志中的最后一列超过3000000,也就是3秒,则需要检查和优化访问的具体文件,如上图的 test.php。  4. 如果大量的访问来自同一 IP,或是同一 IP 段,网站则可能是被攻击了。  5. 在浏览器种类这一列,如果有 Baidu,Google,Sogou,360 等字样,则表示是有搜索引擎在访问网站,如果影响网站可以配置 robots.txt 文件来禁止搜索引擎访问网站。   耗资源(客户程序故障)与大流量的区别。  大流量客户:进行大量的图片下载、广告互换、聊天等工作,造成带宽严重占用。 耗资源(客户程序故障)客户:运行自己网站程序,造成服务器负载急剧上升,造成服务器无法正常服务。 区别在与大流量客户是网络带宽方面,而耗资源(客户程序故障)客户是对服务器正常运行方面。        
2019-12-01 23:21:05 0 浏览量 回答数 0

问题

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

       性能测试在软件的质量保证中起着重要的作用,它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面:应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下&#...
云效平台 2019-12-01 21:45:09 5839 浏览量 回答数 1

回答

线网络优化是通过对现已运行的网络进行话务数据分析、现场测试数据采集、参数分析、硬件检查等手段,找出影响网络质量的原因,并且通过参数的修改、网络结构的调整、设备配置的调整和采取某些技术手段(采用MRP的规划办法等),确保系统高质量的运行,使现有网络资源获得最佳效益,以最经济的投入获得最大的收益。 二 GSM无线网络优化的常规方法 网络优化的方法很多,在网络优化的初期,常通过对OMC-R数据的分析和路测的结果,制定网络调整的方案。在采用图1的流程经过几个循环后,网络质量有了大幅度的提高。但仅采用上述方法较难发现和解决问题,这时通常会结合用户投诉和CQT测试办法来发现问题,结合信令跟踪分析法、话务统计分析法及路测分析法,分析查找问题的根源。在实际优化中,尤其以分析OMC-R话务统计报告,并辅以七号信令仪表进行A接口或Abis接口跟踪分析,作为网络优化最常用的手段。网络优化最重要的一步是如何发现问题,下面就是几种常用的方法: 1.话务统计分析法:OMC话务统计是了解网络性能指标的一个重要途径,它反映了无线网络的实际运行状态。它是我们大多数网络优化基础数据的主要根据。通过对采集到的参数分类处理,形成便于分析网络质量的报告。通过话务统计报告中的各项指标(呼叫成功率、掉话率、切换成功率、每时隙话务量、无线信道可用率、话音信道阻塞率和信令信道的可用率、掉话率及阻塞率等),可以了解到无线基站的话务分布及变化情况,从而发现异常,并结合其它手段,可分析出网络逻辑或物理参数设置的不合理、网络结构的不合理、话务量不均、频率干扰及硬件故障等问题。同时还可以针对不同地区,制定统一的参数模板,以便更快地发现问题,并且通过调整特定小区或整个网络的参数等措施,使系统各小区的各项指标得到提高,从而提高全网的系统指标。 2.DT (驱车测试):在汽车以一定速度行驶的过程中,借助测试仪表、测试手机,对车内信号强度是否满足正常通话要求,是否存在拥塞、干扰、掉话等现象进行测试。通常在DT中根据需要设定每次呼叫的时长,分为长呼(时长不限,直到掉话为止)和短呼(一般取60秒左右,根据平均用户呼叫时长定)两种(可视情况调节时长),为保证测试的真实性,一般车速不应超过40公里/小时。路测分析法主要是分析空中接口的数据及测量覆盖,通过DT测试,可以了解:基站分布、覆盖情况,是否存在盲区;切换关系、切换次数、切换电平是否正常;下行链路是否有同频、邻频干扰;是否有小岛效应;扇区是否错位;天线下倾角、方位角及天线高度是否合理;分析呼叫接通情况,找出呼叫不通及掉话的原因,为制定网络优化方案和实施网络优化提供依据。 3.CQT (呼叫质量测试或定点网络质量测试):在服务区中选取多个测试点,进行一定数量的拨打呼叫,以用户的角度反映网络质量。测试点一般选择在通信比较集中的场合,如酒店、机场、车站、重要部门、写字楼、集会场所等。它是DT测试的重要补充手段。通常还可完成DT所无法测试的深度室内覆盖及高楼等无线信号较复杂地区的测试,是场强测试方法的一种简单形式。 4.用户投诉:通过用户投诉了解网络质量。尤其在网络优化进行到一定阶段时,通过路测或数据分析已较难发现网络中的个别问题,此时通过可能无处不在的用户通话所发现的问题,使我们进一步了解网络服务状况。结合场强测试或简单的CQT测试,我们就可以发现问题的根源。该方法具有发现问题及时,针对性强等特点。 5.信令分析法:信令分析主要是对有疑问的站点的A接口、Abis接口的数据进行跟踪分析。通过对A接口采集数据分析,可以发现切换局数据不全(遗漏切换关系)、信令负荷、硬件故障(找出有问题的中继或时隙)及话务量不均(部分数据定义错误、链路不畅等原因)等问题。通过对Abis接口数据进行收集分析,主要是对测量仪表记录的LAY3信令进行分析,同时根据信号质量分布图、频率干扰检测图、接收电平分布图,结合对信令信道或话音信道占用时长等的分析,可以找出上、下行链路路径损耗过大的问题,还可以发现小区覆盖情况、一些无线干扰及隐性硬件故障等问题。 6.自动路测系统分析:采用安装于移动车辆上的自动路测终端,可以全程监测道路覆盖及通信质量。由于该终端能够将大量的信令消息和测量报告自动传回监控中心,可以及时发现问题,并对出现问题的地点进行分析,具有很强的时效性。所采用的方法同5。 在实际工作中,这几种方法都是相辅相成、互为印证的关系。GSM无线网络优化就是利用上述几种方法,围绕接通率、掉话率、拥塞率、话音质量和切换成功率及超闲小区、最坏小区等指标,通过性能统计测试→数据分析→制定实施优化方案→系统调整→重新制定优化目标→性能统计测试的螺旋式循环上升,达到网络质量明显改善的目的。 三 现阶段GSM无线网络优化方法 随着网络优化的深入进行,现阶段GSM无线网络优化的目标已越来越关注于用户对网络的满意程度,力争使网络更加稳定和通畅,使网络的系统指标进一步提高,网络质量进一步完善。 网络优化的工作流程具体包括五个方面:系统性能收集、数据分析及处理、制定网络优化方案、系统调整、重新制定网络优化目标。在网络优化时首先要通过OMC-R采集系统信息,还可通过用户申告、日常CQT测试和DT测试等信息完善问题的采集,了解用户对网络的意见及当前网络存在的缺陷,并对网络进行测试,收集网络运行的数据;然后对收集的数据进行分析及处理,找出问题发生的根源;根据数据分析处理的结果制定网络优化方案,并对网络进行系统调整。调整后再对系统进行信息收集,确定新的优化目标,周而复始直到问题解决,使网络进一步完善。 通过前述的几种系统性收集的方法,一般均能发现问题的表象及大部分问题产生的原因。 数据分析与处理是指对系统收集的信息进行全面的分析与处理,主要对电测结果结合小区设计数据库资料,包括基站设计资料、天线资料、频率规划表等。通过对数据的分析,可以发现网络中存在的影响运行质量的问题。如频率干扰、软硬件故障、天线方向角和俯仰角存在问题、小区参数设置不合理、无线覆盖不好、环境干扰、系统忙等。数据分析与处理的结果直接影响到网络运行的质量和下一步将采取的措施,因此是非常重要的一步。当然可以看出,它与第一步相辅相成,难以严格区分界限。 制定网络优化方案是根据分析结果提出改善网络运行质量的具体实施方案。 系统调整即实施网络优化,其基本内容包括设备的硬件调整(如天线的方位、俯仰调整,旁路合路器等)、小区参数调整、相邻小区切换参数调整、频率规划调整、话务量调整、天馈线参数调整、覆盖调整等或采用某些技术手段(更先进的功率控制算法、跳频技术、天线分集、更换电调或特型天线、新增微蜂窝、采用双层网结构、增加塔放等)。 测试网络调整后的结果。主要包括场强覆盖测试、干扰测试、呼叫测试和话务统计。 根据测试结果,重新制定网络优化目标。在网络运行质量已处于稳定、良好的阶段,需进一步提高指标,改善网络质量的深层次优化中出现的问题(用户投诉的处理,解决局部地区话音质量差的问题,具体事件的优化等等)或因新一轮建设所引发的问题。 四 网络优化常见问题及优化方案 建立在用户感知度上的网络优化面对的必然是对用户投诉问题的处理,一般有如下几种情况: 1.电话不通的现象 信令建立过程 在手机收到经PCH(寻呼信道)发出的pagingrequest(寻呼请求)消息后,因SDCCH拥塞无法将pagingresponse(寻呼响应)消息发回而导致的呼损。 对策:可通过调整SDCCH与TCH的比例,增加载频,调整BCC(基站色码)等措施减少SDCCH的拥塞。 因手机退出服务造成不能分配占用SDCCH而导致的呼损。 对策:对于盲区造成的脱网现象,可通过增加基站功率,增加天线高度来增加基站覆盖;对于BCCH频点受干扰造成的脱网现象,可通过改频、调整网络参数、天线下倾角等参数来排除干扰。 鉴权过程 因MSC与HLR、BSC间的信令问题,或MSC、HLR、BSC、手机在处理时失败等原因造成鉴权失败而导致的呼损。 对策:由于在呼叫过程中鉴权并非必须的环节,且从安全角度考虑也不需要每次呼叫都鉴权,因此可以将经过多少次呼叫后鉴权一次的参数调大。 加密过程 因MSC、BSC或手机在加密处理时失败导致呼损。 对策:目前对呼叫一般不做加密处理。 从手机占上SDCCH后进而分配TCH前 因无线原因(如RadioLinkFailure、硬件故障)使SDCCH掉话而导致的呼损。 对策:通过路测场强分析和实际拨打分析,对于无线原因造成的如信号差、存在干扰等问题,采取相应的措施解决;对于硬件故障,采用更换相应的单元模块来解决。 话音信道分配过程 因无线分配TCH失败(如TCH拥塞,或手机已被MSC分配至某一TCH上,因某种原因占不上TCH而导致链路中断等原因)而导致的呼损。 对策:对于TCH拥塞问题,可采用均衡话务量,调整相关小区服务范围的参数,启用定向重试功能等措施减少TCH的拥塞;对于占不上TCH的情况,一般是硬件故障,可通过拨打测试或分析话务统计中的CALLHOLDINGTIME参数进行故障定位,如某载频CALLHOLDINGTIME值小于10秒,则可断定此载频有故障。另外严重的同频干扰(如其它基站的BCCH与TCH同频)也会造成占不上TCH信道,可通过改频等措施解决。 2.电话难打现象 一般现象是较难占线、占线后很容易掉线等。这种情况首先应排除是否是TCH溢出的原因,如果TCH信道不足,则应增加信道板或通过增加微蜂窝或小区裂变的形式来解决。 排除以上原因后,一般可以考虑是否是有较强的干扰存在。可以是相邻小区的同邻频干扰或其它无线信号干扰源,或是基站本身的时钟同步不稳。这种问题较为隐蔽,需通过仔细分析层三信令和周围基站信息才能得出结论。 3. 掉话现象 掉话的原因几乎涉及网络优化的所有方面内容,尤其是在路测时发生的掉话,需要仔细分析。在路测时,需要对发生掉话的地段做电平和切换参数等诸多方面的分析。如果电平足够,多半是因为切换参数有问题或切入的小区无空闲信道。对话务较忙小区,可以让周围小区分担部分话务量。采用在保证不存在盲区的情况下,调整相关小区服务范围的参数,包括基站发射功率、天线参数(天线高度、方位角、俯仰角)、小区重选参数、切换参数及小区优先级设置的调整,以达到缩小拥塞小区的范围,并扩大周围一些相对较为空闲小区的服务范围。通过启用DirectedRetry(定向重试)功能,缓解小区的拥塞状况。上述措施仍不能满足要求的话,可通过实施紧急扩容载频的方法来解决。 对大多采用空分天线远郊或近郊的基站,如果主、分集天线俯仰角不一致,也极易造成掉话。如果参数设置无误,则可能是有些点信号质量较差。对这些信号质量较差而引起的掉话,应通过硬件调整的方式增加主用频点来解决。 4. 局部区域话音质量较差 在日常DT测试中,经常发现有很多微小的区域内,话音质量相当差、干扰大,信号弱或不稳定以及频繁切换和不断接入。这些地方往往是很多小区的交叠区、高山或湖面附近、许多高楼之间等。同样这种情况对全网的指标影响不明显,小区的话务统计报告也反映不出。这种现象一方面是由于频带资源有限,基站分布相对集中,频点复用度高,覆盖要求严格,必然不可避免的会产生局部的频率干扰。另一方面是由于在高层建筑林立的市区,手机接收的信号往往是基站发射信号经由不同的反射路径、散射路径、绕射路径的叠加,叠加的结果必然造成无线信号传播中的各种衰落及阴影效应,称之为多径干扰。此外,无线网络参数设置不合理也会造成上述现象。 在测试中RXQUAL的值反映了话音质量的好坏,信号质量实际是指信号误码率, RXQUAL=3(误码率:0.8%至1.6%),RXQUAL=4(误码率:1.6%至3.2%),当网络采用跳频技术时,由于跳频增益的原因,RXQUAL=3时,通话质量尚可,当RXQUAL≥6时,基本无法通话。 根据上述情况,通过对这些小区进行细致的场强覆盖测试和干扰测试,对场强覆盖测试数据进行分析,统计出RXLEV/RXQUAL之间对照表,如果某个小区域RXQUAL为6和7的采样统计数高而RXLEV大于-85dBm的采样数较高,一般可以认为该区域存在干扰。并在Neighbor-List中可分析出同频、邻频干扰频点。 5.多径干扰 如果直达路径信号(主信号)的接收电平与反射、散射等信号的接收电平差小于15dB,而且反射、散射等信号比主信号的时延超过4~5个GSM比特周期(1个比特周期=3.69μs),则可判断此区域存在较强的多径干扰。 多径干扰造成的衰落与频点及所在位置有关。多径衰落可通过均衡器采用的纠错算法得以改善,但这种算法只在信号衰落时间小于纠错码字在交织中分布占用的时间时有效。 采用跳频技术可以抑制多径干扰,因为跳频技术具有频率分集和干扰分集的特性。频率分集可以避免慢速移动的接收设备长时间处于阴影效应区,改善接收质量;而且可以充分利用均衡器的优点。干扰分集使所有的移动及基站接收设备所受干扰等级平均化。使产生干扰的几率大为减小,从而降低干扰程度。 采用天线分集和智能天线阵,对信号的选择性增强,也能降低多径干扰。 适当调整天线方位角,也可减小多径干扰。 若无线网络参数设置不合理,也会影响通话质量。如在DT测试中常常发现切换前话音质量较差,即RXQUAL较大(如5、6、7),而切换后,话音质量变得很好,RXQUAL很小(如0、1),而反方向行驶通过此区域时话音质量可能很好(RXQUAL为0、1),因为占用的服务小区不同。对于这种情况,是由于基于话音质量切换的门限值设置不合理。减小RXQUAL的切换门限值,如原先从RXQUAL≥4时才切换,改为RXQUAL≥3时就切换,可以提高许多区域的通话质量。因此,根据测试情况,找出最佳的切换地点,设置最佳切换参数,通过调整切换门限参数控制切换次数,通过修改相邻小区的切换关系提高通话质量。总之,根据场强测试可以优化系统参数。 值得一提的是,由于竞争的激烈及各运营商的越来越深化的要求,某些地方的运营商为完成任务,达到所谓的优化指标,随意调整放大一些对网络统计指标有贡献的参数,使网络看起来“质量很高”。然而,用户感觉到的仍是网络质量不好,从而招致更多用户的不满,这是不符合网络优化的宗旨的。 总之,网络优化是一项长期、艰巨的任务,进行网络优化的方法很多,有待于进一步探讨和完善。好在现在国内两大运营商都已充分认识到了这一点,网络质量也得到了迅速的提高,同时网络的经济效益也得到了充分发挥,既符合用户的利益又满足了运营商的要求,毫无疑问将是持续的双赢局面。 答案来源于网络
养狐狸的猫 2019-12-02 02:18:17 0 浏览量 回答数 0

问题

【精品问答】Python数据爬取面试题库100问

Python爬虫面试题库100问: 1.遇到过得反爬虫策略以及解决方法? 2.urllib 和 urllib2 的区别? 3.列举网络爬虫所用到的网络数据包,解析包? 4.简述一下爬虫...
珍宝珠 2019-12-01 21:55:53 6502 浏览量 回答数 3

回答

有编程能力和数据挖掘能力的工程师最火,包括:数据挖掘工程师、机器学习工程师,算法工程师。 今年3月份时,谷歌开发的人工智能AlphaGo打败了全球最顶尖的围棋高手,轰动全世界,AI时代正式拉开序幕。实际上,人工智能这一概念早在上世纪一大批科幻小说陆续发表时,就已被人们接受,而随着科技的发展,人工智能的发展前景更是日益清晰。一个人工智能的诞生需要无数个工程师挥洒汗水。其中,负责开发学习算法、使机器能像人类一样思考问题的数据挖掘工程师更是无比重要。什么人能完成人工智能的开发任务呢。必须指出,人工智能和一般的计算机程序有极大的差别,它应当具有“能够自主学习知识”这一特点,这一特点也被称为“机器学习”。而自学习模型(或者说机器学习能力开发)正是数据挖掘工程师的强项,人工智能的诞生和普及需要一大批数据挖掘工程师。  那么在AI时代,如何才能掌握相关的技能,成为企业需要的数据挖掘人才呢。 第一个门槛是数学 首先,机器学习的第一个门槛是数学知识。机器学习算法需要的数学知识集中在微积分、线性代数和概率与统计当中,具有本科理工科专业的同学对这些知识应该不陌生,如果你已经还给了老师,我还是建议你通过自学或大数据学习社区补充相关知识。所幸的是如果只是想合理应用机器学习算法,而不是做相关方向高精尖的研究,需要的数学知识啃一啃教科书还是基本能理解下来的。 第二个门槛是编程 跨过了第一步,就是如何动手解决问题。所谓工欲善其事必先利其器,如果没有工具,那么所有的材料和框架、逻辑、思路都给你,也寸步难行。因此我们还是得需要合适的编程语言、工具和环境帮助自己在数据集上应用机器学习算法。对于有计算机编程基础的初学者而言,Python是很好的入门语言,很容易上手,同时又活跃的社区支持,丰富的工具包帮助我们完成想法。没有编程基础的同学掌握R或者平台自带的一些脚本语言也是不错的选择。 Make your hands dirty 接下来就是了解机器学习的工作流程和掌握常见的算法。一般机器学习步骤包括: 数据建模:将业务问题抽象为数学问题; 数据获取:获取有代表性的数据,如果数据量太大,需要考虑分布式存储和管理; 特征工程:包括特征预处理与特征选择两个核心步骤,前者主要是做数据清洗,好的数据清洗过程可以使算法的效果和性能得到显著提高,这一步体力活多一些,也比较耗时,但也是非常关键的一个步骤。特征选择对业务理解有一定要求,好的特征工程会降低对算法和数据量的依赖。 模型调优:所谓的训练数据都是在这个环节处理的,简单的说就是通过迭代分析和参数优化使上述所建立的特征工程是最优的。 这些工作流程主要是工程实践上总结出的一些经验。并不是每个项目都包含完整的一个流程,只有大家自己多实践,多积累项目经验,才会有自己更深刻的认识。 翻过了数学和编程两座大山,就是如何实践的问题,其中一个捷径就是积极参加国内外各种数据挖掘竞赛。国外的Kaggle和国内的阿里天池比赛都是很好的平台,你可以在上面获取真实的数据和队友们一起学习和进行竞赛,尝试使用已经学过的所有知识来完成这个比赛本身也是一件很有乐趣的事情。 另外就是企业实习,可以先从简单的统计分析和数据清洗开始做起,积累自己对数据的感觉,同时了解企业的业务需求和生产环境。我们通常讲从事数据科学的要”Make your hands dirty”,就是说要通过多接触数据加深对数据和业务的理解,好厨子都是食材方面的专家,你不和你的“料”打交道,怎么能谈的上去应用好它。 摆脱学习的误区 初学机器学习可能有一个误区,就是一上来就陷入到对各种高大上算法的追逐当中。动不动就讨论我能不能用深度学习去解决这个问题啊。实际上脱离业务和数据的算法讨论是毫无意义的。上文中已经提到,好的特征工程会大大降低对算法和数据量的依赖,与其研究算法,不如先厘清业务问题。任何一个问题都可以用最传统的的算法,先完整的走完机器学习的整个工作流程,不断尝试各种算法深挖这些数据的价值,在运用过程中把数据、特征和算法搞透。真正积累出项目经验才是最快、最靠谱的学习路径。 自学还是培训 很多人在自学还是参加培训上比较纠结。我是这么理解的,上述过程中数学知识需要在本科及研究生阶段完成,离开学校的话基本上要靠自学才能补充这方面的知识,所以建议那些还在学校里读书并且有志于从事数据挖掘工作的同学在学校把数学基础打好,书到用时方恨少,希望大家珍惜在学校的学习时间。 除了数学以外,很多知识的确可以通过网络搜索的方式自学,但前提是你是否拥有超强的自主学习能力,通常拥有这种能力的多半是学霸,他们能够跟据自己的情况,找到最合适的学习资料和最快学习成长路径。如果你不属于这一类人,那么参加职业培训也许是个不错的选择,在老师的带领下可以走少很多弯路。另外任何学习不可能没有困难,也就是学习道路上的各种沟沟坎坎,通过老师的答疑解惑,可以让你轻松迈过这些障碍,尽快实现你的“小”目标。 机器学习这个领域想速成是不太可能的,但是就入门来说,如果能有人指点一二还是可以在短期内把这些经典算法都过一遍,这番学习可以对机器学习的整体有个基本的理解,从而尽快进入到这个领域。师傅领进门,修行靠个人,接下来就是如何钻进去了,好在现在很多开源库给我们提供了实现的方法,我们只需要构造基本的算法框架就可以了,大家在学习过程中应当尽可能广的学习机器学习的经典算法。 学习资料 至于机器学习的资料网上很多,大家可以找一下,我个人推荐李航老师的《统计机器学习》和周志华老师的《机器学习》这两门书,前者理论性较强,适合数学专业的同学,后者读起来相对轻松一些,适合大多数理工科专业的同学。
管理贝贝 2019-12-02 01:21:46 0 浏览量 回答数 0

问题

MaxCompute百问集锦(持续更新20171011)

大数据计算服务(MaxCompute,原名 ODPS)是一种快速、完全托管的 GB/TB/PB 级数据仓库解决方案。MaxCompute 向用户提供了完善的数据导入方案以及多种经典的分布式计算模型,能够更快速的解决用户海量数据计算问题,有效...
隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

回答

详细解答可以参考官方帮助文档五天无理由退款目前阿里云部分产品支持 5 天无理由退款。如果您购买这些产品 5 天内(包含产品试用时间)有退款需求,可登录阿里云费用中心 五天无理由退款 进行操作(具体规则以退款页面的退款说明为准)。退款款项会退至用于支付的原支付宝帐号、网银渠道或阿里云账号中。 可五天无理由退款产品新购包年包月产品:云服务器 ECS、关系型数据库 RDS、云市场产品、 云虚拟主机、云盾高防 IP。 五天无理由退款规则说明 支持 5 天无理由退款的产品,在包年包月新购 5 天内,可申请无理由退款。服务器退款限制: 云服务器 ECS、关系型数据库 RDS 或云虚拟主机限每个用户最多退款 1 次,最多累积可退 1 个实例。云盾高防 IP 和安全网络产品限每个用户每个产品最多可累计退款 2 个订单(如果产生了 DDoS 攻击事件则无法退款)。云虚拟主机新购 5 天内做过续费、升级、更换系统和机房(增加带宽的除外),不支持 5 天无理由退款。云市场产品申请全额退款条件: 处于 已开通 状态,且在购买之日起 5 天内。处于 服务中 状态,在状态变为 已完成 前可申请。 退款只退还实付金额,已使用的代金券不退还。活动期购买的云产品申请 5 天无理由退款后,赠品(代金券、延长服务期等)将作废清零。活动规则中说明 不支持5天无理由退款 无法申请 5 天无理由退款。参与活动购买产品,如若通用退款规则与活动规则冲突,以活动规则为准。 5 天无理由退款操作方法登录 阿里云控制台,单击页面上方 费用 进入费用中心。再单击左侧导航栏中 退订管理 > 五天无理由退款。然后按照退款流程完成退款申请。 如您需要退款的产品类型不在支持五天无理由退款产品中,或者超出了五天无理由退款限制,则无法办理退款。 如果您有产品使用方面的问题,请参阅相关产品文档。如果文档不能帮您解决问题,您可以通过相应产品的工单接口 提交工单 进行反馈。 非全额退款部分阿里云产品,若为包年预付费方式购买,在一些特定条件下可在服务期满前提前退订。可提前退订的产品和具体规则,请阅读相应产品的计费相关文档或咨询售后支持。此类退款需通 提交产品售后工单 处理。 非全额退款金额计算公式退款金额 = 订单实付金额-已消费金额-退订手续费说明: 订单实付金额:仅指用户以现金方式支付的订单款项,不包含用户通过代金券抵扣的部分。已消费金额 =(订单原价 × 用户订购产品时适用的折扣比例)×(实际消费时长/订单总时长) 订单原价:指订单中优惠前的产品原价。实际消费时长:按使用小时扣除的使用时间。 按照退款金额计算公式得出的退款金额如小于 0,则不予退款。 非全额退订手续费收取标准实际消费时长 ≤1 年1 年<实际消费时长 ≤2 年2 年<实际消费时长<3 年3 年预付费产品订单实付金额 × 20%订单实付金额 × 15%订单实付金额 × 12%2 年预付费产品订单实付金额 × 20%订单实付金额 × 15%/1 年预付费产品订单实付金额 × 15%// 退款流向 通过支付宝或网银支付的云产品订单,发生退款时,会退至支付使用的支付宝或网银账号。 订单支付成功后,三个月内办理退款,退款至原支付途径;超过三个月办理退款,退款至阿里云账号。 通过支付宝、网银支付的云产品,因系统失败或资金变动发生的支付失败退回原支付途径。 通过账号余额支付的订单退款至阿里云账号。 通过网银支付的订单发生退款,受银行受理时间影响,预计 2-3 个工作日内到账。 2017 年 8 月 12 日以后的订单支持原路退,历史订单退款仍退回阿里云现金帐号。 常见问题其他退款相关常见问题,请参见: 域名与网站(万网)产品退款说明及办理流程 通过聚石塔购买的产品如何退款? 如何查看退款记录?
2019-12-01 23:28:24 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT