这是一个创建于 1966 天前的主题，其中的信息可能已经有所发展或是发生改变。
前提是这个系统在测试环境和预发环境都没问题，就线上出问题了。因为已经上线了，所以没有办法加日志，也不能使用调试工具远程连上线上环境测试（比如 jvm 远程断点调试）。你只能远程连上容器操作命令行，并且排查操作不能影响线上系统的性能（比如导致吞吐量明显下降，API 反应明显变慢等）。
 | 1 yulgang 2020-07-24 10:17:59 +08:00 主机虚拟内存使用情况； netstat 看看 Recv-Q Send-Q 情况，有时候 DNS 反向解析也可能会导致慢或者一部分功能不可用。 |
 | 2 wenjian881314 2020-07-24 10:34:00 +08:00  1 无脑 arthas |
 | 3 gadsavesme 2020-07-24 10:34:04 +08:00 1 ng 查看下回复时间，排查是否网络原因；是否 io 密集型任务排查下系统 io 情况； cpu 是否高占用，如果高占用具体排查线程，是 gc 线程还是用户线程。数据库是否有慢查询，缓存连接情况，mq 消费是否正常，是否有三方接口响应过慢。大方向具体就想到那么多。 |
 | 4 fishofcat 2020-07-24 10:36:17 +08:00 15 简单呀，找熟悉系统的人排查 |
 | 5 TomVista 2020-07-24 10:38:00 +08:00 所以到底出了什么问题,表现是什么? 先问清楚呗, |
 | 7 ChanKc 200-07-24 10:54:42 +08:00 via Android 4 想到个很有趣的说法，说服务端程序的优化是启动慢没关系，要的是运行时的速度提高。而客户端的优化是启动要快，运行时稍微慢一些也没关系。 面试问这种问题我觉得挺没意思的。在短时间内思考，自然是做过的能答出来，没做过的就答不出来。如果面试被问这个我会觉得对方在“要经验”和“要能力”之间，更倾向于前者 |
 | 8 xsirfly 2020-07-24 10:57:06 +08:00 是启动慢还是系统慢，如果只是启动慢，那说明线上没问题呀，加点日志，下次上线时看看启动到底哪里慢；如果是接口慢，那就看看系统负载瓶颈呗，是 cpu 满了，内存不够了还是网卡爆了 |
 | 9 swulling 2020-07-24 10:58:26 +08:00 via iPhone 启动慢又不是运行慢，模拟线上环境在线下尝试复现呗。 线上即然已经上线，启动慢就不是问题，先封禁变更放着，没必要在线上 debug 。 如果线下无法复现，就在线上找个实例，从 LB 上把流量摘了，随便打点加日志折腾 |
 | 10 pmispig 2020-07-24 11:04:59 +08:00 启动慢再多加一个节点不注册服务不就行了，慢慢调试啊 |
 | 11 tusj 2020-07-24 11:08:39 +08:00 先看看启动的日志呗，大致能看到哪里慢，还能怎么着 |
 | 12 atonku 2020-07-24 11:09:22 +08:00 重启啊 |
 | 14 est 2020-07-24 11:30:29 +08:00 > 不能使用调试工具远程连上线上环境测试（比如 jvm 远程断点调试） > 只能远程连上容器操作命令行 只有我一个人觉得这两个设定是矛盾的么。都能 ssh 了。为啥不能上调试工具啊。。 |
 | 15 tcfenix 2020-07-24 11:34:06 +08:00 3 @laike9m 阿里一个应用可能上千台容器,分批估计要分 6 到 8 批,每批又有几个小时的灰度观察时间,真的大型应用发布起来可以说是个体力活,超 1000 台容器的话每次启动总有几个容器会出问题,然后导致不断的重启,重启,启动速度慢能让一个系统发布发的崩溃的 说实话,如果预发环境(这年头谁用测试环境?根本没数据没有依赖服务,有什么东西能测的?)没有问题,那肯定就是线上依赖的上下游系统出问题了,直接在代码里面看依赖了哪些上下游服务,然后点进去看他们有没有发布,基本上就破案了,如果没找到系统发布,那么就查他们配置有没有发布 基本上到这里就没有什么问题了 |
