你好！根据你提供的信息，可能存在以下原因导致 CPU 使用率异常：

CPU 限制设置过低：如果 Pod 中的 Java 应用需要处理大量的请求或者有较高的计算复杂度，那么限制到 4 核可能无法满足其正常运行的需求。建议适当增加限制值并观察是否有改善。

CPU 亲和性设置不合理：如果容器与宿主机之间存在 CPU 亲和性设置，而这些设置可能会影响容器的资源调度和分配。建议查看 Pod 及其相关的 Deployment/StatefulSet 等资源配置，确认是否设置了 CPU 亲和性。

内核版本问题：你提到宿主机内核版本是 3.10 ，这个版本较老，可能存在一些现有的性能问题。建议升级内核版本以获取更好的性能。

k8s 版本问题：你提到 k8s 版本是 1.13 ，也是比较老的版本。较新的版本可能包含更好的性能优化和稳定性改进。建议考虑升级到最新的稳定版本，以获取更好的体验。

另外，你提到在刷 top 命令时出现 CPU 使用率超过 1100%的情况，这可能是瞬态现象。建议使用其他工具（如 ps ）来监控进程的 CPU 使用率，同时长期持续地监控 CPU 使用率变化，从而更好地确认问题所在。

看到这么多正义人士，义愤填膺，真是有意思。好像 op 不是错买了 VPS ，倒像是抢了正义人士自己的 VPS 。正义人士好不容易逮人口实，拿起键盘恨不得砸死 op ，上演一出义薄云天，想让 op 舍生取义，我替 op 感到十分惘然。

二把刀一直开手动挡，有次开同学的电车送他们回家（他们喝了酒），长时间不碰自动挡，脚生，我俩脚放在俩踏板上，怎么都反应不过来哪个油门，哪个刹车，测试着像是和手动挡相反的，搞半天不走，我还想着我也没喝酒，怎么也有点醉，结果旁边同学打开闪光灯看了我的脚，说我左脚别用了，我才反应过来，原来油门刹车一起块踩了半天 =。=

@string2020 如果有 1000k 的用户同时用，中间做日志存储，如果再有实时分析，怎么可能 IO 没影响。带宽不是问题，你这意思是不够用就加硬件呗，反正不是自己花钱。程序员要都是你这想法，淘宝 JD 都不一定能开起来。

500 和程序崩也一样，nginx 也是返回 502

突然懂了，65279 对应十六进制 FEFF ，也就是 Unicode Byte Order Mark (BOM)。
csv 文件为了解决 excel 打开的中文乱码问题，手动设置过 BOM ，在导入到 tidb 的时候，U+FEFFmaterial_id 被当成了一个整体

那个小红点单独粘不出来，但是连着前边的空格，可以粘出来，检测出来 unicode 是 65279 ，然后通过
```golang
SQL := fmt.Sprintf("SELECT %cmaterial_id FROM mytable LIMIT 1", 65279)
```终于在业务代码里实现正常查询了，我是真的不懂，为什么有个这样的坑

感谢各位，找到是数据同步时候，数据库 IO 打满的问题

拿高射炮当烟花用，那确实不好看

1. 选个喜欢的语言，熟悉基本用法
2. 熟悉 SQL 写法，熟悉相关的 ORM
3. 写 web 业务的话，熟悉相关的 web 框架
4. 实际写个项目
5. 可以做牛马了

末流 211 表示入行的时候，杭州 4k ，过了三个月涨到 6k ，再 3 个月驻地到 9k 。
我刚毕业要是有个 8k 的正经公司接收，已经很开心了。

印象中有些 unicode 字符，在某些情况下，都可以用来突破，比如 0x39 。预防 SQL 注入，不是光过滤特殊字符就够的。

8 楼没理解 SQL 注入是怎么回事，不管你拼接在哪，都有可能用 union ，或者 ; select 来获取其他表的数据

一时分辨不出，是在揶揄华晨宇，还是在揶揄 40 岁程序员

戾气有点重

type 是 all ，确实是 full table scan 。rows 是查询到满足条件的数据前，大概需要扫描的行数，不是完全精确。
不是说加了索引就一定走索引，在表数据量小的情况下，全表扫描性能可以优于索引。