Big_blue_的博客

编译格式问题

之前数据库出现过被撑爆的问题，集成同事帮忙查看后确定是没有对$ORACLE_BASE/admin/$ORACLE_SID/adump目录的文件做定时清理。后续增加了清理这个目录的定时任务，学习的过程记录下。关于$ORACLE_BASE/admin/$ORACLE_SID/adump目录这个目录下存储的是审计文件，具体作用后续学习补充。定时任务的格式和修改查看方式基本格式 :*　　*　　*　　*　　command分　时　日　月　周　命令第1列表示分钟1～59 每分钟用*或者 */1表示

之前发现进程总是会core，而且看core文件也没有什么头绪，后续在通过free -m不断跟踪运行过程的内存状态，发现当free和buffer都快用光的时候，进程就core了。之后通过root查看/var/log/message日志，发现了Out of memory: Kill process字样，基本确认了是内存不足导致的进程被系统筛选后杀死。Linux有个OOM killer机制，当系统内存不足请求时，为了保证系统不崩溃，会根据对每个进程的评分（考虑的占用内存大小，时间等因素，可以在/proc//o

1.在使用Remote -SSH插件时，报错glibc的版本问题。查找之后发现远程的服务器的版本最好要是CentOS 7.x及以上。

字节序导致的变量读取问题最近遇到一个问题，在Linux环境上进程获取对端消息包，解析对应结构体的包头时出现了问题，本来应该是12的内容，却读取出了3072。当时第一反应是出现了偏移，从0x000C读取成了0x0C00，结果验证了多次，查看对端发包的内容，都不是偏移。后来才发现，对端在发送消息时，存储的内容是主机字节序----也就是小端字节序。而在发送前使用htonl，转换成了网络字节序—也就是大端字节序。而在读取的时候，并没有对其进行转换。这也就解释了为什么0x000C读取成了0x0C00。这里涉及

在A环境进行编译后，放入B环境执行。本来这两个环境使用的Linux版本都是一致的，Linux xxxx 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011x86_64 x86_64 x86_64 GNU/Linux Linux yyyy 2.6.32-220.el6.x86_64 #1 SMPWed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux但在运行时发现报错如下：