| 16 tcfenix 2020-07-24 11:44:38 +08:00 |
 | 17 p2pCoder 2020-07-24 11:44:45 +08:00 新开一个服务，启动不注册服务，可以做线上 trace，定位是不是单机的问题 除了服务本身的问题，线上 预发 测试的容器规格需要考虑 不同环境下的实例数目需要考虑 同时启动的服务实例数目需要考虑 启动时候依赖的中间件 db 的负载情况 需要了解 |
 | 18 lazyfighter 2020-07-24 11:54:55 +08:00 一般经验网络不稳导致连接注册中心等很慢，不过这种情况因为内网可以忽略， 另外都是因为在启动的时候执行了过多的预加载导致的 |
 | 19 qiyuey 2020-07-24 12:07:35 +08:00 Arthas |
 | 20 laminux29 2020-07-24 12:27:33 +08:00 1 先查看各物理设备情况。比如 CPU 、MEM 、CACHE 、DISK 、NET 等等。 如果物理设备没问题，多半就是代码的问题了。 这种题目很坑且无解，因为无论被面试者有多牛逼，这种题目，从不同角度回答，会得到完全相反且极端的评价，一般这种问题，HR 会拿来无脑选人或踢人。 |
 | 21 rioshikelong121 2020-07-24 12:29:00 +08:00 我想问问你是面什么岗位 |
 | 22 kaedea 2020-07-24 13:16:58 +08:00 via Android 面向熟人编程 |
 | 23 NVDA 2020-07-24 13:18:30 +08:00 via iPad 发 ticket 找 oncall 啊，自己瞎折腾什么 |
 | 24 runningman007 2020-07-24 13:30:45 +08:00 重启 还不行就重装系统 :) |
 | 25 zh1997 2020-07-24 13:49:19 +08:00 先看服务器负载情况，查查系统瓶颈，可能是木马：top 如果系统负载正常，看启动慢在哪：strace 如果启动过程中需要联网考虑下路由、网关的情况 翻翻系统日志没准能发现问题：/var/log/messages |
 | 27 Vkery 2020-07-24 14:00:15 +08:00 用阿里的 arthas |
 | 28 lipcao 2020-07-24 14:21:34 +08:00 重点是启动慢吧，也可能初始加载数据太多了，UAT 环境数据少，生产数据多 |
 | 29 Jooooooooo 2020-07-24 14:34:11 +08:00 人家问这问题是想看你思路 |
 | 30 justin2018 2020-07-24 14:36:51 +08:00 看看有没有 sleep 函数 |
 | 31 ivyliner 2020-07-24 14:47:17 +08:00 @linxiaoziruo 从你的描述上看启动慢的话, 可以 "系统", "容器", "网络, 业务代码上来分析 - 系统方面: 系统当时的负载是不是比较高 ? 甚至有可能有对应的硬件故障? 比如硬盘故障导致系统启动慢 ? - 网络方面: 如果业务的特性, 比如业务启动需要去服务中心注册之类, 那么外部依赖, 和网络上是否有问题? - 容器: 容器相关的网络, IO 等也会导致慢, 比如容器常见的 DNS 的 ndot 问题 - 业务代码: 有可能线上环境的问题, 比如业务配置文件不存在, 超时配置等不合理系列问题. 不能影响线上系统的性能的话, 主要思路其实是要对自己执行的命令有充分的了解. 比如 strace 命令其实是会有一定的影响, 可以考虑使用 sysdig 或者 bcc 之类的命令来替代. 最后打一个广告, 上面的各种命令, 都在我(资深的运维工程师)开发的 "小命令" 小程序里面有一定的体现, 且在持续更新中.  |
 | 32 sampeng 2020-07-24 15:00:35 +08:00 via iPhone 都说了启动慢…启动是一个过去状态，请问你们这么招怎么观察一个过去的状态？在这一瞬间启动然后排查？等你进完容器，都启动完了。这怎么查？拍脑袋猜？假设题主没写错题目。所有限定就是尼不能看到线上的日志，不能对线上做任何操作。那只能看源码了，看启动流程里面干了什么。在本地做测试。当然，这个还要区分是容器启动慢还是应用启动慢。原因都不一样。比如线上因为宿主机的文件句柄快用完了，啥都会启动慢。还是有很多可能的。查看宿主机监控先排除容器的问题。再处理应用的问题 |
 | 33 leafre 2020-07-24 15:09:28 +08:00 启动慢，看启动 console 啊 |
 | 34 linxiaoziruo OP 各位大佬的回复我都看了。大致分为两类原因，一类是本地原因（如 CPU 过高，IO 过于密集），一类是远程交互问题（如网络不通，查询遇到慢 sql，或者消息队列消费阻塞了）。我当时也是有点懵，被面试官提到的『陌生系统』这个词给弄晕了。如果是陌生系统，那么就意味着你是不知道这个线上服务有没有和外部通信的，有没有使用消息队列或者启动的时候有没有执行数据库查询的。 |
 | 35 TtTtTtT 2020-07-24 15:30:54 +08:00 这个 case 也太真实了吧=。= 一个结论，不具有一般性： 1. 用差不多 2 个小时看一下启动日志，然后看一下启动时期一些中间件的初始化耗时情况。 2. 基本上这里的结论都没有啥用，然后会在下一个发布时间搭车加一些日志，测量一下初始化的问题具体在哪里。 3. 发现真的解决不了问题，然后跟中间件说把发布启动超时弄长一点。 4. 然后他们就会比较关注这个应用，跟你说哪里可以改进一下。 |
 | 36 KingHL 2020-07-24 17:55:33 +08:00 一看就知道是真阿里的面试题 |
 | 37 dany813 2020-07-24 18:00:20 +08:00 学习 |
 | 38 windfarer 2020-07-24 18:18:07 +08:00 爪哇的程序有启动得快的吗？ |
 | 39 qwerthhusn 2020-07-24 18:54:46 +08:00 ECS 升级啊 |
 | 40 lululau 2020-07-24 19:04:15 +08:00 via iPhone dtrace 吧，直接了当，Linux 就用 jvm 上特有的等价物吧 |
 | 41 waitingChou 2020-07-25 12:31:20 +08:00 如果其他环境没问题就生产有问题，那理论上是程序的问题概率很小。 如果是我不会重点关注项目日志(因为你也不熟)，而会在对比环境的差异： 1. 生产和测试的服务配置有没有可能影响？ 启动参数一样吗？ 2. 检查各环境服务器配置和负载 进行不同环境的对比，找出不同项重点排查 |
Select Language