linux平台下server运维问题分析与定位
结合我工作中碰到的运维问题,总结一下linux下server常见的运维问题以及定位方式。这里的server主要指自主开发的逻辑server,web srv因为通常采用通用的架构所以问题比较少。
逻辑server通常的处理能力在3k/s - 1w/s之间,因业务特点而不同。逻辑server一般是自主开发的,虽然在上线前大都经过功能和压力测试,但放到现网环境上部署后还是难免会出现一些问题,有些问题是在灰度发布时就可以发现,而有些问题则是一个漫长的暴露过程。下面先总结一下大致的问题分类和定位方法。
1. 程序BUG如fd泄漏或内存泄漏
业务上线前一定要做压测,同时查看进程消耗的内存与fd数,结合业务特性分析fd使用量是否合理,同时观察内存使用是不是最终会趋于稳定的值,如果一直增加,就肯定有泄漏。
fd泄漏确认方法是:ls /proc/pid/fd -al | wc,可以看到单个进程使用的fd数,观察是否一直在涨长,如果没有最终达到一个稳定值,则可以确认存在泄漏。同时可以cat /proc/net/sockstat观察整体的fd使用数量是否一直在涨长,通常32位的机器,fd超过10W时系统会到达瓶颈。
内存泄漏确认方法是:top 看进程使用的RES 和 SHR,观察是否一直在涨长,如果没有最终达到一个稳定值,则可以确认存在泄漏。同时可以看下mem的使用量是否一直在增加。内存泄漏最终的结果是使用到的swap分区,一旦出现这种情况,cpu的wa字段会出现远大于0的情况,表明cpu阻塞在等待输入输出上。
2. 业务自然增长
这一点依赖于对请求数的统计,通过对前后几天的对比,不难确认是否是业务自然增长,单机请求量上升使系统出现瓶颈,这种问题通过扩容可以轻松解决,但最好的办法是对系统的容量和关键参数如cpu\mem\eth加上监控,能够做到提前告警,这样不至于在出问题的时候紧急扩容。
3. 特性变更导致用户行为异常
举个例子,有一次我在升级server时,基于性能的考虑,少返回了一个已无效的字段,灰度升级一台机器后,发现系统负载升高了3倍,当时的第一反应是有bug,使到cpu的使用突增,但vmstat发现 升级前cpu使用率 usr 和 sys大致是 14 7,升级后为 42 21,大致同比增长了3倍,再看一下请求数,发现请求数也同比增长,可见,是某些原因达致用户在重试。
&n
相关文档:
当执行
ls -l
或
ls -al
命令后显示的结果中,最前面的第
2
~
10
个字符是用来表示权限。第一个字符一般用来区分文件和目录:
d
:表示是一个目录,事实上在
ext2fs
中,目录是一个特殊的文件。
-:表示这是一个普通的文件。
l:
表示 ......
终于到了编译范例的时候了,范例在APPS目录里,好兴奋呀。。。
开始编译:
zhaowei@zhaowei-ubuntu:~/toolchain/apps/HelloToolchain$ make
arm-apple-darwin9-gcc -lobjc -bind_at_load -framework Foundation -framework CoreFoundation -framework UIKit -w -o HelloToolchain HelloToolchain.o
ld: library not fou ......
On 05/02/2010 04:31, Larry Hall (Cygwin) wrote:
> On 02/04/2010 08:36 PM, phil song wrote:
>> Hi,cygwin,
>> when I compile some project in cygwin,It prompts
>>
>> /cygdrive/g/work_platform/open-s/ftk-0.2/src/os/linux/ftk_linux.h:43:22:
>> linux/fb ......
Linux version
[1] 2.6.10
2.6 version number, 10 release number
[2] 2.6.10 and 2.6.11
They can differ significantly even in core components and in fundamental algorithms
[3] 2.6.11.12
when a new kernel release appears, it is potentially unstable and buggy. To address this problem, the kern ......
关键业务慎用linux!
在这里我指的“关键业务”是指在企业中提供诸如收费、销售等业务,需要提供要求苛刻的“安全性”、“可靠性(7X24)等要求的业务。不是宕机几个小时都无所谓的业务。从我的以往的应用案例来看,使用linux是个非常糟糕的选择。安全性,由于不能得到及时修补很容易被利用。稳定 ......