遭遇系统问题

本文记录了一次AIX系统异常导致的应用进程日志文件未正常生成的问题排查过程,通过系统日志发现磁盘阵列中可能存在硬盘故障,并提出了上报处理的建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

应用系统所在的机房今天凌晨突然掉电,系统重启后,表面看起来正常,其实隐藏危机,核心的进程没有正常产生日志文件,花了好长时间查问题,也没发现故障原因。

顺便看了看AIX的系统异常日志,呵呵,有些收获:

# errpt |more
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
B4C00618   0225160006 P H ssa0           RESOURCE UNAVAILABLE
B4C00618   0225150006 P H ssa0           RESOURCE UNAVAILABLE

B4C00618   0225140006 P H ssa0           RESOURCE UNAVAILABLE
625E6B9A   0225130006 P H ssa0           ADAPTER DETECTED OPEN SERIAL LINK
B4C00618   0225130006 P H ssa0           RESOURCE UNAVAILABLE
625E6B9A   0225120006 P H ssa0           ADAPTER DETECTED OPEN SERIAL LINK
B4C00618   0225120006 P H ssa0           RESOURCE UNAVAILABLE
3DB7729E   0225120006 P H ssa0           ADAPTER PERFORMANCE DEGRADED

 T=P,有些不妙,再细看:

# errpt -a|pg
---------------------------------------------------------------------------
LABEL:          SSA_ARRAY_ERROR
IDENTIFIER:     B4C00618

Date/Time:       Sat Feb 25 17:00:00 2006
Sequence Number: 18057
Machine Id:      0056FA7E4C00
Node Id:         spms_app
Class:           H
Type:            PERM
Resource Name:   ssa0
Resource Class:  adapter
Resource Type:   ssa160
Location:        U0.1-P2-I5/Q1

Type=PERM,按照IBM技术手册的手法,这是不可能得到恢复和解决的错误,是永久的错误。看起来像是磁盘阵列中的硬盘出现了故障。

我没有smitty的相关权限,无法进一步确认了,上报错误信息给相关人员处理。

踏入编程这个行业有些时日了,越来越感觉解决系统问题已经不单单编程语言的语法,如果技艺要精进,熟练掌握编程语言的语法外,更重要的是去了解你的软件运行的环境(操作系统平台,数据库系统平台等),扩展你的技能,同时也会扩展你的视野。

### Ubuntu 系统卡顿的排查与解决方法 当遇到 Ubuntu 系统卡顿时,可以从以下几个方面入手解决问题: #### 1. **检查硬件资源占用** 高 CPU 或内存使用率可能是导致系统卡顿的主要原因。可以使用 `top` 命令来查看当前运行进程及其资源消耗情况[^4]。 ```bash top ``` 如果发现某个特定程序占用了大量资源,考虑终止该程序或优化其配置文件。 #### 2. **调整内核参数以提高性能** 有时操作系统级别的设置可能会影响整体性能表现。例如,在某些情况下增加允许打开的最大文件数能够缓解一些问题[^2]: 编辑 `/etc/security/limits.conf` 文件并加入如下行: ```plaintext * soft nofile 65535 * hard nofile 65535 ``` 同时修改系统的全局限制值 fs.file-max : ```bash sysctl -w fs.file-max=100000 ``` 为了使更改永久生效,请将其写入到 `/etc/sysctl.conf` 中。 #### 3. **图形驱动兼容性问题** 对于安装了独立显卡(尤其是 AMD 显卡)的用户来说,可能会因为 GPU 驱动不完善而遭遇虚拟化传递失败或者其他错误(比如著名的 "Reset Bug")[^1] 。尝试更新至最新版本官方推荐的开源或者闭源驱动,并确保主机支持必要的补丁应用。 另外也可以通过黑屏修复指南中的建议操作步骤来进行调试处理。 #### 4. **磁盘 I/O 性能瓶颈** 硬盘读写速度慢同样会造成整个桌面环境变得迟缓。利用 iotop 工具监控实时 IO 活动状况可以帮助定位具体哪个应用程序正在频繁访问存储设备。 ```bash sudo apt install iotop iotop ``` 必要时升级机械硬盘 HDD 到固态 SSD 可显著改善体验效果。 #### 5. **网络连接异常影响用户体验** 如果你正经历在线活动期间产生的延迟现象,则需进一步深入探究是否有 DNS 解析缓慢或是 MTU 设置不当等问题存在。可以通过 ping 测试目标服务器往返时间以及 tracert 跟踪路由路径等方式收集更多信息用于分析判断。 --- ### 提供一段 Python 示例脚本检测 CPU 使用率超过阈值的情况 下面是一个简单的 python 脚本来定期监测 cpu 的负载状态,一旦超出设定比例即发送警告通知邮件给管理员账户。 ```python import psutil import smtplib from email.mime.text import MIMEText def send_email(subject, body): sender = 'your-email@example.com' receivers = ['admin@example.com'] msg = MIMEText(body) msg['Subject'] = subject msg['From'] = sender msg['To'] = ", ".join(receivers) try: smtpObj = smtplib.SMTP('localhost') smtpObj.sendmail(sender, receivers, msg.as_string()) print ("Successfully sent email") except Exception as e: print (f"Error: unable to send email {e}") cpu_percent_threshold = 80 # Set your own threshold here. while True: current_cpu_usage = psutil.cpu_percent(interval=1) if current_cpu_usage >= cpu_percent_threshold : message_body = f'Warning! Current CPU Usage is at {current_cpu_usage}% which exceeds defined limit.' send_email("High CPU Alert",message_body ) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值